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 Wed Minutes:

attached are the minutes.

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

Title: *Proposed Agenda:*

WSRM Face To Face Proposed Agenda:

Wednesday Jan 14 – 16, 2004

Oracle Conference Center

350 Oracle Parkway
Redwood Shores CA 94065

Conference Bridge Call in Info:  Each day (9:00 AM to 11:00 AM Pacific Standard Time, with possible extension to 12:00 Noon if required each day) 

Host: Fujitsu
Toll only :  1-512-225-3050
Participant code: 89772
(NOT toll-free !)

Wed Jan 14: AM:   Note: Roll call is on Wednesday Morning you must be present or on bridge to have attendance count for voting rights.


0         Draft Agenda

Wed Jan 14: AM:   Note: Roll call is on Wednesday Morning you must be present or on bridge to have attendance count for voting rights.


8:30       Coffee and Continental Breakfast

9:00       Start Roll Call, Review of Agenda and Identification of input contributions

9:15       Approval of 1/06 minutes

9:30       Walk thru of WS draft/ Schema to confirm reflection of accepted resolutions

10:15      Triage of Open Issues (arrange in priority)

10:30       Break

10:45       Resolution of Config Parameter Issues Rel(56, 83 84, 85, 86)

12:00       Lunch begins




1:00 PM   - Detailed WS-Reliability Editor’s Draft Walk thru

a)         Check for usage of Optionality “SHOULD, MUST, MAY, etc” (Rel 22)

b)         Determine candidates for Optional Implementation (Rel 29)

2:30     Break

3:00      Discussion of Rel 49 Non normative wsdl annotation Specification

3:30      Discussion of UML State Charts

5:00      Homework assignments and meeting recess


Thursday Jan 15



8:30        Coffee

9:00        Review of Homework Assignments and Continued Issue Resolution

10:30      Break

10:45      Resolution of “Requirements” Issues (Rel 59-79)




12:00      Lunch

1:00        Continue Resolution of Requirements issues

2:30        Break

3:00        Resume Discussion of Issue resolutions

3:30        Discussion on Conformance issues (Rel 29) for Sender and Receiver RMPs

5:00       Discussion of Homework Assignments, and meeting recess


Friday Jan 16:


8:30 Coffee

9:00           Review of Homework Assignments/proposals

9:30           Continuation of Conformance Discussion

10:30         Break

10:45         Review WS-Reliability Spec / Schema and assign subteams to clean up descriptions and examples.

12:00         Lunch




1:00            Discussion of Timing for Deliverables and Future Interop Demo plans

2:30            Break

3:00            Concluding discussions

4:00            Future Meeting Planning and Wrapup

5:00            Meeting Adjourns


1         Introduction

1.1      Earliest Possible timeline

Tom Rutt displayed the following possible timeline


Jan 27 – CD 1 7 day Ballot issued

Feb 3 – CD 1 ballot closes

Feb 4 – 30 day Review initiated

March 5 – 30 Day public Review ends

March 15, submit to oasis staff for member vote

April 1 – Membership two week review

April 15 – start member two week vote

April 30 – member vote concludes.  Earliest Oasis Standard.


1.2      Roll Call


First Name

Last Name













Choreology Ltd














TC Chair
















NEC Corporation




















Sun Microsystems





Sun Microsystems





University of Hong Kong







1.3      Identification of input contributions

Iwasa prepared a new spec Version updated with Sunil’s comments and some technical fixes to meet resolved comments.


Doug asked that we use the 1-06 document, because his annotation were against that version.


Doug uploaded a new version of the issues list, dated 1/14/2004.


2         Approval of 1/06 minutes

Sunil moved to approve the 1/6 minutes.  Bob seconded.


No opposition , minutes approved.


3         Discussion of Active Issues

3.1      Rel 56, and 83 thru 86

Jacques email sent on 1/6/2004

Here is a proposal for Rel 56, attached, for further review.

