OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Prelim Minutes of WSRM TC f2f from Wednesday

alttached are the prelim minutes from Wednesday.

There will be a new Requirements Document posted tomorrow, reflecting
the comment resolutions from today.  It is the intent to have a vote on 
morning teleconf to progress this as a TC WG draft, available for public 

The meeting was not quorate (2 members missing) so we need to vote on
pending resolutions on the friday call.

The wednesday minutes will not be sent tomorrow, only the thursday additions
will be sent tomorrow.

Tom Rutt
WSRM Chair

Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Prelim Minutes WSRM F2F Wednesday:

Prelim Minutes WSRM F2F Wednesday:


1         Roll Call


Last Name




Voting Level







(at Hotel)




France Telecom

















TC Chair

























NEC Corporation




































WRQ, Inc.




Monday morning is not quorate (28 voting members, need 15 voting members present) thus all resolutions will be recorded as pending.


We will need a block motion on Friday morning to approve all pending resolutions in the minutes sent out on Thursday.


2         Admin

2.1      Review of Agenda


The proposed agenda was approved.

Here is the proposed agenda:


Friday Meeting will close at 12:00 PM

Conference Bridge Details: (10:30 AM to 12:00 PM Friday only)

Dial-In numbers:


Toll Free - : 1-800-605-5167

International - : 1-719-457-0339

Passcode: 732072



*Proposed Agenda:*




8:30 Coffee

9:00 Introductions and Review of Agenda

9:30 Roll Call, identification of input contributions, and Minutes approval

9:30 Discussion and Resolution of Requirements Issues

10:30 Break

10:45 Requirements Document Review (Verify Requirements Issue Closures).



12:00 Lunch

1:00 Requirements Document Approval

2:30 Break

3:00 Discussion of Unresolved Specification Issues

5:00 Homework Assignments, meeting closes 5:30 PM




8:30 Coffee

9:00 Review of WS-Reliability Specification Editor’s Draft

10:30 Break

10:45 Continued Discussion / Resolutions of WS-Reliability Specification Issues



12:00 Lunch

1:00 WS Reliability Feasibility Demonstration (J. Durand)

2:30 Break

3:00 Discussion for Finalizing WSRM Deliverables

5:00 Homework Assignments, meeting closes 5:30 PM




8:30 Coffee

9:00 Review of Homework Assignments


9:30 Discussion of Possible TC subgroups

10:15 Break


The following will be available for participation by teleconference:


10:30 Concluding discussions and possible voting on pending resolutions

11:30 Future Meeting Planning

12:00 Meeting Adjourns



2.2      Input contributions:

WSRM Requirements – 0.8


WSRM Issues List – Aug 28th


WSRM spec version 0.5 – Sep 2


Various WSRM Emails


3         Minutes Approval

Not quorate, wait for Friday teleconf


4         Resolution of outstanding Requirements Issues.


4.1      Issue 56 – Describe configuration info in spec.


Jacques Durand provided the following proposal for an annex to the spec (separate issue on the name for TimeToLive).

Discussion items from the meeting are in italics (non indented)

Rel 56:


1.  Maximum message lifetime/duration 

Discussion: determines upper bound on message expiration time interval ,from date it is sent


SUMMARY:         Set an expiration time for any message, when no TimeToLive was set.



There are two issues with messages for which TimeToLive has not been set,

in terms of persistence handling:

(1) on receiver side, messages may persist a long time in the receiver store if

"unclaimed" by the application, or application unavailable (e.g shutdown).

(2) on the sender side, message removal is normally controlled by the Ack and resend mechanism.

However, e.g. in some cases of long shutdown, messages do be [re]sent should be considered as

too old and not be processed anymore, to free resources for new messages.

In both cases, an RMP needs input to decide when it is time to discard an "old" message

from the store, and to notify the loss.


PARAMETER:     MessageMaxPersist (perhaps have it be Default TimeToLive)


MODE:   mandatory


SENDER HANDLING: remove from store all messages as specified in spec 2.2.3,

or else if no TimeToLive specified, with (sending date + MessageMaxPersist) > currdate.


RECEIVER HANDLING: remove from store all messages with either: TimeToLive > currdate,

or if no TimeToLive specified, with (sending date + MessageMaxPersist) > currdate.

SCOPE: apply to all received and sent messages.



- this parameter is mostly meaningful for message store management, and is common

to messages for all connections Sender-Receiver.

Is equivalent to a "default" TimeToLive, except that it does not rely on setting a default

TimeToLive in messages (which requires all Senders to do so and cannot be controlled by a Receiver).

- as only applies when TimeToLive is not set, will be override by TimeToLive.



