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: Preliminary Thursday minutes of WSRM TC meeting

The prelim Thursday minutes are attached.

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

Title: Thursday:

Preliminary Thursday WSRM Minutes

Thursday: Oct 30, 2003

8         Review of Homework Assignments/proposals

8.1      Group Termination

Email from Jacques with Tom Rutt comments

> Jacques Durand wrote:


>> Here is a proposal which, I believe, should address all concerns heard this afternoon,

>> first and foremost from Sunil. (Close to what he proposed in fact, but with nicer handling of "corner cases"

>> It looks a bit detailed, but I believe is in fact very "implementable".


>> Jacques


>> -----------------------------------------------------------------------------------------------


>> Background:

>> Let us start with precise semantics: We had 3 possible (non -exclusive)

>> semantics for expiryTime:

>> (1) business semantics (how long a message still makes sense for the application)

>> (2) RMP management semantics (how long should we try to make available to the app

>> before giving-up)

>> (3) dup elim semantics: when "at most once" is required, a message should be subject

>> to dup elim as long as it has not expired.


>> So far, our spec mostly talks of (2).

>> Several of us believe it is none of RMP business to enforce (1).

>> As for (3), there is an obvious impact from (2), as by definition, a duplicate of

>> an expired message would never be delivered, even if we skip the dup check.

>> That mostly spares us a dup check.


>> General approach: we endorse semantics (2) and (3).

>> For individual messages (group singletons), dup check is done over all past

>> messages that have not expired yet, and we keep this mesg ID store up-to-date.

>> But for groups, we do not want to have to store each message expiry time,

>> along with message IDs (GroupId + seq number). That would undermine the

>> fast and space efficient check that groups are supposed to provide in general.


>> General Proposal:

>> - we keep everything of what has been "decided" (or formulated for decision) so far.

>> - we still assume each individual message of a group has expiryTime.

>> Like for singletons, a message in a group would not be delivered to app if it has expired

>> when received. However we do NOT memorize this expirtyTime after first check.

>> (of course, in case we need to keep all undelivered messages of a broken sequence on receiver,

>> we keep the entire messages and therefore their expiryTime. We decide to give-up

>> if the max of all expiryTimes of waiting messages has expired.)

>> - for the sake of simplicity, the receiver RMP will keep the ID of all past

>> messages for an active group, whether expired or not.

>> That is, once they have been delivered to app, RMP will NOT try to

>> manage expiry time of past delivered messages, and will NOT discard from memory

>> the message IDs of those expired, like it would for singletons.

>> Duplicate checks would be made over ALL past messages for the group, whether expired or not.

>> There is no added cost in fact, as these IDs are remembered as seq num intervals.

>> Will even be faster, as not discarding means fewer intervals.



>> Refined Proposal when groups terminate:


>> NOTE: In the 3 following termination cases, "discarding" a group means removing

>> everything (state, msg IDs, message bodies), and not doing anymore

>> duplicate checks for these. Any late message from this group will be treated

>> as from a new group.


>> Termination (t1): when a group terminates because its GroupExpiryTime is over,

>> it is completely discarded from RMP (state, message Ids and payloads).

>> No duplicate check is done against that group ever. If a "late duplicate" arrives,

>> it would be automatically discarded due to its expiry time.


>> Termination (t2): when a group terminates because its MaxIdleTime is past,

>> its messages may not be expired yet. We do not keep expiryTime of each message

>> of the group, however we keep the max of all expiryTimes of messages received

>> so far. We use this max as the GroupExpiryTime, and wait for this time -if needed-

>> before discarding the group. We fall back then to termination (t1).

>> In case a new message arrives after maxIdleTime expires but before the group expires,

>> we need to define what to do: I suggest we process it and keep bumping up the max

>> of all expiryTimes if needed (so dup check still enabled for the group).


>> Termination (t3): when a group terminates because it receives a status="end" message.

>> Note that this only tells us "no greater seq number will be received after".

>> Like in (t2), its messages may not be expired yet. We treat it like in (t2): the max

>> of all expiryTimes tells us when the group should be discarded, and not subject

>> to duplicate check. The group may still have missing messages that are late. Subcases:

>> (3.1)If the group is complete, still use max of expiryTimes before discarding it.

>> (so dup checks still possible, but we know are useless after that.)

>> (3.2) If group has missing messages, wait for these to the extent allowed by

>> either GroupExpiryTime, or maxIdleTime  (whichever was specified), then fall back on

>> either (t1) or (t2) respectively.





Tom Rutt:, given we relax the condition of requiring at least one of the two groupExpiryTime or GroupMaxIdleDuration. (i.e., both are truly optional presence):  add a new termination condition:


T4) If there is neither a groupexiryTime nor a GroupMaxIdleTime, derive a CurrentGroupExpiryTime as the max expiryTime of all received messages in group.  Then use t1 criteria.



