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 9-16 meeting

Attached are the prelim minutes

Please respond with corrections by Thurs PM.

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: Draft Agenda to WSRM TC Conference Call – May 06, 2003


Prelim Minutes WSRM TC Conference Call – September 16, 2003



The meeting of the WSRM TC took place by teleconference 
Tuesday August 26, 2003, from 5:30 to 7:30 PM Eastern Daylight Time
(UTC - 4)
The call in details wer as follows :
Dial-in numbers: 
Toll Free - : 1-800-605-5167 
International - : 1-719-457-0339 
Passcode: 732072 

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call – Sept 16, 2003
    1 Roll Call
    2 Minutes Discussion
    2.1 Appointment of Minute Taker
    2.2 Approval of previous meeting minutes
    3 Discussion of Issues:
    4 Discussion of Interop Demo at XML show, and status of Subgroup
Discussion of Charter and the XML 2003 issues.
Decided to do this first part limited to 20 minutes.

1         Roll Call

First Name

Last Name






Booz Allen Hamilton




Cyclone Commerce











TC Chair

























NEC Corporation




NEC Corporation
























Sun Microsystems




University of Hong Kong




webMethods, Inc.




WRQ, Inc.




France Telecom

Meeting was quorate.



Jamie Clark, from OASIS staff, joined the call

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Marc G agreed to take issue resolutions.


2.2      Approval of previous meeting minutes


Boston f2f minutes:

Alan  moved to accept minutes, Bob Freund seconded.
No opposition, minutes minutes approved.


3         Discussion of Feasibility Demo Activities

3.1      Proposed charter

Jacques sent out the following email:



After discussion between demo participants, and trimming all that is not essential,

the proposed charter of the POC / Interoperability subcommittee would be:


1- To provide a forum and an environment for implementers of the WS-R specification, for testing and ensuring interoperability across implementations.


2- To provide test tool standards, specifications, and test case definitions,

for those choosing to participate in interoperability testing of WS-R implementations.


3- To provide specific feedback to the TC regarding WS-R implementation

experience and specification issues.


4- To provide POC and demonstration capability for the promotion of this specification.


For review and comments...


Jacques stated detailed comments are welcome on the list.


Doug B stated the first item using the word “and ensuring” is against the sense of the f2f meeting discussions.   We should not take on the ensurance. 


Bob asked if it could be changed to demonstrating.  Doug B stated it would help.


Agreed to change draft.


Need agreement on the wording of the charter.


The subgroup chairs will prepare charter


3.2      Demo at XML show

Bob F stated that he and Jacques have been discussing improvements on the demo mechanics.


They will need to find a visually appealing way to do this with a single projection screen for audience.


They think they have enough participants to make it real.  Hitachi, Fujitsu, NEC and Oracle are still committed.  However this is a more exposed environment, and they will endeavor to dry run in the middle of nov.


The conference is Dec 7th.


Bob F has taken the task to draft the abstract.  This is ˝ page of text.  Look at that from email.


Jamie Clark of OASIS staff stated that he is willing to review the abstract request. 


Alan asked if the abstract is about the demo.  The Sept 29 deadline is hard.


Bob F stated he would send the draft to TC.   XML 2003 has farmed the task to them.


Jamie Clark stated that working it thru them.


Our next meeting is one day after the due date.


They are taking a realistic use case as a demo, to demonstrate the core of the fundamental three features:

  • Guaranteed delivery
  • Duplicate elimination
  • Ordered delivery


They will not exercise all the options.


Jamie suggested that we are only constrained to choice of use case and bullet point description by end of month.


No objection to having an informal email review by tomorrow.  


Alan Weisberger volunteered to have a paper which describes other features, why just three.


Alan is proposing a white paper handout.


Bob F stated that contributory collateral material is a welcome addition.


Alan stated he will draft such a small white paper.


Bob F stated there is a need to focus the time.


Expect the Draft spec of WSRM by end of month. 