Need to decide (need a config param for this?):

- in case of persistence failure (no more room in store), either new messages should

be bounced, or older messages be flushed.



We need a Fault for the receiver to return if the time to live specified in the request is greater than the maximum time to live the receiver is willing to accept.


Another question:  why is the time to live parameter optional. 

If timeToLive was mandatory to be sent with each reliable message then there would be no need for a “default” time to live.


Rejecting a message you are not willing to persist would be based on a Maximum Time to Live (perhaps only visible through fault message).


Discussion Item:

A Config parameters is  only to  be included the spec if that parameter affects the observable behaviour of an endpoint using the protocol.


Issue:  If spec has a config parameter specified, there must be a way whoever is using the configuration parameter.



2.  Maximum message group (or message sequence) lifetime


SUMMARY:         Provides criterion for removing group data from RMP store



Sequence of messages (identified by GroupId) may be started, yet not ended.

In case no message is sent with @status="end" or if @removeAfter is never set, many

sequences may remain indefinitely open, tying up system resources.

In such case, we can either (a) set an overall max duration for all sequences,

or (b) set the max elapsed time between two messages of a sequence, so that

when a sequence is "inactive" beyond this time, it will be assumed it has ended.

Because it is sometimes hard to estimate the max length of some sequences

(some may be very long, or even never ending by nature, e.g. a monitoring flow),

we'll use a parameter for (b) which seems also more intuitive.


Limiting the idle time between messages in the sequence, allows the receiver to determine that the sequence is retired.


The current protocol has a status in the sequence to signal the last message in the sequence.


If sender goes away, how long does the receiver wait before it closes the “sequence”. 


Do sequences only close if the sender sends the “last message” indication.


Regardless of default time to live, there is a need to cap max time to live on receiver. 


An error (group shut down by receiver) might be required for use when the receiver gets a sequence member for a groupID which the receiver has shut down.


PARAMETER:     GroupMaxIdle


MODE:   mandatory


SENDER HANDLING: tracks for each group the elapsed time since last sending for the group.

Remove the group data if elapsed time > GroupMaxIdle.


RECEIVER HANDLING: tracks for each group the elapsed time since sending date of

last message received for this group. Remove the group data if elapsed time > GroupMaxIdle.

If some unordered messages of this group were still awaiting to be passed to the receiver app,

then pass them, and send error notice for the missing ones.

SCOPE: apply to all groups of all connections (sender/receiver)



3.        If one wants this to apply only when “removeAfter” has not been specified,

then Spec 3.3.1 should not consider “removeAfter” default = forever.

If we consider the default is “forever”, then this idle time limit policy should

apply also to any group, which may be brutal, as cannot be override.





3.        Resend interval (SEE REL 47)


SUMMARY:         defines the elapsed time before resending a non-acknowledged message.



When guaranteed delivery is required, need to set the time to wait for an Ack

before resending the message.

Assume this is specific to each Sender/Receiver connection.


Does the sender have to have this be a fixed parameter?  It could be implemented as a “soft” parameter which the sender could change by time of day, or by traffic load.


We need a use case for why the receiver needs to know this parameter.  Scott W stated that the minimum retry interval would be useful for the piggyback implementation.  Could it work if the receiver did not know this parameter (yes but would give more traffic).


It is necessary if we can find a benefit for the receiver to know this.


PARAMETER:     RetryInterval


MODE:   mandatory when guaranteed delivery is requested.


SENDER HANDLING: used to schedule the resending: minimum elapsed time before resend.




SCOPE: apply to all messages of a connection (sender/receiver)



- could be used as a base-interval if a more complex interval algorithm is used later.

- it is important to define the scope: if specific to a connection Sender/Receiver,

an RMP will have to manage a parameter for each connection, vs. just one for all connections. 





4.  Retransmission count (SEE REL 47)


SUMMARY:         define the max numer of resent non-acknowledged messages, before

generating a delivery failure.



When guaranteed delivery is required, need to set the max number of times a message

will be resent if not acknowledged (from 0 to N), so that a repeated failure to send

will not tie up processing and storage resources in the Sender, and will be notified

to sender application in a timely manner.

Assume this is specific to each Sender/Receiver connection.


Discussion:  This parameter would be a nice thing for the receiver to know.  However it is not required for the protocol to work.


PARAMETER:     RetryMaxNumber


MODE:   mandatory when guaranteed delivery is requested.


SENDER HANDLING: Used to limit the total number of message resend.




SCOPE: apply to all messages of a connection (sender/receiver)



- it is important to define the scope: if specific to a connection Sender/Receiver,