Message ExpiryTime is under control of the sender.  If  the receiver keeps an ongoing calculated

statistic of the "maximum expiry time over all messages received in this group", and uses that as the

GroupExpiryTime, it will be a more conservative algorithm than any of the three in Jacques proposal.


The MaxIdleInterval was there to terminate open ended sequences.  Keeping a current statistic on the maxExpiryTime for messages received for this group also terminates open ended sequences.


This also takes away what would be a source of error, users not knowing how to determine

the correct groupExpiryTime, before starting a group.



>> Termination (t3prime): when a group terminates because it receives a status="end" message – Delete the group state information as soon as all the messages with smaller sequenceNo are delivered to app.  Do not start group until the “start” message is received.



Bob F – Duplicate elim has to work the same within or without a group.  We have the messageId (groupID,OptSeqNO) and expiry time which are what is used for duplicate elimination.


Bob F – we may not need group terminition parameters for criteria.  Construction of group is complicated by allowing un-ordered group.


Sunil’s optimization is to save space for holding state on the receiver side.


Bob: two conditions:

- Explicit Stop, -  then  wait for all received messages to expire before removing group persistence

- Last message received for that group has expired.


General concensus on Jacques proposal plus the additional t4 condition to cover case when neither groupexpiryTime or GroupIdleInterval are present for the group.


8.2      Figures for Section 2 Model

Iwasa presented his new figures for section 2, at http://www.oasis-open.org/archives/wsrm/200310/msg00100.html


It was pointed out that “(reliable message)” must be attached to the top arrows for the three proposed section 2 figures, as is done for the (Poll), and (Ack, Fault)


In section 5, RM Request should be changed to (reliable message) in all the figures, and “RM Reply (ack, fault)” should be “(Ack, Fault).


9         Timing Issue Resolutions

9.1      Rel 50 semantics of ExpiryTime


Agreement that ExpiryTime has following semantics (from Jacques proposal above):

>> 1) RMP management semantics (how long should we try to make available to the app

>> before giving-up)

>> 2) dup elim semantics: when "at most once" is required, a message should be subject

>> to dup elim as long as it has not expired.

The first semantic, 1) is already in the spec, however we need to add the second semantic, 2), to the spec.


Should clarify that the semantic 1) has repercussions on the sender’s and the receiver’s persistence requirements.


Doug: What happens when app does not retrieve the messge on the receiving side, even though it is in the rmp queue for delivery to the app, and that message expires.  This is a distributed state management issue. 


The text in 1) is ambiguous. 


Doug::  we need to avoid the receiver Eventually giving up with the sender not knowing the receiver has given up.  Do not want to have the sender think the message was delivered, when, in fact, the rmp has given up before the message has been delivered to the receiver app.


Can have either:

  • Expiration time is checked once and the receiver rmp never gives up trying to deliver to the receiver app after it has acknowledged that message, or
  • have a way to return a fault to sender before giving up.


Sunil: Alternative could be to send ack only when the rmp makes available to the user.  However, we dismissed this alternative at past meetings.


There are places where we have acked a message, but later it is thrown away because the group is terminated.


Doug would prefer the message is never thrown away once it has been acked (except for terminating a broken sequence).


Jacques;  as soon a message has been acked (except for broken sequence condition) it must always be made available to the user.


1) RMP management semantics - When receiving a message, the RMP will not process it  further if it expired).


The text in 2) is ambiguous.  There are two queues, one where the rmp is holding an unordered message from being made available.


>> 2) dup elim semantics - when "at most once" is required, a message should be subject

>> to dup elim as long as it has not expired, .or was not discarded by the RMP due to an unrecoverable broken sequence with ordered delivery in use.


Sunil case: Later message expiring while orderedDelivery buffer is waiting for a message -


Doug:  The broken sequence case is not a problem, with the Jacques proposal.  For the broken sequence case, the sender knows that at least one of its messages in that sequence was not acknowledged.  The sender can throw a message in its sending buffer always once that message and all the messages before it have been acked.


Need to avoid:

Have a broken sequence, the missing message arrives and is acked


Ack means that the receiver rmp has received the message, and will deliver it to the user unless

  • any messages with lower sequenceNo than that acked message have not been received by the time that: the group persistence (groupID, receivedSeqNO list, outOFOrderMessages not yet made available to receiving app) is removed by the receiver rmp, due to group termination conditions


Ordered example 1

