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 minutes of wsrm tc teleconf 5/4/04

The prelim minutes are attached.

Please post any corrections before Thursday pm to the entire list.

Tom Rutt
WSRM Chair

Tom Rutt	email: tom@coastin.com; trutt@us.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 of WSRM TC Conference Call – May 04, 2004


The meeting of the WSRM TC took place by teleconference 

Tuesday, May 4, 2004, from 5:30 to 7:30 PM Eastern Standard Time

(UTC - 5)


1         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Action Item Status Review

4 Discussions of unresolved editorial comments

5 Discussion of Document progression

6 Discussion of FAQ / Presentation for WS-Reliability


2         Roll Call


Last Name




Voting Level




Booz Allen Hamilton










Cyclone Commerce









TC Chair































NEC Corporation





NEC Corporation

























Sun Microsystems





University of Hong Kong




 Meeting is quorate.


3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes will serve to record issue resolutions.

3.2      Approval of previous meeting minutes




Leave open, for Sunil to post a correction.


To approve at the next meeting

4         Status of Action Items



4.1      Action editors-1 – (Marc and Doug) Pending


Marc G and Doug B to updated issues list to reflect agreements in CD .992.

- open


4.2      Action 042004-1 – (Jacques) close



Action: Jacques will propose the text changes to the document to remove retry parameters

Changes for the agreements section text in .996, still listed in table Iwasa added to section 3 and in the annex

Ø New action for Iwasa needed to remove retry parameters from table in section 3 and from annex A.


4.3      Action 042904-1 – (Tom and Iwasa) needs discussion


Action: Iwasa and Tom will provide text for the new fault code and the reference to it in the section of text Alan cites.

Added GroupAborted error code to draft .996, however the paragraph which was cited to add the MUST return sentence was deleted.  Did not add a sentence.  Could add the following sentence somewhere:

“When group processing is aborted, the Receving RMP MUST return GroupAborted fault for all non-delivered messages which have not had an RM reply sent.”



4.4      Action 042904-2 – (Sunil) completed


Action: Sunil will update schema for new fault code in the message processing failures sector.



4.5      Action 042904-3 – (Jacques) Pending


Jacques took an action item to propose this new subsection on special considerations for wsdl request/response operations. 


4.6      Action 042904-4 – (Jacques) Pending


Jacques took action item to add appropriate text to also clarify that an RM-Fault must be returned if the message  cannot be delivered because the requested reply pattern is not supported 


4.7      Action 042904-5 – (Jacques) completed


Jacques took an action on where to move the current section 3.4, with perhaps a re-title of section 3.  Jacques will also propose a new document structure to accommodate this and other problems he encounters



4.8      Action 042904-6 – (Jacques) completed


Jacques took action item to propose appropriate change to using word application (perhaps producer/consumer).

Completed in .996, however figures need to be updated to change “application layer” to “producer” or “consumer”.  The new figure 1 still has application party.  Needs to be removed.


Ø New action to Iwasa required to make figure changes.


4.9      Action 042904-7 – (Iwasa) needs discussion


Action: Iwasa to apply all editorial changes from Tony’s mail, except for those he considers in need of discussion.

Completed on 4/30, there are a few comments that require further discussion at May 4 TC teleconf.


4.10Action 042904-8 – (Tom) completed


Action: Tom should put out a call for IPR claims.



4.11Action 042904-9 – (Jacques) completed


Action on Jacques: incorporate his new Agreement section while doing the document restructure.



4.12Action 042904-10 – (Bob F) closed


Bob F took action to lead a team to provide an initial draft of the comparison paper of WS-Reliability/WS-ReliableMessaging, for review by the TC.  Sunil and Jacques joined the team.


Add to agenda

4.13Action 042904-11 – (Jacques) closed


Action: Jacques will lead a team to ensure the terminology used in the spec is consistent with normative terms in the soap spec.  Pete W will work with Jacques to provide a proposal to resolve this.




5         Discussion of Issues and editorial Comments

The following table includes items which need further discussion:



5.1      Resolution of W3c Protocol group alignment comment



2. The relationship of Reliable Messaging Processor (Lines 278-281) to the SOAP processing model requires definition.


Statements that the RMP is a "module" that exposes "submit", "notify" and "deliver" operations directly to an application imply a layered processing approach, which is not explicitly defined.  Also, the SOAP term "node" is used in several instances where possibly "RMP" is meant, which contributes to the lack of clarity.


Action item assigned to Pete to draft appropriate clarification text.



Line 279: Change

  "A module capable of processing and enforcing Reliable Messaging as described in this specification."


  "A SOAP Processor capable of processing Reliable Messaging SOAP  header blocks."

