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 12/16 teleconf

the prelim minutes are attached.

Have a good Holiday season with Peace On Earth for all.

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

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes WSRM TC Conference Call – Dec 16, 2003



The meeting of the WSRM TC took place by teleconference 
Tuesday Dec 16, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call – Nov 11, 2003

1 Roll Call (late arrival no longer counts by OASIS rules)

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes

3 Feedback Discussion of XML 2003 Demo

4 Discussions of Issues

5 F2f Meeting schedule and new conference bridge


1         Roll Call

First Name

Last Name








Choreology Ltd





Cyclone Commerce














TC Chair































NEC Corporation





NEC Corporation






























Sun Microsystems





Sun Microsystems





University of Hong Kong


Jamie Clark, from OASIS staff, joined us on the call.


Meeting was quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Doug agreed to serve for issue resolutions.

2.2      Approval of previous meeting minutes

Jeff  moved to accept the 12/02  minutes. Jacques seconded.
No opposition, 12/02  minutes approved.

3         Feedback from XML 2003 Demo

Bob F stated the participants worked for the final integration and were able to present all of the demos without flaw.


No embarrassment.  Reasonable, but not large turnout.  Jamie from OASIS was there.


Few good questions.


Bob thanks everyone.


Jamie Clark: he was not surprised it went well.  Other sessions talked about WS-Reliability, and people were impressed.


4         Discussion of Jan F2F and New Conference Bridge service

Wed Jan 14, 15 and 16.


Try for 8:30 coffee time, 9:00 starting time, 5:30 ending time.


Friday go to 5:30 as well.


Think about wheter we need bridge.  Might just go f2f for this meeting.


Jan 06 is the next meeting.


Jacques explained that the new bridge number for Fujitsu will not be toll free.


If others are willing to host, they could do so.


Will post the new number more than a week.


Tom will email Jamie about the minutes having bridge numbers in them.


A lot of companies will facilitate employees, but this is a persistent usage that can be hacked.


Jan 20 one hour meeting.

5         Discussion of Issues

Iwasa put together a new document, rev .84, which incorporates the latest closed issues, 33 and 50.


5.1      Rel 33

Rel 33 was reopened and then later closed with the new definition of Ack being on delivery.


This needs to be reflected in the Issues list.


5.2      Rel 50

This was also closed at a wsrm teleconference.  New text has been added to the draft .84.


Needs to be reflected in the issues list.


Doug is having problems with draft identifiers.  The date of upload is easier to use as a consistent identifier.


Doug can send email to Iwasa an example of how to identify successive drafts.


Use same names of files. 


Tom Will send the email on where it was specified.



5.1      Rel 52 and 57  and 82

The following proposal is intended to resolve issues rel 52 and 57, and it also resolves rel 82.


Latest Email proposal from Task force:



This proposal (draft g) is intended to close both Rel 52 and Rel 57:



Rel 52: (New rules for state persistence, also, related "timing issues") and Rel 57  Ordering and Missing Message Behavior



Rel 57 is addressed as part of T5 of Rel 52 and hence should be closed as resolved by resolution for Rel 52.



Add the following text to a subsection which defines the two group termination parameters.  This section should replace the existing “RemoveAfter” section of the document.




x.x Group termination parameters


A request message MAY contain one of the following group termination parameters:

-        Group Expiry Time – the date and time at which the sender wishes the sequence group to terminate.

-        Group Max Idle Duration – On the receiver side, if the time interval since the last message was received exceeds the group max idle duration, then the sequence group may be terminated. On the sender side, the same condition applies to the time since the last message was sent.


The following assumptions pertain to the two group persistence control parameters:


a) the First message in a group (the one with status=start) MUST be used by the sender to indicate that time based group persistence control is in use for the group.

-        If the first message in the sequence of a group has neither group persistence parameter present, the group will be terminated according to condition t4 or t5.

-        If the first message has either of the two group persistence parameter present (either GroupExpiryTime, or GroupMaxIdleDuration) then that parameter will be used in the criteria used for terminating the group.

-        A fault MUST be returned if both group persistence parameters are present in any request. An INVALID_GROUP_PARAMETER fault shall be sent in this case..

-        If GroupExpiryTime is in use, the sender must not send a message in that group with an ExpiryTime greater than the GroupExpiryTime.


b) If guaranteed delivery is not requested for messages in the group, then the group termination parameter which was sent on the first message in the group must have a value sent on all subsequent messages in that group.