group expiry 10pm

1 – exp4pm (start) sent at 0 pm

2 – exp8pm (continue) sent at 0 pm

3 – exp 4pm (end) sent at 0 pm


receive 1 -  at 1pm ack and made avialble to user

recieve 3 – 1.05 pm then ack and buffered (not made available yet, waiting for 2 until group persistence removed due to termination conditions firing, do not terminate at 4Pm

2 is never received.


Group is terminate at 10:pm – terminate group, removed 3 from group persistence buffer (i.e, will not  be made available to user)


Ordered example 2

without GroupExpiryTime and without GroupIdleInterval

1 – exp4pm (start) sent at 0 pm –

2 – exp8pm (continue) sent at 0 pm –

3 – exp 4pm (end) sent at 0 pm


receive 1 -  at 1pm ack,  derived get=4pm  then make avialable to user - 

recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made available yet, waiting for 2


4pm – group terminated, 3 removed from messageOrder queue, will not be made available to use.


receive 2 – at 6:00 PMacked and start new sequence. Derived get=8pm, will be buffered waiting for 1


8pm – terminate new sequence, remove 2 from buffer will not be made available to user.


Ordered example 2 has the problem that the sender has all three messages acked, however 2 was not made available.


Ordered example 3

GroupExpiryTime 8:00pm

1 – exp4pm (start) sent at 0 pm –

2 – exp8pm (continue) sent at 0 pm –

3 – exp 4pm (end) sent at 0 pm


receive 1 -  at 1pm ack,  derived get=4pm  then make avialable to user - 

recieve 3 – 1.05 pm then ack – derived get=4pm, and buffered (not made available yet, waiting for 2


8pm – group terminated, 3 removed from messageOrder queue, will not be made available to use.


8pm – terminate new sequence, remove 2 from buffer will not be made available to user.


receive 2 – at 9:00 PM – expired, not acked and do not start new sequence.




Sunil pointed out that the processing rule from wed minutes no longer holds

    • any information persisted in receiver RMP for a message in the group is removed from persistent store when the message expires.


Need to leave all timing issues open, for further discussion on email list.


We agreed at last f2f meeting to Weekly telecom hourly meetings, (2:30 TO 3:30 pm , until end of December).  Starting Nov 4.


Rel-50 – semantics of expiryTime

REL-52: New rules for persistence

REL-57: Ordering and Missing Message Behavior

REL-97: GroupID lifetime (RemoveAfter)



10   Implementation  Conformance Discussion


Conformance Matrix for Sender



Guaranteed Delivery

Duplicate Elimination

Message Order














Conformance Matrix for Receiver



Guaranteed Delivery

Duplicate Elimination

Message Order














Tom stated that the conformance matrix for sender implementations should be granular.  The sending application must be able to do the things that it indicates in the headers of the messages it sends. 


Thus a sending RMP is free to implement any of the nine cells of the conformance matrix.


To assist interoperability, we should partition the receiver conformance matrix into a small number of conformance classes.  One example follows with two conformance classes for receivers (basic and enh):


Example 1) Receiver conformance with two levels of conformance


Guaranteed Delivery

Duplicate Elimination

Message Order


Level1, Level2












      Under example 1 - All receiver  implementations MUST support Basic conformance class, MAY support Enh conformance class.


Example 2: - nine independent conformance classes, sender pick whatever it wants to implement

Conformance Matrix for Receiver


Guaranteed Delivery

Duplicate Elimination

Message Order














    A receiver MUST implement at least one of the nine conformance classes in the matrix.



Example 1 ensures greater interop out of the box,


Example 2 will leave more senders unsatisified.


Another example


Example 3) Receiver conformance with another two levels of conformance


Guaranteed Delivery

Duplicate Elimination

Message Order














      Under example 3 - All receiver  implementations MUST support Level1 conformance class, MAY support one or more of the classes O2 thru O8.


Put this to the email list for discussion.


Discuss this further on the list.


11   Discussion of Committee Draft Timing

From the Procedures:

Approval of a Committee Draft


Upon completion of a specification the TC may approve the work as a Committee Draft. The approval of a Committee Draft shall require at least 2/3 of the total membership of a TC voting to approve and no more than 1/4 voting to disapprove.


OASIS TC Administration must be notified at the completion of any ballot to approve a Committee Draft, regardless of the outcome of the ballot.


The name of a Committee Draft may not include any trademarks or service marks not owned by OASIS. The Committee Draft must use the OASIS-approved document templates and naming, and must include the OASIS copyright.

(b). Approval of an OASIS Standard


Public Review