The expectation is the next demo will be using the current draft.


Target is to have the review complete by next Tuesday, He will incorporate into a Tuesday time frame.  Bob will complete this


By next Tuesday. 



4         Discussion of Issues:

Latest issues list at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3529/wsrm-reqm-issues.html


4.1      Rel 39 Revisited - Definition of Reply pattern

Doug Bunting sent out the following email:
Noticed as I was re-reading through these minutes...
This may be an editorial issue even though we agreed to specific words in this resolution.  The new text in 3.2.2 tells implementers they must always provide some type of response to the sender.  To avoid this confusion, I suggest each description of rm:ReplyPattern values be changed slightly.  How would the group like to handle this issue (as an editorial matter or a new technical issue)?
BTW, what does "MANDATORY" mean?  Is that some new terminology for "in every compliant WS-Reliability message"?
We currently have:
3.2.2 RMReplyPattern Element
The RMReplyPattern element is used for a sender to indicate what RM reply pattern is requested. The RMReplyPattern element is a MANDATORY element. This element is used to specify whether the Acknowledgment Message (or RM fault messages) should be sent back directly in the reply to the reliable message, in a separate callback request, or in the response to a separate poll request.
This element MUST have one of the following three values.
   - Response : An Acknowledgment Message (or RM Fault message) MUST be sent back directly in the Reply to the Reliable Message.  This pattern
is not applicable for one-way application level MEP
   - Callback: An Acknowledgment Message (or RM Fault message) MUST be sent as a callback request, using the address in the  ReplyTo element
   - Poll: An Acknowledgement Message(or RM Fault message) MUST be sent as a response to a poll request
The last should instead say (modulo additional word smithing, maybe
   - Response : Any Acknowledgment or RM Fault message the receiver needs to send in reply to this message (any message generated by the receiving RMP with RefToGroupID and RefToSequenceNo equal to the value of this message's GroupID and SequenceNumber, respectively) MUST be sent back directly in the Reply to the Reliable Message.  This pattern is not applicable for one-way application level MEP.
   - Callback: Any Acknowledgment or RM Fault message the receiver needs to send in reply to this message MUST be sent as a callback request, using the address in the ReplyTo element.
   - Poll: Any Acknowledgment or RM Fault message the receiver needs to send in reply to this message MUST be sent as a response to a poll request.

Doug moved to accept his proposal, Jeff turpin seconded.


Nobody opposed, Motion passes.


Sunil stated the non applicability to one way application level MEP.  The requirements document was changed.  R 3.5 states callback is only for one-way.


Sunil stated such a statement was added for response, so the negative statement should be made for callback.


Add statement “This pattern is not applicable for request response application level MEP.


Global change on the overall use of application level MEP.


Doug stated we are addressing more issues than required at this time.


Doug moved to accept the original proposed addition, with the current wording. Sunil seconded.


No opposition, will add to resolution of 39.

4.2      Rel 57 About Ordering

Jacques stated that issue rel 57 has other things behind it.


There are two definitions of ordering which have been discussed.


Since guaranteed delivery is required with ordering is the one which is the most strict.


Jacques proposed two definitions.  One allows holes, the other that does not tolerate any missing message.


The second one is the one we have consensus on. 


Thus Issue 57 is easy to resolve.


Option a) from Scott, is in line with this more precise definition of ordering.


Resolution for 57 is a), with a more specific definition statement to avoid misunderstanding.


This statement is buried in section 3 already.  From editorial view it should be brought into.


Doug stated this issue was added directly based on scott’s email.


Doug questioned the summary of Jacques.  He agrees with the sentiments, but he is unsure about how to handle a fault sent after an acknowledgement.


Doug stated this is either a sub issue to this one or a new issue.


Jacques this should be a sub issue. 


Doug B stated that a fault to the originating system is a good thing, however it could cause problems.


Doug B suggested we record the direction to go with option a), but to keep open the details of the fault returned.  We should leave it open as a part of 57.