It already reflects some earlier comments from some of you (most from Doug).


As for the former list of REL 83-84-85-86:


REL 83: current proposed resolution for R83 is assumed by R56, although parameter is renamed in R56.

REL 84: current proposed resolution for R84  is assumed by R56, although parameter is renamed in R56.

REL 85: propose to close without action: not relevant anymore since we can guarantee to NOT deliver duplicate

regardless of scope (i.e. "forever", thanks to the semantics of ExpiryTime)

REL 86: propose  to close without action: REL 57 is handling the termination of  pending out-of-order sequences.

Any other reason to cancel an out-of-order sequences hinges on storage capacity, which should be

handled separately (and in a consistent way across several other RM features. E.g. with appropriate Faults.)







REL 56: Proposal





- the proposal is independent from resolution for REL 83-84-85-86, although

we assume here that REL 85-86 are dropped. (rationale to be sent separately)


- Instead of talking of "configuration parameters", this proposal will talk

more abstractly (and more generally) of "reliability agreement items", or RM-agreement items.


- "RM-agreement items" describe the reliability contract between parties.

They cover both the RM parameters that show up in the protocol, and those which do not

(like "retry interval", "number of retries"). This distinction is not essential at this level.

Some items may, at implementation level, translate into configuration parameters for RMPs.


- the proposal is that the spec identifies and describes the RM-agreement items, so they

have a formal existence independent from their protocol representation (as some do not

appear in protocol). This allows for treating all of them in a uniform way in the spec.

The proposal does not mandate a concrete representation.

Later on, a formal representation could be recommended (e.g. a policy language,

an agreement representation...)



Detailed proposal:



Reliability Agreement (or RM Agreement):



An RM Agreement describes the set of agreed contracts between:

- a Sending "application layer" and the associated RMP.

- a Sending RMP and a Receiving RMP.

- a Receiving "application layer" and the associated RMP.


The way these contracts are established or communicated to each party is out of scope,

although for the contract RMP-RMP, the assumption is that all the needed synchronization

is achieved through the message protocol, i.e. the Receiver RMP does not need other

input than the message headers.


The highest-level items of the RM Agreement are the main RM features themselves:


- Guaranteed delivery (or at-least-once delivery):

When a Sender application submits a well-formed business payload to the RMP,

the agreement requires that either:

(1) the payload is delivered to the Receiver application, or

(2) the Sender application is notified in case of failure.


- Duplicate elimination (or at-most-once delivery):

When an RMP delivers a business payload to a Receiver application, the agreement requires

that no future business payload from a message with same identity as the message containing

the first payload (GroupId and SequenceNumber if any) will ever be delivered

to the Receiver application.


- Guaranteed ordered delivery:

When a Sender application submits an ordered sequence of business payloads to an RMP,

the agreement requires that when delivering a business payload to the Receiver application,

all previous payloads in the sequence have already been delivered.



RM Agreement Items:



An RM Agreement is a list of Agreement Items.

An RMP implementation MUST be capable of:

(1) taking knowledge (e.g. either via configuration, or via an API call, or via a message,

or via the result of an algorithm) of a set of values that represent the RM Agreement Items

described in this specification,

(2) processing them according to the semantics described in this specification.


Some of these items will map to some message header field, some will not.


They are:


- GuaranteedDelivery (enabled/disabled):  for setting guaranteed delivery.

- GuaranteedOrdering (enabled/disabled):  for setting guaranteed message ordering.

- AtMostOnceDelivery (enabled/disabled): for setting message delivery without duplicates.

- GroupMaxIdleDuration (number of seconds):

For setting the elapsed time limit from the last message sent or received in a group,

after which the group can be terminated.

- GroupExpiryTime (number of seconds):

For setting the date and time after which the group can be terminated.

- ExpiryTime (number of seconds):

For setting the date and time after which a message must not be delivered

to the receiving application.

- RetryMaxTimes (integer number):