Open see 6.2

To resolve with XMLP comment 2.




Email from pete:

Jacques and others, I believe that recently adopted text goes a long

way toward resolving the terminology discussion ("what is an RMP?").

I propose the following additional changes (based on WD 0.996) to

close this issue, and welcome any comments and corrections.



WS-Reliability is a SOAP Module (as defined by [SOAP 1.2]), which fulfills reliable messaging requirements that are critical in some applications of Web Services. SOAP ([SOAP 1.1] and [SOAP 1.2]) over HTTP [RFC2616] is not sufficient when an application-level messaging protocol must also guarantee some

level of reliability and security....  [Continue with remaining text as-is.]



1.2 [Change first paragraph to:]

Reliable Messaging (RM) is the execution of a transport-agnostic protocol

based on SOAP for providing quality of service in the reliable delivery

of messages.


[Continue with remaining paragraphs.]


[Replace these two definitions:]


Reliable Messaging (RM):

The act of processing the set of transport-agnostic SOAP Features defined

by WS-Reliability, resulting in a protocol which guarantees certain

qualities of service.  This includes the processing of Acknowledgment

messages, re-sending of messages, duplicate message elimination, and

message ordering.


Change to acknowledgement indications.




Reliable Messaging Processor (RMP):

A SOAP Node (as defined by [SOAP 1.2]), or a subset or superset

thereof, capable of performing Reliable Messaging as described by this

specification. With regard to the transmission of a Reliable Message from

one RMP to another, the former will be referred to as the Sending RMP,

and the latter as the Receiving RMP.





Pete moved to close the issue with accepting the proposed text with amendments above.  Jacques seconded.


No opposition, motion passes.





Line 98: Says "This specification addresses end-to-end reliability, and is not concerned with intermediaries."  However, there is nothing to prevent someone targeting Reliability headers to "next" role/actor. This case should be explicitly forbidden, rather than left undefined.


Concerns expressed by Peter Furniss.

RE: [wsrm] Comments on WS-Reliability CD 0.992


Now in line 120 of ed .996


Pete stated this may be a valid concern. 


Leave open and put discussion to the list.


Will be put on the agenda for the next meeting.


Jacques will initiate discussion of this concern.




1025-1030: Example in which SOAP Fault may also convey an RM Acknowledgment requires a confusing or impossible processing order. (Process RM headers, remember that an Ack needs to be sent, continue with header processing and SOAP Body validation and finally "application processing space outside the realm of the receiving RMP".)  How does the RMP know when all processing has been completed, then intercept a possible SOAP Fault in order to attach its Ack?

in .996

Action Item to Tom Rutt for proposing better text.


Re: [wsrm] response to action item to clarify soap faults and WSRMresponses


Jacques took action item to incorporate the latest proposal from Tom and Pete into a new section on request/response.


Replacement text provided by Jacques, need to ensure it is complete.








The specification contains no reference to the schemas. 

agreed not yet applied

The two schemas should be listed in the normative appendix, and introduced at an appropriate location in the text, perhaps at the beginning of Section 4


Agreed to have a new normative appendix which points at the schema URL.  It also has to have the precedence statement copied from the schema.


At publication time the OASIS staff can decide to place the actual schema text.



Ø Action on Iwasa to add new annex pointing at schema with the disclaimer of precidens.




Editorial corrections required

agreed not yet applied

269: Remove line break in the middle of "response".

501: "the Sender RMP notifies a delivery failure"

  should be

  "the Sending RMP is notified of a delivery failure".

522: "an" should be "a".

526: "nor to notify failure on the sender side" should be "nor to notify  the RMP Sender of the failure".

527: "it's" should be "its".

Schemas: "it's" (in comment blocks) should be "its".


Ø Action: Iwasa should check if item 7.13 is done.






in .996, needs discussion

Faults for Aborted Ordered Deliver

treatment of aborted out-of-order seq


Action on Tom and Iwasa to provide text (completed).


GroupAborted fault code added, but text stating “MUST send” was not added since the paragraph cited by Alan was removed.  It is not


Could add a statement that “When group processing is aborted, the Receving RMP MUST return GroupAborted fault for all non-delivered messages which have not had an RM reply sent.”



Bob F: is there any reason we have to send more than 1.


Bob F: suggested:

Any additional messages that are received for an aborted group, until the group expiry time, MUST have the GroupAborted fault sent.


Jacques, requiring that every message received has to have this fault returned.  The Receiver may decide to only send once every 10 messages received in that group.


Jacques: we should not mandate one fault notice for each received message.