an RMP will have to manage a parameter for each connection, vs. just one for all connections. 







5.  Duplicate search scope (minimum number of past messages to look-up)


SUMMARY: Defines minimum size of set of past messages to be considered for a duplicate search.



Duplicate search cannot be guaranteed over all previously received messages.

It is necessary to clarify the limits of the duplicate search, either in number

of past message IDs to look-up, or in terms of past date.

The trade-off scope of search / performance can also be adjusted and prevent doing

exhaustive expensive duplicate search over large logs of non-relevant message IDs.



Receiver cannot do a global “exhaustive” search for duplicate messages. 


Payrits: This will change the definition of “duplicate” elimination.


Sunil: Can we keep the protocol simple, to assume that the duplicate elimination is not limited in such a way.


PARAMETER:     DuplicateSearchSetLimit, DuplicateSearchTimeLimit


MODE:   Mandatory if duplicate elimination required.




RECEIVER HANDLING: will limit (but guarantee) the search of duplicate over a number of past

message IDs equal to DuplicateSearchSetLimit, or over the past messages until the date

defined by (current date - DuplicateSearchTimeLimit).


SCOPE: apply to all messages of a connection (sender/receiver) for which a duplicate

elimination is required.



- in case both parameters are also specified, the search is limited by whichever

defines the larger set.

- it is important to define the scope: if specific to a connection Sender/Receiver,

an RMP will have to manage a parameter for each connection, vs. just one for all connections. 






6.  Unordered messages window size (max number of messages to hold)


SUMMARY: Defines max size of set of unordered received messages, before

 taking action (notify, pass messages to application)



If a message is missing in a received sequence, the Receiver may have to store

a very large number of messages, and delay their passing to the application in a

damaging way (a messages may loose value way before reaching its TimeToLive).

Relying on the store capacity to decide of the size of this window is crude:

space resource may not be well allocated between several broken sequences.



Scott has homework on semantics of non-received message in an ordered group.


TimeToLive minus epsilon could be the trigger for this decision by the receiver.


This problem might require a configuration parameter. 


Payrits: This could be an api issue, not a protocol interop issue.




PARAMETER:     UnorderedWindowSize


MODE:   mandatory if Ordering required.




RECEIVER HANDLING: When the unordered section of a particular sequence exceeds UnorderedWindowSize,

Receiver will notify of the unreceived messages, and pass all pending messages to the application.


SCOPE: apply to all messages of a sequence / GroupId.



-          should the “reduction” of an unordered sequence be lternatively controlled by a time-based




-          Behavior of Receiver after a broken sequence has been reduced by reaching window size,

is TBD: keep ordering the rest? Give up?




RMP-specific resource capabilities: (TBD)


These parameters are not reflecting an RM agreement, like the previous ones.

Rather, they define the “profile” of an RMP, in terms of:

- persistence capability (may include also some tuning info such as MessageMaxSize, MessageAvgSize)

- types of MEPs supported

- WS-RM spec options supported (e.g. sync/async)

- alternative transport bindings supported (besides HTTP),


RMP-specific behaviors: (TBD)


- recovery actions to be taken on failure and/or failure recovery

(power outage, no-ack count expired, crash tolerance, etc).

-          level of failure notification.


General RM agreement parameters: (?)


These parameters would represent the RM agreement, and would be interpreted

by both Sender and Receiver RMPs. Could be override by header data:


- Duplicate elimination

- Guaranteed delivery

- Message Ordering


<end of J. Durand email>

The Discussion went back to the Requirements Issue.


The spec will describe semantics of parameters.


Alan: there are two types of parms:

1) those needed to be know for protocol to work properly (e.g. expiry time)

2) those as optimization or api parameters which only need to be known by one side.


Proposed requirement statement:

The spec will describe the semantics of Reliable Message Processing Parameters that affect both sides of the protocol.


Need to generate a new spec issue for each of the 6 parameters from the J. Durand proposal.


Agreed to Pending resolution of Rel 56 as closed with the above requirement to be added to requirements doc.


5         Requirements review.


Jeff M suggested that after resolution of comments on the existing Requirements Document, we can vote to make it a TC draft, to post on Kavi as status of Working Group Draft Document.


Doug:  Once the WG draft is determine, we still need to have a way to progress new comments and resolutions on the wg draft.


Tom stated that the agenda states that we will have a TC approved Requirements document by Wed afternoon.


Jeff suggested we make the requirements a working group draft by the end of this meeting.  This means generally approved by the TC.


Tom asked what the status of the requirements document would be.  Should it be put on the public comments list before the spec is approved?