For setting how many times a message must be resent if not acknowledged.

- RetryTimeInterval (number of seconds):

For setting the minimal elapsed time between two re-sending of the same message.

- ReplyPattern ("response", "callback", "poll")

For setting the mode of response for Acks or Faults.



Messaging Scope of Agreement Items:



The messaging scope of these agreement items may be:

(s1) All messages sent over a connection between a Sender RMP and a Receiver RMP (default).

(s2) All messages sent within a Group.

(s3) a single message, within a group of several messages (non-singleton group).


Some agreement items obviously relate to a particular scope, e.g. ExpiryTime

is affecting each message separately, while GroupExpiryTime is an agreement about groups.

Such scopes are "required" scopes that must be supported.


The smallest required scope for each RM agreement item is:


Message scope (s3):

- ExpiryTime

- RetryMaxTimes

- RetryTimeInterval

- ReplyPattern 

- GuaranteedDelivery

- AtMostOnceDelivery


Group scope (s2):

- GuaranteedOrdering

- GroupExpiryTime

- GroupMaxIdleDuration


NOTE: although an RMP must support each agreement item at the scope level above,

the RMP implementation may also provide a way to specify these values for a broader scope.


Example: an RMP implementation may decide to provide a way to specify the ExpiryTime

value for all messages of a group.



Rules about Agreement Items, when used in an RM Agreement:



- If GuaranteedOrdering is enabled for a messaging scope, then GuaranteedDelivery and

AtMostOnceDelivery MUST also be enabled for that messaging scope.


- If GuaranteedDelivery is enabled for a messaging scope, then the items

(RetryMaxTimes, RetryTimeInterval) MUST also be defined for that scope.


- If GroupExpiryTime is enabled for a messaging scope, then the item GroupMaxIdleTime

must not be enabled, and vice versa.


Jacques summarized that the notion of RM-agreement, without explicit representation in protocol, allows these terms to be used in the specification.


Jacques moved to adopt his proposal. Bob seconded.


If motion passes, this text will be put into the spec.  Editoral changes could be incorporated later.


No opposition. Motion passes.  Close 56, 83 to 86.


3.2      Rel 49 WSDL annotation


Sunil Email:

This proposal not only addresses the main issue as mentioned in REL 49,

 but it also touches upon the client side config that was mentioned in other

 issues.  I'd like to discuss this more at the F2F


 Salient points are:


    * This should either be normative and optional (wrt to compliance) or should be made non-normative. Oracle prefers former.

    * Has 2 different schema elements. <service-config> is defined for service side WSRM config to be used in the Service WSDL. <client-config> element is used for client side config to be used in vendor specific client property/config file.

    * <service-config>

          o Based  wsdl  extensibility elements concept.

          o Per operation or per binding. Note that while wsdl 1.1 is ambiguous about extensible elements under portType/operation, BP does allow it.

          o This extensible element can be either used in portType/operation or binding/operation. If it has to be shared by all bindings, then it could be used in the portType/operation [abstract part]. If this (wsrm usage) is per binding, then it can be defined only in the binding operation It can also be used at the binding level directly, if it is common for all the binding operations (note that extensibility elements are prohibited at the portType level though).

          o This service element could be used inside any vendor specific policy elements or directly. If used directly, one could use the wsdl:required  (set to true) attribute, to enforce the config element..


  Once we finalize the schema, we could define them in the same schema we are

  defining for the WSRM SOAP Headers and use the same namespace.


 Example of a <service-config> usage inside the operation 'foorBar'.


<portType name="fooPortType">

  <operation name="fooBar">


    <wsrm:service-config xmlns:wsrm="some URI" wsdl:required="true">

        <!-- Spec. version>


        <!-- We can also have some kind of capability parameters












            <!-- List the reply patterns supported by this service.

                   Can have one or more such patterns -->


                    Callback  <!—possible values are Response/Callback/Polling ->












     <input message="fooMessageIn" />

     <input message="fooMessageOut>