Doug B stated we keep it as one issue with a common status.  We have a general direction, but need to keep the issue open for the fault details.


Action: Jacques will give a shot on how long to wait for the missing message.  He will list all the possible options for discussion on email before next meeting.


He had an issue about the optional sequence number.  He will discuss this on the email,


For now we will.

4.3      Schema for Headers

The following proposal was sent by Sunil:

All -


 Before Scott & I work on the Schema for the RM Headers, we would like to

 know that this is what we have decided so far. Please correct us if we missed

 something or didn't capture any resolution properly.






     - GroupId - "mid URI" scheme from RFC2392 - Mandatory

     - SequenceNumber - unsignedLong – Long (required for ordered delivery)

       --   status attribute - xsd:string -  Begin, Continue, End

     - TimeStamp  - UTC  - Mandtory

     - ExpiryTime  - UTC - Mandatory

     - ReplyPattern -  xsd:string  - Optional

       - replyTo attribute - uri  - Optional



     - AckRequested  - Optional

     - DuplicateElimination  - Optional



   RefToGroupId - "mid URI" scheme  from RFC2392 - Mandatory

   RefToSequenceNumber - unsignedLong - Optional


Fault - QName - Mandatory







URL Location:





Sunil wanted to change MessageHeader to MessageInfo.


John Fuller, we are changing other names from ebXML.  Is there a reason for this.


Sunil stated the names have been changed on a case by case basis.


The group did not agree to the name change of MessageHeader to MessageInfo.


The namespace listed is not correct.  The url ids at the bottom are the two namespace we chose.


There is an agreement on Rel 58.  The resolution does not include the proposed urn and http scheme urls.  We decided to go to the http scheme.


We also decided on a schema name from the meeting minutes.


Doug stated the urn scheme uri’s are now irrelevant, because we decided to go the http scheme.


Target namespace should be urn.


Sunil or scot has enough info to post a schema before the next meeting.


4.4      Rel 27  28, 41

Marc G stated these were moved to accepted instead of closed.


Rel 27

Rel 28, Application level synchronous message.


Rel 41 – ack requested name change  change to Closed


Marc G moved to close rel 27, 28 and 41 with no action


Nobody opposed, will change status to closed.


It was clarified that we are Supporting request response application type.


This is tied to requirements doc.


4.5      Issues completed in spec

Rel 36, Rel 37, Rel 44, Rel 88 are completed in the spec.


Two others are Rel 51 and Rel 58.


Iwasa agreed that rel 51 and 58 are completed in the spec.


Mark moved to mark the above issues as completed.  Iwasa seconded.


No opposition, motion passes.


4.6      Poll mechanics

Sunil sent mail:



  I'd like to propose to have 2 new Headers:





  StatusRequest will be the Header used by the Sender to send a poll/status

  inquiry to the Receiver. It will have 2 sub-elements. A mandatory GroupId

  and an optional SequenceNo. The types for these are the same as the ones

  in MessageHeader element.



      - GroupId  - Mid URI type - Mandatory

      - SequenceNo - UnsignedLong - Optional


  StatusRequest can be sent without a MessageHeader and hence can be

  piggy-backed on another Request or can be batched with other status requests.


  StatusResponse Header will be used by a Receiver to send the status back

  to Sender. It will have the following sub-elements:

        - RefToGroupId      -  mid URI type - Mandatory

        - RefToSequenceNo - unsigned long  - Optional

        - Status                    - QNAME        - Mandatory


  Possible Status Values are:

        - InvalidGroupId -  When the GroupId is invalid or un-recognized

        - InvalidSequenceNo  - When the SequenceNo is invalid or un-recognized

        - MsgExpired - When the message was expired (based on ExpiryTime)

        - MsgReceived - When the message was received and ack-ed by the RMP/


  Since all our Header elements are extensible, Implementations can extend with a

  new element called 'sub-status' and send more implementation specific details

  if desired. But I prefer that Spec. level requirements for Status be simple.


  Multiple StatusResponse(s)  can be batched or can be piggy-backed on Response.


  We should be able to share the above Status values with Fault Codes. Note both

  are QNAME types and hence shareable.


  Error due to StatusRequest processing will result in a Fault with error code