Before the TC can submit its Committee Draft to OASIS membership for review and approval as an OASIS Standard, the TC must conduct a public review of the work. The decision by the TC to submit the work for public review requires a majority vote. The review must be announced by the TC Administrator on the OASIS members mail list and optionally on other public mail lists. Review must take place for a minimum of 30 days, during which time no changes may be made to the document. Comments must be collected via the TC's archived public comment facility. The TC must record the comments received as well as the resolution of those comments.


The TC may conduct any number of additional review cycles (i.e. collecting comments, making edits to the specification, sending out a revised version for review again, etc.) before deciding that the review is complete. If substantive changes are made to the specification after the start of the public review then the TC should conduct another review cycle. After the conclusion of the review and final changes to the document, the TC must re-approve the work as a Committee Draft before submitting it to OASIS.


A first committee Draft requires a 2/3 yes vote of the TC.  However, the TC may have subsequence ballots for further Committee Drafts, before attempting the vote to put out for member review.


Thus, to have a “Committee Draft” at the time of the Demo on Dec 9, we should have voted 2/3 yes on a ballot for First committee draft.  To allow a two week ballot to be active on Dec 9 (Monday) the Ballot for first committee draft must go out on Dec 2, after the TC teleconference..The ballot should close at 5:00 PM Pacific time on Dec 15


Dec 2 – issue ballot for first CD

Dec 15 – ballot closes

Dec 16 – TC meeting to determine next step


Most likely we will need several weeks to produce a second ballot for Committee draft. 


Realistic target for the issuance of second ballot for Committee draft is middle of January.


Agreed to have Next f2f during week of Jan 12, in the SF Bay area.  Specific days of that week and Host will be decided in the next few calls.


No conference call on demo day Dec 9


We will have weekly one hour TC conference calls, from 2:30 to 3:30 Pacific time on

Nov 4, 11, 18, 25

Dec 2,  16

Jan 6,


12   Resolving Issues with Proposals

12.1Rel 78– meet compatibility requirement R8.1



  <title>Meet <b>Compatibility, R8.1</b> requirement</title>


  <section />




  <originator />

  <responsible />

  <description>The Specification should be usable with other

  open standard technologies, if appropriate.<br />R8.1.1<br

  />The Specification shall not preclude the use of Web

  Service message attachments.  (see also issue <a

  href="#xREL-10">REL-10</a>)<br />R8.1.2<br />Insure that

  the Specification is usable in combination with WSS SOAP

  Message Security to implement secure reliable messaging.

  (see also issue <a


  <proposal />

  <resolution />




Iwasa sent an email to resolve the attachments part of this issue after editing the group came up with the following proposal


Proposed Resolution regarding attachments portion of the issue:

Create a new section "Section 2.9 Attachments" and include the following description:

2.9 Attachments

When this spec is used with W3C note “SOAP messages with Attachments” specification, the following rules MUST be met:

 1) The first MIME part MUST include whole SOAP envelope

     with WS-Reliability header elements.

 2)  The charset of the Content-Header of the first MIME part MUST be either UTF-8 or UTF-16.

 3) Zero or more additional MIME parts MAY be included in a reliable message.

 4) The receiver RMP MUST make available, to the receiving application, all MIME parts in a reliable message




W3C SOAP messages with Attachments:



Agreed:  Split issue 78 to move attachments portion to a new issue 100. 


Amend Issue 78 to remove reference to Soap With Atachments.


Agreed to record the  proposed resolution above as a pending resolution to new issue 100.


Confirm pending resolution at a future TC teleconf.


12.2REL-31: Meaning of guarantee


REL-31 Spec 1.1.2 def Design Unassigned  Peter Furniss


Title: Meaning of guarantee


Description: Meaning of guarantee needs to be defined (i.e. it is OK to announce

failure of meeting guantee in a particular case)

Related to crash tolerance, see REL-5

When is a guarantee not a guarantee? Message corruption issue may come up

here. Should be specifying a protocol and its failure modes (relatively complete).

One case: Recipient loses all of their message identifier store and can no longer

detect duplicates. Recipient system failed and sender is not notified. Outside

the scope of the protocol, one of the partners no longer playing. Need to

document the limitations of the protocol. (Cannot document correct error

message for case where sender of that error does not know what is going on.)



Iwasa sent the following mail:

Here is a proposal for REL31:


Guaranteed delivery -  To deliver a message from a sender RMP to a receiver RMP without failure, or to report failure to the sender's application. To realize guaranteed delivery, the message MUST be persisted in the sender RMP until it delivery to it's receiver is acknowledged, or until the ultimate failure is reported to it's sender.  There is a requirement of the underlying transport protocol that the message MUST be transported without corruption (i.e, the transport protocol will not let corrupted messages arrive at the receiving RMP).