Alan: a responsible sending RMP will cease sending on the group once it receives this fault for this group.  This would be a small number of messages in transit which would require sending this fault.


Bob F: if you have high bandwidth, low latency channel , they could wait a few seconds to wait and send the fault replies.


Jacques: in ebMS people had considered a sender with bad intentions, to overload the receiver.  This concern is addressed in the design of the ebMS protocol.  In the same way we deferred the resend policy, we could say that the receiver must publish a group abort fault when the group is aborted.  This publishing could be open for config parameters to decide the frequency.


We need further discussions.  Take to the email list.









For Callbacks, response POST context URI doesn’t match the replyTo URI in the request

agreed editorial change


Ø Action iwasa needs to clarify.





change application layer in figures


Most of the figures use the word ‘Application Layer’, we need to better quantify what we mean by ‘Application Layer’ or say something like ‘Application Layer/SOAP Processor’.

Agreed that the word application and application layer need to be changed to more abstract terms (perhaps producer and consumer).

Added new definitions for producer and consumer, need to update figures


Iwasa has action item to update figures to get rid of application layer.

5.9       Superfluous use of two schemata


Two schemas and namespaces are unnecessary for two soap versions.


Proposed change:

remove the soap 1.2 schema, and change the following lines on the soap 1.1 schema:

soap 1.1 schema has:

<xsd:schema targetNamespace=
"http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.62">
   <xsd:import namespace=
"http://schemas.xmlsoap.org/soap/envelope/" schemaLocation="http://schemas.xmlsoap.org/soap/envelope"/>
   <!-- 4WSRM Headers -->
   <xsd:element name="Request" type="wsrm:RequestType"/>
   <xsd:element name="Response" type="wsrm:ResponseType"/>
   <xsd:element name="PollRequest" type="wsrm:PollRequestType"/>
<!-- Describe the BaseTypes -->
   <xsd:complexType name="HeaderBaseType">
           <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       <xsd:attribute ref="soap11:mustUnderstand" use="required" fixed="1"/>
       <xsd:anyAttribute namespace="##other" processContents="lax"/>

to the folloing:

<xsd:schema targetNamespace=
"http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"

   <!-- 4WSRM Headers -->

   <xsd:element name="Request" type="wsrm:RequestType"/>
   <xsd:element name="Response" type="wsrm:ResponseType"/>
   <xsd:element name="PollRequest" type="wsrm:PollRequestType"/>
   <!-- Describe the BaseTypes -->
   <xsd:complexType name="HeaderBaseType">
        <!--mustUnderstand attribute for soap version used must be present with value = 1 -->
           <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        <!--mustUnderstand attribute for soap version used must be present with value = 1 -->
       <xsd:anyAttribute namespace="##other" processContents="lax"/>

And add the following text to the spec, in the new annex pointing at the schema:

When used with soap 1.1, the soap1.1 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks.

When used with Soap 1.2, the soap1.2 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks.


Also:    Version number should be in the title of the document as version 1.1.


Joe Chiusano moved to accept this change, Bob F seconded.


No discussion.


No opposition, motion passes.


Aleady been applied to schema and text.


Ø Iwasa: action to ensure the two statements are included.  Incorporate version 1.1 in title of spec.


5.10Syntax of replyTo attribute


New email from Anish:

For the poll and callback pattern WS-R has an attribute 'replyTo' of type xs:anyURI. The value of this attribute in the request message specifies the poll/callback location. This is problematic for the following reasons:


1) A URI does not represent a Web service -- a WS is much more than a URI and a reference to a WS has to be more than a URI. A URI is certainly part of the WS reference. URI is necessary but not complete. For example, the URI does not say what the operation/interfaces/binding/policy/f&P/capability/etc are. One cannot even specify the value for the "SOAPAction" HTTP header (which is part of the binding). Although WS-R is not WSDL-centric (and the callback location and poll location does not necessarily have an associated WSDL), the replyTo attribute makes the scope of WS-R very limited.


2) As corollary to (1) above, the binding/interface of the URI has to be known before hand and cannot be changed. I.e., the SOAP node which is being polled or called-back on has to be assumed to use SOAP HTTP binding. One of the big reasons for using callback/poll is the underlying protocol itself is asynchronous (HTTP is synchronous) -- other reason is that the operation takes a long time. Effectively, WS-R cannot be used with non-HTTP/non-SOAP-binding. For example, one cannot use SMTP/MOM-proprietary asynch protocols.


3) Another corollary to (1) is that one cannot send a message using protocol A and poll/callback using protocol B. E.g., a node which is behind a firewall sends a message using HTTP (so that it knows that the message has been received but not necessarily delivered) and have the receiving node send an ack using SMTP.