Client side config sample:


<wsrm:client-config xmlns:wsrm="some URI">

    <!-- No. of retries to send for non ack. messages  and return interval -->



          <wsrm:retry-interval>10</wsrm:retry-interval>  <!-- 10 secs



     <!-- Can have only one such pattern. If the pattern is 'Callback',

            the reply-to attribute can also be used -->

     <wsrm:reply-pattern wsrm:reply-to="SomeURIToSendAcksAndFaults">

            Callback  <!—possible values are Response/Callback/Polling ->












Sunil summarized some issues:

  • Client side config
  • Optionality/conformance
  • WSDL extensibility element usage (on which wsdl 1.1 elements.


If we decide on the general approach, we can refine the schema.


Jacques: at high level this is to specify capability of a service with respect to Reliable message capabilities


Sunil: others have used ws-policy for such things.


Jacques – is someday a standard policy language is adopted we will have collistion.


Sunil – this would be replaced by the WSDL 2 features and properties (F&P).


Jacques: Some of thes capabilities may not depend on the web service itself , but on the deployment.


Sunil: at abstract level it is less useful.  It would be more useful at the port level (or perhaps binding).


Sunil : it definitely would be optional. 


Tom: what requirement are we trying to solve here.


Bob: I have a concern about finishing this in the 1.0 timeframe.  I suggest postponing this beyond ws-reliability 1.0 as a future feature.


We only have a few weeks to reach or committee draft status.


Sunil: This thing is high level concept, once we decide the specifics are not that difficult.


Bob: we should focus on fundamentals required to get us to 1.0.


Bob: we should focus on getting a tightly specified document in the limited time we have.


There are activites being started, WS-PL as part of WS-XACML


Bob F suggestd to close the issue 49 be closed, and that the annotation be put on the “wish list” for future protocol versions.


Doug: is the problem that this solution appears large at this late date, or whether it is addressing something separate from the raised issue.


Bob: both.  I would like to be able to use features which have not yet been adequately baked in standards committees.


Doug: there is that and the WSDL 2.0 approach of F&P.


Doug: how about a simple annotation: this endpoint requires the use of WS-Reliablity (or a list of the three Reliability features).


Tom: thus the main requirement in R49 is to allow a WSDL service definer to specify which of the three QOS features are required to be used with a service instance.


Sunil we would not put wsdlrequired true on these extensibility elements.


The group decided to keep issue open for now, perhaps decide later in the week.


Bob: we are on the fence about an optional feature, I would like to close now.


Leave it open for now.


4         Walk thru of WS draft/ Schema to confirm reflection of completed resolutions


Doug: there are 6 accepted issues to check if they have been applied to the document.  Iwasa and I can do this online.


There are 20 completed issues to confirm that they are reflected in the document. We need to decide on moving from completed to closed.


All in order:


4.1      Rel 14

in appendix c line 997 this is done


4.2      Rel 16

- Issue resolution for (a) carried, will maintain MUST link between message ordering and use of the AckRequested element. Issue resolution for (b) carried, will maintain MUST link between message ordering and use of the DuplicateElimination element.


Done in 3.2.3 – line 715


4.3      Rel 31

 – Meaning of Guarantee – done in 2.7.


4.4      Rel 32

editorial definition of reply patterns, done in section1.8


4.5      Rel 33

meaning of acknowledgement – done in definition of Acknowledgement message. However, the first paragraph now needs to be removed (lines 177 to 180) since the third paragraph is better.  It was agreed to remove the first paragraph.


This was reopened below.


4.6      Rel 36

- Eliminate message id from WSRM headers, and use the groupID/sequence number as a concatenated unique ID for WSRM identity purposes.  Note: The sequence number defaults to zero for senders that choose not to implement order delivery (though that does not help recipients). -  Search for message ID   Line 251 on page 9 , section 2.4 needs to have messageID fully spelled out.  This needs another check by the editor. 


Question for group: is it worth linking, at least informally, from occurrences of message Identifier back to definition in 2.2.  Leave this as requiring further checks.


4.7      Rel 37

– Use of MessageID – agreed to make URI with rec for MID scheme. Done in Section 3.1.1, however rfcn 2392 does not appear in refs


The sentence” It is RECOMMENDED to use a syntax of Message-ID, as defined in [RFC2392].”


Agreed to editorial change from “a syntax of Message-ID” to “the Message-ID scheme”


4.8      Rel  38

– remove timestamp.  There were some changes made in latest document. These will be closed later. Need to remove the timestamp fault


4.9      General Fault Cleanup

ACTION: Need to endure faults in general being Cleaned up  Sunil will try to get a proposal to clean up fault text before the end of the F2f..


4.10Rel 40

time to live is change to expiry time, and made mandatory.  There is a comment on 3.1.3, which it was agreed can be removed. 


The text states “delivery to the application”, where the definition of delivery uses “next processing entity”. 


In 3.1.3 we agreed to Change “MUST NOT deliver a received message to the application.”  To “ MUST NOT invoke the deliver operation for the received message.”


Agreed to change “modified in any case by Sender,  to “modified in any manner by the Sending RMP”


Sunil : the pictures show the rmp communicating with the receiving application.


It was agreed to reopen Rel 33 to refine the definition of Message Delivery.


4.11Rel 33 reopened


Propsed to Change  resolution to Rel 33: Doug: suggested: add “(application layer)” immediately after the term “next processing entity” in the definition of Message Delivery. Agreed as important editorial.


Doug: either define application layer as next application entity, or redefine ack in terms which are visible on the wire.


Eg:  “message in ordered sequence is not acknowledge until all previous messages are acknowledged.”


Doug: we could eliminate the need for formal definition of delivery.


Tom: Maybe use the term delivery, informally, in the def of ack.  But the formal semantics required for acks, should be defined directly.


Doug: there is no way to test delivery.


Doug: Two approaches

1)      Define application layer, and use as we do in this spec.  This is a little bit messy for a protocol spec.