c) If guaranteed deliver is requested for the group, subsequent messages in the sequence do not need to repeat the group persistence parameter. When guaranteed delivery is mandated for the group, it is RECOMMENDED that the sender repeats the group persistence parameters in each message sent, until the first acknowledgement has been received for the group.  The receiver will continue to use the latest received value for the parameter chosen by the sender to apply to the group, to serve as the trigger for terminating the group. If a subsequent message uses a different group parameter than the one used in a prior message or uses a group termination parameter not sent on the “start” message for the group, an INVALID_GROUP_PARAMETER FAULT MUST be returned.


Doug B had a basic comment to simplify by always sending the parameter

It is not clear to me that this optimization saves that much.  In fact, it seems to complicate the protocol.  Why not have a single set of rules for both guaranteed and not cases, requiring the parameters always be present?


Jacques states that forcing each message to have a consistent parameter simplifies things.  The proposal we are reading perhaps is too flexible. 


Bob F stated what does latest mean.  Tom Stated it should be the highest sequence number received.

New text:


b) The group termination parameter which was sent on the first message in the group must have a value sent on all subsequent messages in that group.


c) The receiver MUST use the value from the highest sequence number received for the group.





d) In any subsequent message the parameter which was sent in the first message can be changed by sending a new value.  A new value for GroupMaxIdleDuration can either be increased or decreased. The protocol allows change (up or down) of GroupExpiryTime, as long as it is never less than maxExpiryTimeReceived.


Doug: Global change, of the statistic maxExpiryTimeReceived  max(ExpiryTime).


This spelling appears other ways in the proposal.  Agreed.




The sender will know, when the receiver has replied to a message which contains new group persistence parameter values present, that the receiver has knowledge of the new values.  If a reply to the message with the new parameters is not received in time, the sender needs to resend the group persistence parameters through a retry or in a subsequent message of the sequence. An INVALID_GROUP_PARAMETER FAULT MUST be returned if the value is decreased to be less than the maximumExpiryTime received for the group.


e) The sender can explicitly terminate the group by sending a message with status value “END”.  This is regardless to whether a group termination parameter is in use for the group.


Doug: we need a different word than terminate. Completing the group.


Jacques: all E is intended to stat that status=end be considered a parameter for termination.


Doug: status =end is part of ordering protocol.  Would not be discussed in group termination parameters.


Doug: four group stated, open, closed, terminated, removed.


Not terminated until complete.


Doug: all end does is give an upper bound on the maximum sequence number which will be sent.


Deleting e) was agreed.







Add a new section


x.y Group persistence


The duplicate elimination feature requires persisting the message ID (GroupId and optionally the Sequence Number), after the message has been processed and delivered (made available) to the application. The general rule about message ID persistence, is that an RMP MUST persist the ID of a message at least until the message expires regardless whether the message has been delivered or not to the application.


It is RECOMMENDED that an RMP removes the ID of a singleton message (message with GroupId but no SequenceNumber) from its persistent store after it expires. However, unlike for singletons, it is RECOMMENDED to NOT remove the ID of a message that belongs to a non-singleton group, when the message expires. The reason is, message IDs for groups can be stored efficiently as intervals of integers.


Doug: this should not be normative text. It is implementation details.


Jacques: As author I agree it is implementation relevant material.


Jacques would like this material to be left in as an informative Note.


Doug: clarify that the middle paragraph should be merged into the informative note. 


Agreed to clarify that the note is not normative.  Get rid of all capital letters.


NOTE: When doing duplicate checks for messages of a group, there is no loss of performance in checking over all past message IDs of the group, whether expired or not. The check will in fact be faster, because not discarding expired IDs means fewer intervals to look up.



Add the following new section:


x.z Group Termination and State Removal Criteria


These termination rules apply to both ordered and unordered groups.


In all termination cases (t1, t2, t3, t4, t5) described in this section, it is not necessary to remember the ExpiryTime of all messages of a group, as only the maximum of all ExpiryTime values is needed.


A group is defined as complete when all the messages between ‘start’ to ‘end’ are received.


Doug: Is there a requirement that the sender MUST make use of the END status. The word Complete needs to be clarified as a definition.


Doug: termination and remove apply to groups, but it is not clearly a list of definitions.


Make as Definition of Complete.



Termination of a group, and removal of its state are two distinct events.

o        When a group terminates, both in sender and receiver, no message is expected to be sent or received for this group anymore. When a group terminates, all subsequent messages with same group ID would be handled as belonging to a new group, unless they are duplicates of previous messages in the group, in which case they are treated as duplicates within this group.  If a message is received after the termination of a group, with same GroupId as the terminated group, it May be considered by the Receiver as belonging to a new group (the Receiver is not required to verify that a new GroupId value has not already been used in a previous group, as this test is impractical).


Peter: Once a group is terminated

Termination means stop forward work on this group.


Termination is about the processing of the group, removal is to assure you process correctly, and completion is about the sequence.


Jacques: these definitions are the expected behavior, the later sections are on the criteria for termination.