There was general agreement to make it available to the WSRM-comments list out of this meeting.


It was determined that Kavi will make any document marked to be available to the public, available to the public.


The goal is to progress this document from editor’s draft status to WG draft status.  We will close all completed issues for this requirements document.  We will make the document available to public.


5.1      Section 3.2 Definitions

Sunil suggested that the ack binding pattern definitions be modified to state the pattern is for acks and faults.


Agreed to make this change.


Agreed to change “Acknowledgement Binding  to “RM-Reply” wherever used in the document.


5.2      Mapping of oneway mep

In 5.1, Sunil wants to take away the association of oneway MEP to Request/Response MEP in the diagram.


Doug B asked why we need the diagram, given the text in section 5.3.


Sunil pointed to Requirement 3.3.1:


R 3.3.1 – Sunil wants to change “MUST” to “MUST NOT”.  Application mep of one way cannot have a response for the application.


Sunil stated that for one way MEP at application layer, the RM-REPLY must be received on a callback or through polling.


The WSDL contract, by WS-I BP 1.0, makes this required.


Payrits stated that if WSDL is not being used for application contract, this would not be a problem.


Sunil stated we cannot change the user’s WSDL, which is the contract for the service.


Since we are using the WSDL definition for mep, we should consider it in our use.  If we wanted to describe our headers in wsdl, it could not be done with Oneway wsdl mep, since it allows on output message parts.


Jeff M pointed out that Sunil’s point is that if we ever want to use WSDL to describe our headers as message parts, we could not do that with WSDL Oneway, since it has no output message to place the reply headers in.


Straw poll: Change 3.3.1 “MUST SUPPORT” to “MUST NOT SUPPORT”


Doug suggested deleting 3.31 as an alternative.


There was additional discussion on how to reform the requirements in this area.


Change 3.2  3.3 and 3.4 with the following two new requirements:


The spec must support the one way Message exchange pattern using both of the following:

-         Callback RM-Reply pattern

-         Polling RM-Reply pattern


The spec must support the request response Message Exchange Pattern using all of the following:

-         Response RM-Reply pattern

-         Callback RM-Reply pattern

-         Polling RM-Reply pattern


Payrits:  We want to support WS RM for services described as WSDL one way and WSDL request response.  


New wording:

Spec must support WSDL 1.1 one-way operation type


Spec must support WSDL 1.1 request-response operation type.


Spec must support response rm-reply pattern for oneway or request response operation.


Spec must support callback RM-reply for one way.


Spec must support polling RM-reply for one way.


Discussion of 7.3.1:  This requirement if for the polling for reply case.


Agreed to delete 7.3.1.


Editor shall fix the picture or delete it.

5.3      Basic profile requirement


Add basic requirement for supporting WS-I Basic profile.


5.4      Req 4.1


The sentence in 4.1.1 is is required.


R4.1.1.1 should be made the same level as R4.1.1.


5.5      R5.4.3

Need to fix the wording of 5.4.1 and 5.4.2.


Change 5.4.3 to be compatible with new decisions.


5.6      R6.2

Iwasa stated the requirement needs to be fixed.


This came from issue rel-7.


Agreed to put in text from issue rel-7 resolution.


Response from non RM node to RM request will most likely be an HTTP fault response.


5.7      Rel-5

Failure recovery definition: The definition agreed to did not make it into the document.


Agree to fix the requirements as indicated in Rel-5 resolution.


5.8      Rel – 6

Doug asked: Do we need a definition for persistent data?


Is persistent data connected to persistent storage?  Both are not required.


Leave requirements alone.


5.9       Req 7.2.1

Doug B stated this was not agreed.


“Every implementation must be able to receive multiple acks and may be able to send it”



May 20 minutes 2.5 is where it came from.


Doug suggested that 7.2.1 is an implementation issue.  It does not belong as a requirement.


Doug asked if we need a requirement to reduce the number of implementation options in the spec.


Tom Rutt example:

“The semantics of spec options must be specified in such a manner, as to avoid interoperability problems.”


One example of a spec conformance requirement to guarantee interop: “if there is a parameter which is optional so send, all receivers must implement the ability to receive that optional parameter.”  The alternative is to have a fault the non-implementing receiver can return to indicate it does not implement.


Discussion on deletion of the R 7.2.1.


Agreed to add new requirement to requirements document:

“The spec must have a conformance section which clarifies what is required to claim conformance to the spec.”


Agreed to delete R 7.2.1.



Doug stated this is not a requirements issue.


This is a specification issue which has been resolved and agreed.


Agreed to remove R7.4 from requirements document.


5.11Requirements wrapup.