4) An attribute of type URI is not enuf to represent all kinds of protocol bindings (such as queuing systems). This means that newer versions of WS-R spec (which hopefully will support various protocols) cannot use an attribute of type URI -- for two reasons -- the type is restricted to URI and it is an attribute (which means it can only be simple type). I.e., the current schema for WS-R lacks extensibility for the addressing feature of callback/poll. Not very friendly for future versioning.


I do realize that this issue is being brought up at the 11th hour, but did not realize that there was an issue till now.







Tom: what if we make it a sub element with any syntax any.  We could state that with the HTTP POST normative binding the sub element reply to would be a URI.


Anish: the current syntax disallows some other bindings.  A URI is not enough as an addressing mechanism, especially in a wsdl centric world.


There are at least two addressing mechanisms allowing pointing to a web services.  By having a structure, the next version of ws-reliability will have to change the structure to allow other addressing mechanism.


Anish: Given it is a uri, it is transport agnostic, but it is not transport binding independent.  IT is possible to have more than one binding for a given transport protocol...


Jacques; is this for the longer term.  What we send back to the reply to address is not intended to be bound to wsdl, it is intended to be received by the soap node sending the message.  This is not critical for this release, however the reply to might be a third party address.  Is this a serious limitation for this version?


Anish: It is problematic for future versions.   The next version would not be backward compatible with the current spec if the change is not made now.  Until a new version is out I cannot use the spec with other bindings.  There are two major use cases for asynch callback: 1) the infrastructure is one way, 2) the reply may not come for a long time.  The first case is not covered by the spec, since the schema prevents other bindings.


Jeff: if we make it an open content model, with this version restricted if using the HTTP post binding, we enable  backwards compatibility.


Jeff: make it an element, with an any attribute syntax.


Leave it open, take to the list, incorporate discussion of the following point on http binding clarification as well..


5.11Clarification of http binding


·  ·  Re: [wsrm] Clarification needed on our http binding
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
4 May 2004 05:01:30 -0000


Tom Rutt wrote:


> We need to clarifiy that the mandatory binding in the spec is to use

> htttp post.



I think the spec needs to be clearer than that. It should probably say

SOAP HTTP binding defined by WSDL 1.1 section 3 (OR SOAP 1.1 section 6

binding, minus the HTTP Extension framework)


> This is not stated clearly.


> In fact we need to clarify the exsting lines 1310, 1311, 1312

> "

> (3) The Acknowledgment Message is sent with another HTTP connection from

> the Receiving

> RMP to the Sending RMP. Example 15 is an example of this message.

> (4) The HTTP response for (3) has no HTTP message body. Example 14 is an

> example for this

> HTTP Response.

> "

> to require an http post request.


> This clarification is needed, for interoperability, to avoid the use of

> http get when http post is expected.


> Tom Rutt




Can an implementation claim conformance if it does not do HTTP post binding.


Alan: I thought we agreed on this that it is so.


Discussion should include both of these items together.


Take this to the list.


5.12Tony Graham edits needing discussion:

Defer discussion to next week.


Ø Action: Iwasa and Tony should work to resolve Tony’s non resolved comments



section 1.5 - xml declarations in example


Remove the XML Declarations since they are unnecessary.

This was kept in the example, since it is necessary when example includes HTTP header, according to Sunil’s comments


sextion 1.5 line 178


Change "wsr-example.org" to "wsr.example.org" or "example.org/wsr" to

properly use the "example.org" example domain name.

Pending. Is it allowed to use “example.org”?  wsr-examples.org was not registered yet the point of I picked up, so it is no problem so far. Need to make sure with example.org domain for its use



Lines 229, 260, 262


Use 'straight' quotes instead of 'smart' quotes around attribute values.

Kept them as-is for consistency with example1 ,2 and 3



Section 1.6 line 288, 304


Why must the time be identifiable?  Why is it not sufficient to just preserve the order of submissions, e.g., in a queue?

Need resolution. (Not applied)

Proposal: replacing “The time” with “The order”



Line 316, 317, 319


done partially in .995, undone in .996. many remain

"Acknowledgment messages" are not defined.  There are now only "Acknowledgment indications".

The following lines need to change Acknowledgement message or fault message to acknowledgment indication or rm-fault indication.:

229, 230, 232, 264,633,  661, 662, 813, 814, 661, 662, 823, 825, 877, 1234, 1237, 1239, 1245, 1299, 1452, 1478, 1309, 1373, 1391



line 329 of .993


How can a "Reliable Messaging Fault Indication" signal a failure to receive a message when this specification "expects that the transport layer will not deliver a corrupted message" (line 1308) and there are no fault codes for non-delivery of messages?

      Needs resolution.