2)      Do our best to avoid discussion of Application layer matters entirely within a single system.


Jacques: define a delivery operation that every Receiving RMP must support in some application manner.  Then define, send ack after invoking this abstract operation.



Tom:  eg: Delivery – an abstract operation invoked by the Receiving RMP to transfer responsibility for Reliable message.


Doug: delivery can be defined as some operation that transfers responsibility for message shifting from RMP to application layer.


Doug: I agree that for ordered delivery, non ordered delivery of acks is not quite sufficient to cover the semantics we want.


Doug: I like leaving the application layer in the spec, so that ordered delivery has a useful meaning.


Jacques: we should define two abstract operations:  Submit from application to sending rmp, and deliver from Receiving RMP to application.


Tom: Delivery: an abstract operation (implementation specific realization) which is used by the Receiving RMP to transfer responsibility of the Reliable message to the application layer.


Jacques: Require that the RMP invokes an operation called deliver.  Then have examples (e.g, RMP transfers responsibility for the message to the application layer through an implementation specific mechanism, such as putting the message into persistent storage.)


Proposal: add new definitions.

Deliver: an abstract operation the Receiving RMP may invoke per Reliable Message (e.g, a request to the application layer to.take responsibility for the Reliable message).


Submit: an abstract operation the Sending RMP supports, invoked per Reliable message (e.g., a request to the sending RMP to take responsibility for the reliable message.


Notify: an abstract operation the Sending RMP may invoke per Reliable Message (e.g, a notification that the Sending RMP cannot insure that the Requested Reliability feature were realized)


Everywhere else use words  deliver operation invoked” to describe the action of delivery.


Change first sentence of definition of Message Delivery to


“Message Delivery:

 Message delivery is the action of invoking the deliver operation for a Reliable Message.


This is a new resolution to Rel 33.


The group also agreed  to add labels of these operations to the arrows in Figures 1, 2, 3. 7. 8. and 9.   Remove the arrow showing a receiving app invoking an operation on the Receiving RMP.


4.12Rel 44

Senders must not reuse message IDs


Doug: We need to add statement in definition of group id that states it must not be reused.


Change second sentence of 3.1.1 from:

This element MUST have a globally unique identifier as its value.”


“The sending RMP MUST use a distinct globally unique Group ID for any distinct Group of messages.  Any group of messages will have a common Group ID value”


Action: Iwasa to apply changes, then we will change status after done.


4.13Rel 50 Semantics of Expiry Time

Iwasa incorporated the email from Tom, verbatim into the document.


Agreed to close this issue


4.14Rel 51 Message Piggybacking

Proposal:  Enable acknowledgement piggybacking by removing the distinction between Reliable Message and Acknowledgement Message. Specifically:

1)      Remove the MessageType element. – This was done