Payrits agreed to produce a new version of the requirements, to reflect the comment resolutions above.


He will provide the new doc, with a list of the changes made, for approval to progress as wg Draft for pubic revied, at the Friday morning teleconference,

6         Discussion of Spec Issues:

6.1      Rel 22 – Optionality in Spec

Email discussion:


The original reason for the issue on the list was our reference to 2119 (optional to implement) terminology versus our use of "optional" and a few other words in the "can zero copies of this element / attribute appear in a valid (compliant) WS-Reliability message?" sense.  In that light, Iwasa is recommending a way to avoid the problem -- specifically, never using 2119 terminology except within the conformance section.  You seem to be going a step further and recommending a particular approach to conformance.  Is that correct?  If so, your proposal actually relates to issue REL-29 and merits further discussion.

I suspect the conformance section will end up saying more than "do the whole specification".  At least, the various definitions for crash tolerance and persistence imply we will have more to day.  Deployment patterns (for example, intended for use where inbound HTTP requests are not allowed) may imply conformance patterns...


On 29-Aug-03 12:41, Dock Allen wrote:

Maybe a revisit of why something might be optional:

1-save bandwidth (not very much value here)

2-backward compatibility

3-sideways compatibility (with implementations that don't support WSRM)

4-allow implementations to only support some of the features

I think we're after 2 and 3.  Meaning that a non-supporting implementation will ignore the parameters on input, and will not provide them on output.

This means that 4 would be implied, but I argue against that.  If you permit implementors to only support part of the specification, it becomes pretty complicated for the user
(what if you are using an implementation that only supports ordering and you are talking to an implementation that only supports duplicate removal?)  I don't see any benefit
(from an interoperability point of view) for subsets, and they add complexity to the overall community, as well as making life really difficult for users who have mult-platform
applications and vendors who need to write applications that can exist in multiple environments.  So I would recommend that either you do the whole spec, or none of it.

My two cents worth

Dock Allen

iwasa wrote:

Here is a proposed resolution for Rel22:

REL-22 Spec  meta Editorial Unassigned Tom Rutt
Title: Optionality
Description: The use of the term OPTIONAL needs to be
revisited particularly in a specification of this nature where
interoperability is an explicit goal and RFC 2119 has been
referenced.  [see original spec]
Proposal: Go to email on this issue

Proposed Resolution:
We include Conformance section in the spec.
The word "OPTIONAL " in the spec means
the element or attribute is optional to be in a message.
But it doesn't say anything about optionality
for implementation.
Comformance section should mention about
the optionality for implementation.

Any comments?




Email from Martin Sachs:

IMHO, the word "optional" must only be used where optionality for implementation is intended.  RFC2119 is specifically about optionality for implementation.  For any other uses of "optional", other words should be found instead of using the word "optional".  Please also be aware that while use of the RFC2119 words in capital letters has become a common practice, RFC2119 does not require the use of capital letters for those words.  Therefore, the use of lower case (e.g. "optional") when the word is for purpose other than optionality of implementation violates RFC2119 and will cause confusion.





There was discussion the keyword “optional” in Xml Schema definition language.  They did not refer to rfc 2119.


Strongest statement:

“Receiver MUST be able to receive and process correctly all possible inputs defined in the protocol”


This would guarantee interoperability.


It is stronger than SOAP “mustUnderstand” = True.


Weaker statement as a Fallback:  spec describes which protocol inputs must be received and processed correctly, and which can allow returning a fault message.


OPTIONAL on sending: the sender does not have to demonstrate the ability to send the parameter of initiate the feature.  The sender of a reply is the server.


An example: the use of queryStatus message might be OPTIONAL.


When we use the word OPTIONAL (or MAY be present) use it as in 2119.  Use a different word when we want different semantics.


Doug stated that ebXML messaging spec qualified the scope, so it was not for the overall system “OPTIONAL for a message”, rather than “OPTIONAL for Implementation”.


Text from 2119:

   MAY   This word, or the adjective "OPTIONAL", mean that an item is

   truly optional.  One vendor may choose to include the item because a

   particular marketplace requires it or because the vendor feels that

   it enhances the product while another vendor may omit the same item.

   An implementation which does not include a particular option MUST be

   prepared to interoperate with another implementation which does

   include the option, though perhaps with reduced functionality. In the

   same vein an implementation which does include a particular option

   MUST be prepared to interoperate with another implementation which

   does not include the option (except, of course, for the feature the

   option provides.)


Agreed to have group examine every use of the word optional on Thursday, while going thru spec.



Meeting closed for day at 5:30.  Will reconvene on Wed AM.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]