Sunil came up with two states for the message. 


Sunil clarified that each header element is for a single message being polled.


Sunil stated the persistence requirements are the same for this as for other mechanisms.


Tom Rutt stated that the persistence limitations is part of the contract between the user and the web service implementor.


The polling can be used for request response or one way.


In Sunil’s  proposal Poll response with message received is equivalent to an ack, and serves as an ack for our protocol.


Doug stated this proposal is also able to satisfy the status inquiry message.


Sunil stated that he decided to make the poll operation very simple, but it still may handle the query requirement.


Doug B stated that his feeling on this proposal is not complete enough to be accepted as is.  It is currently phrased as a response to the polling, but does not describe how to use it in a polling scenario.  It does not show how to use this as a query, even if the Ack was sent the normal way.


Doug B stated this needs to be clarified with respect to the semantics for the various patterns it is to support.


Sunil agreed he could add that in the next version.


Doug B stated this is higher level than RMP signals.  This is asking to search for status of things received sometime in the pass.


Doug B stated this is above the other RMP signals.  It is effectively a different action that the other end is being requested to take. 


Doug B stated we can define an application request that gets sent in the soap body.


Doug B is not sure whether this applies to both the poll request and the status request.


Doug B stated we are placing new requirements on RMP, where the RMP is now an application.  It is answering a direct question rather than passing data thru to the application.


Doug B stated it is better to send in soap body rather than the soap header.


You may want to send a status request as another reliable message.


Sunil stated the rmp is doing duplicate elimination work, it is processing.


Doug B stated the approach is complicating the situation.


Doug B suggested an additional operation at the wsdl level for polling.


Doug B suggested an RMP as a published WSDL service.  He does not want us to carry an app level request response in soap header.


Sunil stated this poll mechanism is at the protocol level.


Marc G stated he is leaning to Doug in that we will be sending a large soap header with an empty body.


Tom stated that if this is a service, it should not serve as an alternative ack at the protocol level.  The protocol should be sound


Sunil asked what about call back.


Tom stated the Poll is tied to the replyPattern requested in the protocol, and thus the poll should be at the protocol level.  However, Tom stated he agreed the general status query can be a separate wsdl service treating the rmp as an application.


Status request, status response. 


Sunil wants the protocol operation to do the polling for the reply pattern.  He did not intend it to do status request in general.


Jacques agreed that status request is an application level service.  But the poll pattern is part of our protocol.


Doug B stated how treating the receiving rmp as providing app service is inappropriate.  The queue is an application on its own right.


Sunil stated the concerns seam to be header vs body, and having the message return more information on status.


Doing these both as separate servces seems sensible.


Tom asked if the reply pattern would need to be changed.


Doug suggested changing the poll reply pattern interpretation that one would use the wsdl service at a later time to do this.


For interop we would require a special service for user of rmp.


Simple headers would suffice, according to Sunil.


Payrits stated that nomatter where we place it, it is a distinct operation.  It might cause problems if the mep is mixed up due to some error situation.  If you use two services at the same time things could be mixed up.


Tom repeated his concern about the reply pattern being part of the protocol.  Doug repeated his response that this is not a problem.  Tom stated he needed time to think about it.


Having a WSDL service spec for the polling/status operation as part of the service.


Sunil stated having it in the body id problematic, because the protocol is implemented as a handler, not a wsdl service.


This would also require agreements on bindings and the like.  This also requires a RMP to expose itself as a WSDL endpoint. 


Tom Stated this may require a different http address for the wsdl endpoint from the rm endpoint. Doug was not sure.


Continue discussion on email on this one.

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