When message persistence is lost for any reason, it is no longer possible to continue to guarantee message delivery.  Since the reliability of message persistence is A property of the system implementation, the conditions under which guaranteed message delivery holds is also a property of the system implementation..


Example 1). A PC Server may use a HDD for it's persistent Storage, and those messages persisted in the HDD are reliably maintained even if the the system software crashes and the system is rebooted. However, if the HDD itself crashes, it is no longer possible to guarantee message delivery


Example 2) . A message persisted in a mobile phone may be lost when it's battery is detached. In this case, message delivery is only guaranteed by proper battery maintenance of the mobile phone.


Agreed to record this as a pending resolution to issue REl 31.


12.3REL-32: Add new terms from requirements


REL-32 Spec 1.5 def Editorial Active  Iwasa

Title: Add new terms from requirments

Description: See resolution for definition issues. 



Iwasa email:

Here is a proposed resolution for Rel-32:


Add the first seven definitions in Requirement document

at Section 3.2 Definitions to the Specification

at 1.8 Terminology.







From Requirement document:




Reponse RM-Reply Pattern :

    We say that a response RM-Reply pattern is in use if the

    outbound Reliable Message is sent in the underlying protocol

    request and the Acknowledgment Message (or RM-Fault

    message) is contained in the underlying protocol response

    message corresponding to the original request.


Callback RM-Reply Pattern:

    We say that a callback RM-Reply pattern is in use if the

    Acknowledgement Message (or RM-Fault message) is

    contained in an underlying protocol request of a second

    request/response exchange (or a second one-way message),

    operating in the opposite direction to the message containing

    the outbound Reliable Message.


Polling RM-Reply Pattern:

     We say that the polling RM-Reply pattern is being used if a

    second underlying protocol request is issued in the same

    direction as the one containing the outbound Reliable

    Message to act as a request for acknowledgement. The

    Acknowledgement Message (or RM-Fault message) is

    contained in the underlying protocol response to this request.

    This polling pattern is expected to be used in situations where

    it is inappropriate for the sender of reliable messages to

    receive underlying protocol requests.



Agreed to record the above as a pending resolution to Rel 32.

12.4REL-34: Figure 4 needs refinement


Resolved by current Spec draft.


Close issue as resolved by current draft.


12.5REL-35: Header processing order

REL-35 Spec  meta Design Unassigned Scott Werden  
Title: Header processing order 
Description: Need to determine impact of header processing 
order, particularly when used in conjunction with WSS.  
Mail from Iwasa:
Here is a proposed resolution for Rel35:
Unless otherwise agreed between sender and receiver,
security related header(s) must be processed before any
reliable messaging header specified in this spec
is processed, when this specification is used with
security related specifications.


Sunil:  Is this requirement on the RMP or the soap processor?


It was agreed that such a statement is outside the scope of this specfiction.


Agreed to pending resolution of issue 35, as Closed with no action, because it is outside the scope of this spec.


12.6REL-82 to REL-86: Parameters

Agreed to leave open until after resolution of the protocol timing parameters.


12.7REL-87: New WS-R Headers


Leave open until after resolving protocol timing parameters block of issues.


12.8REL-94: Polling RM-Reply Pattern design


Agreed to pending resolution from Sunil’s latest email (also in Wed minutes).


12.9New issue from Tony Graham

Doug stated, for interop purposes we need to describe what are the specific rules for comparing URI values in our specification.


Eg, is case significant,


Eg. Is padded white space significant






Doug stated we should align with the W3C TAG discussions on this matter.


Agreed to add this as a new issue Rel 101.


12.10                        From and To

Jacques asked for clarification of why we removed from and to elements from the earlier draft.


Tom Stated we made this decision because the protocol does not use either of them.


Sunil stated that all headers are extensible, and an implementation could put them in the extension, however that would not be interoperable.


Jacques stated that we could add a clarification statement into the specification on why from and to elements are not included in the protocol.


If anyone provides such  proposed clarification text, the TC should review it.


12.11                        Rel 38 –Timestamp

Agreed to pending resolution of closing issue 38 by removing timestamp.


13   Wrapup


Action: Iwasa to provide the next draft spec before the next TC meeting.


Action: Sunil will distribute a new pending schema document to the email list, but will not post it to the server.


The meeting participants thanked Pramila and France Telecom for the excellent hosting arrangements for the meeting.


Motion to adjourn by Marc G, seconded by Sunil


Adjourned at 4:25.


Put pending issues resolution as first thing on agenda for Tuesday.

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