line 336 of .993


A reply may now include multiple Acknowledgment Indications.

Needs text, if required.



line 366 of .993


"between the application layer, the sender and receiver RMPs" does not


Needs discussion. I believe we shouldn’t mention RM is a contract between application and RMP. Reliable Messaging is for between Sending RMP and Receiving RMP only, but not application and RMP. We can’t guarantee the delivery to the application and should not do that when we don’t define neither protocol between RMP and application, nor RMP API. Even in the ordering case, we don’t guarantee the delivery of a message to the application, and it is completely appropriate. In conclusion, we should not say the RM agreement is an agreement between application and RMP. Sending RMP can’t and shouldn’t guarantee the delivery of a message to the application. (That is the point Chris Ferris raised actually, and he is right, even if what he picked up was wrong, which was “Ack is a receipt of delivery to the application”.)




Section 1.7.2, RM Agreement Items


Line 388, 390, 392


Change "period" to "period.".

I don’t understand this comment. Need clarification.



Section 3, Reliability Features


Line 499

"Business payload" is undefined.

Needs definition for Business payload or replacement text.




table and figure numbers


Line 1263


Number the table and make this the title for the table.

Note: Table number, examples, Figures will be renumbered after restructuring of the spec



Mail from Tony Graham:

>Some of Tony Graham's editorial comments are in this category.

>> Please look this over to see if any of your items need further discussion.



1. Line 178: example.org


   example.org (and example.net and example.com) are reserved for

   examples and documentation.  See

   http://www.rfc-editor.org/rfc/rfc2606.txt for the explanation.


   Using example.org makes it obvious that it is an example and avoids

   any conflict with a domain name that is in use or will one day be

   in use.


2. Line 288, 304: Why must the time be identifiable?


   I would like this to be explained to me.


3. Line 329: Reliable Messaging Fault Indication for failure to

   receive a message


   Another thing that I would like explained to me.


4. Line 366


   My comment had to do with the sentence construction.  Looking at

   the comment in the preliminary minutes, it seems likely that the

   sentence will change anyway.


5. Line 388, 390, 392


   My braino.  It should be "Change 'details' to 'details.'." but I

   was thinking too much about periods so the wrong word came out.





Tony Graham



6         Discussion of Document Progression.


Ø Jacques, took action, with Iwasa,  to produce a new editor’s draft .997 by Friday.  Indicate which public review coments are resolved.


Agreed to postpone discussion of  progression to next meeting.



7         Frequently Asked Questions / Presentation rebuttal

Karl F. Best wrote:


After some discussion among staff and the OASIS Board, we would like to invite the WSRM TC to submit a response to the presentation made by Chris Ferris' last week in
New Orleans. This response should be in the form of slides that can be posted to our web site alongside the other slide sets from the program..  he content of the slides should be strictly limited to correction of any errors in the comparative analysis done by Chris.

Would the TC be able to prepare this in the next couple of days? (We suspect that someone in the TC may have already started this, so hope that this timeframe would be workable.) We would like to post the TC's slides at the same time as the other program slides which will be posted later this week. If this schedule doesn't work then the TC's response could be posted later.

Please let me know if the TC would like to do this.



Bob F sent an email with a draft power point presentation.


·  ·  First cut at response presentation, please feel free to comment and discuss
From "Bob Freund" <Bob.Freund@hitachisoftware.com> on 4 May 2004 21:20:04 -0000


Concern was expressed on the statement from carl:

The content of the slides should be strictly limited to correction of any errors in the comparative analysis done by Chris


The group decided we have leaway to say what we want.


Several comments on the presentation were collected by Bob F.


Jeff suggested we recast it as a critical comparison.  We need to ensure that the criticisms from Chris are dealt with by this paper.


Doug: perhaps we should quote from the slides.


Jeff: we do not have to do that.  We can talk about it at a higher level.


Doug: I agree that talking about it at a higher level will make us look less like a detailed thing


Bob: I asked Tom if comments made by an editor of a competing spec might not be considered as public review comments.


Tom: we can discuss whether we want them to be public review comments next week.


Say: revised spec has one schema.


Jeff sugested a team to refine the slides.  


Bob can do revision before noon wed.  Discuss on email Wed pm.  Put number on list at  3 pacific time.


Who in team: Bob F, Alan, Jacques, Jeff, Pete,


Jacques moved that the tc delegates to the subteam the job to deliver the talk to the Oasis staff.,  Alan seconded.


No opposition.   Motion passes.   


Tom will tell Karl that we will have it by Thursday or Friday.


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