2)      Any RMResponse element could coexist with other elements."


Change “is containing” to “contains” in definition of message Acknowledgment.


There are problems in English phrasing in four lines:

This Response element can co-exist with Request element, and it enables to send back

Acknowledgment message with the business response to the original message. It also enables

the receiver sending an another independent message to the sender with an Acknowledgment

message to reduce network traffic.


“A Response element can coexist with a Request element, enabling the combination of an Acknowledgment message with the business response to the original message. This coexistence also enables a receiver sending another independent message to the sender with an Acknowledgment message (e.g., to reduce network traffic).”


Doug: we need to globally change (as part of rel 22) the tables “ required – no” to “cardinality – 0 or 1”, and “required – yes” to “cardinality – 1”.


4.15Rel 52 New rules for persistence

Message 70 in December had the agreed resolution.


This added all the new timing rules, and termination stuff.


Section 2.5. and parameters are defined in section 3.


Doug: it would be better to move abstract definitions for the group termination parameters to section 2.  Section 3 should simply state that the “xxx” attribute”corresponds to the abstract definition in section 2.


Move everything after table in 3.1.1 (lines 546 thru 571) into a new section 2.5.1, after the lead in text, pushing the rest of 2.5 down.



A request message MAY contain one of the following

group termination parameters:

a groupExpiryTime attribute

a groupMaxIdleDuration attribute



A request message MAY contain one of the following

Attributes corresponding to the group termination parameters specified in section 2.5.1:

a groupExpiryTime attribute

a groupMaxIdleDuration attribute


Agreed to add new issue to update Section 2.6 “message persistence”, now that we have resolved the timing parameter issues.


Mark Rel 57 as closed.


Leave Rel 53 open until we verify that the changes are complete.


Action: Iwasa is to produce a change barred version of all the changes made from the 1-06 document.  Use compare documents under Edit to do it.


4.16Rel 58 Namespace Identifier update

Done in 3.0 an also in the schema.


Agreed to close this issue.


4.17Rel 82

Agreed to close as resolved by resolution to timing parameters.


4.18Rel 87

Fixes to resolve Rel 87 are in Sunil’s comments in his email from 1/06:



Change second 3.3.1 to 3.4.1 and fix is sub-clause numbers as well.