Tom: each end has its own knowledge of termination state.




o        When the state of a group is removed, any trace of the group (including status, groupId, current sequence number, as well as all received message IDs for the group (e.g. SequenceNumber intervals) are removed, and therefore not available anymore for subsequent duplicate checks. State removal may occur either at termination time or later, depending on the termination rules that follow.



x.z.1 Termination (t1):



Triggering event: GroupExpiryTime is over.


Receiver side:

The RMP MUST NOT accept any new message for this group and MUST terminate the group. It is RECOMMENDED that its state be removed as soon as possible. No duplicate check needs to be done against that group ever. If a "late duplicate" arrives, it would never be delivered to the next layer, as its ExpiryTime, which is always earlier than GroupExpiryTime, would have expired.


Sender side:

The group MUST be terminated, and its state removed from the RMP.



x.z.2 Termination (t2):



Triggering event: GroupMaxIdleDuration is over.


Receiver side:

The group MUST be terminated. But unlike (t1), some of its past messages may not have expired yet, and therefore their ID still be needed for duplicate checks.  If we define maxExpiryTimeInGroup as the max of all ExpiryTimes of messages already received for a group, an RMP MUST persist the state of a group even after termination of the group, at least until maxExpiryTimeInGroup is reached, in case duplicate elimination is required.


Sender side:

The group MUST be terminated, and its state removed from the RMP when the time elapsed since the last sent message (including retries) exceeds GroupMaxIdleDuration.



x.z.3 Termination (t3):



Triggering event: the RMP receives a status="end" message. The group had either GroupExpiryTime or GroupMaxIdleDuration specified.


Subcase t3.1: The group was complete on receiver side.


Receiver side:

The group MUST be terminated. However, its state is removed according to (t1) or (t2), depending which termination criterion was specified for the group.


Sender side:

The group is also known to be complete, and MUST be terminated and state is removed.


Subcase t3.2: The group was not complete on receiver side.

In this case, the group is not yet terminated.   Indeed, an "end" status only tells that "no greater seq number will ever be received after", but late messages may still arrive for this group.


Bob F: Concern of cases which do not fit, represent termination parameters tabularly.  Want state info to flesh out the details.


We could have the details of the state transitions.


Sender and Receiver Side:

Then the Receiver RMP and Sender RMP MUST apply termination rules of (t1) or (t2), depending which one of GroupExpiryTime or GroupMaxIdleTime was specified



x.z.4 Termination (t4):



Triggering event: the RMP receives a status="end" message. The group had neither GroupExpiryTime nor GroupMaxIdleDuration specified.


Subcase t4.1: The group was complete on receiver side.


Receiver side:

The group MUST be terminated. The time of removal of its state is determined by the maxExpiryTime received in the Group.


Sender side:

The group is also known to be complete, and MUST be terminated and the group state removed.


Subcase t4.2: The group was not complete on receiver side.

Receiver side:

In this subcase, the RMP should keep the group processing active: this event, by itself, does not cause the termination of the group.


The group can terminate in two ways:


a)    When the group becomes complete, or


b)    When the maxExpiryTime received for the group is reached.


In either case a) or b), the time of group state removal is based on the maxExpiryTime received for the group.


  Sender side:

  The group is terminated either when:

a)    all the messages in the group are acknowledged, or

b)    the expiry time of all the messages sent passes.


When the expiry time of all messages sent passes, the sender group state is removed.



x.z.5 Termination (t5):



Triggering event: In an ordered group, a message expires before delivery:

Either the message expires in an out-of-order sequence on the Receiver side, or a non-acknowledged message expires on the Sender side.


Receiving side:

Triggering event for Termination: In an ordered group, a buffered message expires before delivery.


For state removal:

- If the group does not have termination parameter, then it will be removed when the maxExpiryTime for all received messages passes.

- If the group uses GroupExpiryTime, then removal criteria as defined in t1 will apply.

- if the group uses GroupMaxIdleDuration, then removal criteria as defined in t2 will apply.


Sender Side:

Triggering event for Termination: A non-acknowledged message expires on the Sender side.

For state removal

- If the group does not have termination parameter, then it will be removed when the maxExpiryTime for all sent messages passes..

- If the group uses GroupExpiryTime, then removal criteria as defined in t1 will apply.

- if the group uses GroupMaxIdleDuration, then removal criteria as defined in t2 will apply.


--------end of proposal to resolve r52 and r57


Motion to accept proposal with these changes made by Jacques.  Sunil Seconded.


Doug B asked if we can send the updates of the task force proposal.


Tom will send the final answer as rev H.


No opposition. Move forward.


Iwasa will have new doc before the next meeting.


Bob stated to look ad wording of t4.1 defining. Max expiry time.




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