Delete “(to be added)” from 3.3 and 3.3.1


 - Section 3 (Message Format).

   - replyTo is not an element rather an attribute of ReplyPattern (pgs. 15 & 16) - AGREED

   - For PollRequest, GroupId is a required element (minOccurs = 1) (pg. 16) - AGREED


 - Section 3.1/Table1 (pg. 17)

    - Timestamp should be removed from the child elements. It was removed when - AGREED

    - Many more Faults to be added -  SUNIL Took Action item to complete this.


 - Section 3.1.1/Table 2 (pg. 18)

   - Add InvalidGroupParameter fault to the table (also change INVALID_GROUP_PARAMETER to InvalidGroupParameter on line 555) -  AGREED, but this will be in the new section 2.5.1


 - Section 3.3.1/Pg. 24

    - GroupId under PollRequest is different from GroupId in MessageHeader in 2 ways.

      i) It has zero or more SequenceNumberRange elements - AGREED

      ii) It also has an attribute called 'value'. it's type is the same as the type of GroupId in MessageHeader - AGREED

      (because of REL-94)


  - Section

    - It has 2 attributes called 'from' and 'to', both of type unsignedLong (pg. 24-25) (because of REL-94)  - AGREED to ADD two new attrbutes


  - Section 3.4/ResponseElement (pg. 25).

    - Response Element has only one child element called RefToGroupId. – AGREED to delete ref to seq no range in table and delete line 747


  - Section (now 3.4.1/Table 14  (RefToGroupId/pg. 26)

    - Should have a new attribute called 'value' - AGREED

    - RefToGroupId has an attribute called 'value' of type MIDType and can have zero or more RefToSequenceNumber elements. -  AGREED


 - Section  now 15  (RefToSequenceNumber/pg. 26)

    - Should have 2 new attributes called 'from' and 'to', and no value - AGREED


These agreed changes resolve Rel 87.


Delete (needs updating ) from the new section 3.4.1 section and subsection headers.


4.19Rel 88

Agree it has be implemented in the spec.


Agreed to Close it.


4.20Rel 94 – Polling support

Tom: does it clearly state that the poll can only be done for messages which were originally send with this pattern set.


Sunil: it does state this.


Need to add a section about polling in section 2, with the model.


Sunil: there is no general section on the model for polling.


The header elements are properly defined in sections 3.3 and 3.4.


ACTION: Sunil took action to come up with additions to the model text for section 2.1 by Friday.


Left open until modeling text is complete.


4.21Rel 98 – sequence number usage

The informative note in second para of 2.4 was questioned by the meeting.

Informative NOTE: 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 that message IDs

for groups can be stored efficiently as intervals of integers. 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.

Jacques agreed that the informative not is not needed with normative text.  It could go in implementation guidelines, but we do not have them.


AGREED to remove the informative NOTE.


Doug::  a message that does not contain a sequence number is semantically identical to a message containing the explicit sequence number zero.


Tom: need to update section 2.10 to correspond to 3.1.2.


Sunil: everything is based on existence of sequence no.


Doug: my real concern is that you are allowed to leave sequence number out, but the conditions are not clear.



  • Sequence no is required to be used for Ordered delivery. 
  • Sequnece no is not required to be used for Guaranteed delivery, however it may be present.
  • Sequnece no is not required to be used for Duplicate elimination, however it may be present.


Tom: For interoperability, all receivers MUST be able to handle sequence numbers for non-ordered messages.


Doug: I agree with this statement of Tom.


Tom: For interoperability, all receivers MUST be able to handle non-ordered messages which do not use sequence numbers.


Doug: the sender is deciding whether this “optimization” is used, even though the receiver benefits.


Doug: eg. Sun version only uses sequence number for Ordered delivery.  Fujitsu Receiver RMP works much more efficiently when ordering is used.  In this case the sun sending implementation would make the Fujitsu receiver work very inefficiently.


Doug: we are describing an allowed optimization.  Some senders may choose to generate a new group ID for each un-ordered message, and they would conformant.  The simplest sender may not want to maintain the state of the last sequence number used in each group.  This could be a significant cost for some minimal sending implementations.  It is easier to generate global unique ids, not being concerned with separate integer sequences per group.


Tom: A receiver implementation must be able to deal with singleton groups for non-ordered messages.


Doug: Any receiver implementation of an optimization for un ordered groups is not likely to be exercised, given that may senders will not implement sequence numbers with un-ordered group.


Jacques: Agree that there is no way to enforce the sender to use sequence numbers for non-ordered delivery.  However, if the sender and receiver agree together to use the feature, it would be realized in practice.


The last sentence in 2.2 is incorrect:

Presence of SequenceNumber indicates the Group has more than one message.


Replace with “SequenceNumbers are required only for groups that have more than one message.


Doug: what is def of group. 


Bob: a group is a collection of one or more messages with the same group ID.


Doug: then there can be groups of one.


Doug, there are semantics we do not capture in the text.  The sequence numbers when used must be unique within the group, and monotonic.  We do not say that no two messages in a group can leave out the sequence number.


It needs to be stated

Groups with more than one message must have the sequence number included for all messages in that group.


One logical place for this text to go is 2.10.  This needs to be consolidated with 3.1.2 text on sequence number.


Bob: some of this belongs in 3.1.2, other stuff is in 3.1


The section about groupID needs to be enhanced to discuss the definition of group and its use of sequence numbers.


Jacques- we could have a section to define groups in section 2. 


ACTION: Jacques will make a proposal to fix these group semantic concerns.


Doug has another schema issue with the messageID structure being a sequence with two elements, while the ref to group ID is different.


Have sequence number be a child of group ID would allow more expressive schema.



<xsd:element name="GroupId" type="wsrm:GroupIdType" />

  <xsd:element name="SequenceNumber" type="wsrm:SequenceNumberType" minOccurs="0" />


Doug proposed to unify the schema for the message Id with the schema for the refs.


Agreed to change “SequenceNumber” to “SequenceNum


Agreed to keep name of the attribute of  a new messageId element  groupId


Change name “RefToMessageID” to

  • RefToMessageIDs
  • RefToGroupedMessages
  • Ref toMessages
  • RefToMessageIdSet
  • RefToGroupSubset
  • RefToSubGroup


The winner was RefToMessageID.









Action: Jacques is to

5         Editorial Cleanup

Sunil sent the following email against the 1/04 draft:

Hi Iwasa,




 - The Termination conditions (in pg. 11) uses GroupExpiryTime and GroupMaxIdleDuration.

   It should be consistent with the actual attribute names (starting with lower cases).


 - When attributes are mentioned in the Table, please list their types. Ex. status (string)


 - ReplyTo attribute (in Section 3.1.4/pg. 21) should be replyTo (all attributes start with lower



 - Please add the schema as an appendix


 - Section 2.4/Line no. 259.

   It should read "after the message has been processed and delivered to the "next processing layer".


 - Figures 1-2-3 on pgs. 8-9 may need to be updated to show the "next processor entity" as per our

   new definitions.


 - All the new terms such as Group Termination, Removal, Complete etc... should be defined

   in the terminology section





AGREED to accept these editorial comments


5.1      General Parameter Name Cleanup

e.g. ID, Identifier, Number, etc.


Agreed to add a new issue


6         Discussion of UML State Charts


Tom showed two simplifications to the state diagram he sent out in early Jan:


1)      The sending of an expiry fault was removed from the state machine.


2)      the ack of duplicate delivered messages was removed.  It is proposed to simplify by not acking duplicates.


There was a large number of concerns about the second change.


Doug stated it is not good to have the sender keep resending in a lost ack case and never get an ack.


Jacques stated his major concern is the ability for the sending rmp to be sure that the earlier receipt of the duplicate message was actually delivered.


Tom stated: if the messages was received, and it is not in the held queue waiting for prior, then you know it is delivered.


Doug: there are other ways to know the message was delivered.


Tom: the key point is whether the protocol requires the Receiving RMP to know what messages were received as well as what messages were delivered.


Agree do not ack a resend on a held message, also do not ack an expired message.


Tom will prepare a new receiver state diagram reflecting these simplifications to send out for review.




Agreed that duplicate of held message will not have to be acked.


7         Homework assignments and meeting recess

Iwasa will come up with a new doc, change marked against 1/6


Doug will send out a new issues list.


Tom Will send out new receiver stae


Jacques will send new proposal for group and sequence.


Sunil will send email about schema changes for group ID.


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