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 aug 17 teleconf

The prelim minutes are attached

Please post any corrections to the list before friday.

Tom Rutt

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 WSRM TC Conference Call –August 17, 2004


The meeting of the WSRM TC  will take place by teleconference 

Tuesday, Aug 17, 2004, from 5:30 to 7:30 PM Eastern Standard Time


1         Draft Agenda:

1 Draft Agenda to WSRM TC Conference Call

2 Roll Call

3 Minutes Discussion

3.1 Appointment of Minute Taker

3.2 Approval of previous meeting minutes –

4 Action Item Status Review

5 Discussions of unresolved comments

6 Straw Poll on whether changes from CD .992 are substantive

7 Scheduled Vote for CD (only if all comments are resolved and we are quorate, else we could initiate a Kavi 7 day ballot)

8 Scheduled Votes for further progression (only if CD is voted yes)

8.1 Vote on whether changes from CD .992 are substantive

8.2 Vote to Submit to OASIS for member vote (subject to no vote on 7.1))

8.3 Vote for second 30 day public review (subject to yes vote on 7.1)

9 Discussion of document progression and future meeting schedule


2         Roll Call



First Name

Last Name








Booz Allen Hamilton





Cyclone Commerce














TC Chair































NEC Corporation





Nortel Networks




















Sun Microsystems





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

The minutes of the Aug 3 teleconf are posted at:



The minutes of the Aug 10 teleconf are posted at:



Jeff moved to approve, Jacques seconded.


No opposition, minutes are approved.


4         Status of Action Items


4.1      Action 052503-1 (Tom Rutt) pending

Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.


4.2      Action 060104-5 (Jacques) Pending


Action: Jacques, will propose further edits, on the FAQ for composability.


Still open, low priority


4.3      Action 081004-1 (Sunil) closed


Action: Editing team should propose suggested changes for soap fault codes text, with Sunil leading the effort.


Sunil provided text for the editors.


4.4      Action 081004-1 (Editor) closed


Action: editors to post next draft on Thursday, Aug 12.


Draft 1.085 Posted on Aug 13.


5         Discussion of Issues and editorial Comments

The following issues list includes items which have been resolved as of the output of the 7/6/1004 TC meeting:




Additional issues and comments were circulated to the list for discussion. 


These need to be resolved before we can vote on a next CD.


The editing team posted draft 1.085 to the server which resolved the editorial items from the 8/10 minutes, including Doug B contribution:  http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8689/WS-Reliability-2004-08-12.pdf .


5.1      Restriction of Callback and Poll Reply patterns to one way only


Doug: our spec does not talk about the response operation.  The text which has been there for a long time in section 6 is being changed.


Doug I would like to move that 1.085 is the CD.


Motion failed for lack of second.


Jacques; I have moved text around so the changes may look greater.  Section 6 for  callback and poll was only discusses with one-way operations, which did not agree with the previous table 5.2 which allowed use of callback and poll reply patterns.  The TC did not explicity approve this new restriction.  Either we could align section 2 with the restriction, which is what 1.085 does, if we agree to keep these restrictions.


What has been done to section 6.2 and 6.3 is adding the case when the reliable message may bind to http request responses when the response has a payload.  Also if a fault is part of the request response this must be explained.


The section in 4.5 has been edited to align with the requirements associated with the response reply pattern is used with callback.  Given these changes the original section 2 does not need to be changed.


I believe this is fixing an inconsistency in a way to support the previous definitions of callback and poll.  It is deterministic how the binding section has been updated.


Jeff: can Doug explain what is wrong with Jacques proposal.


Doug: a number of things are happening here.  We are muddling the request response language.  We can use a one way binding of request response at some time.  What is happening here is that we are expanding the protocol, thus producing more choices causing lack of interoperability.    Doug, we are only talking about request response at the underlying protocol level.  We are talking about soap over http as used by rmp to send messages back and forth.


Jeff: can the soap mep be request response.


Doug: at the top level there is either a consumer payload or not, based on wsdl one way or request response.



Doug: request response can be mapped to underlying layer by putting the response payload with rm reply in a callback.


Tom: this is a different wsdl binding than the traditional soap/http Post binding in the WSDL spec.


Doug: what we are trying to do here is apply restrictions to the consumer interface.


Doug: the application is supposed to respond before the RMP.  The RMP can take its time to send the callback.


Jacques: we have some use cases.  Callback can be bundled, the acks can be bundled but if you do that you may not want to sort out which belongs to one way and which belongs to request/response mep.  This use case shows one use.


Sunil; another use case is the sender wants a centralized ack mechanism regardless of callback or response reply pattern.  The same would apply for polling.  This restriction does not really simplify the protocol.


Doug: I do not understand how when sending rmp sends it message how it knows that there will be date in soap body of response.   We should not apply bp 1.0 at the consumer interface level.


Sunil one operation has an input but does not have an output.


Jeff: BP enforcement looks at messages going across the wire.  All the messages using the soap/http post binding, as in section 6, must obey BP 1.0 restrictions.  


Jacques: you must also look at the wsdl, including the port binding, for conformance.


Jacques: the restriction in 1.085 precludes using a wsdl request response bound to soap http post binding with callback or poll reply pattern


Tom: the question is how important the loss of this use case is with this restriction.


Jeff: we have those use cases given to us, as Sunil as described.


Jeff: the 10 second short hand question: you do not want to allow callback or POLL WITH Wsdl request response on Soap http/post binding.


Tom  We need to clarify that we are talking about the standard wsdl soap/http-Post port binding type.


Doug: if wsdl says it is one way, then that means there can be no underlying response on the wire.     The ws reliability spec is a slightly different wsdl binding. 


Jeff: we are not talking about one way, we are only talking about request response.


Doug: I agree with Tom, that if a consumer interface described as a wsdl operation using request response has to go to the underlying level, then the section 2 changes disallow it.


Tom: The standard soap/httpPost wsdl port binding does make a strong mapping of application level request response to the underlying Soap request response MEP.   Other wsdl port bindings could be defined which map wsdl request/respose operations to underlying soap oneway MEP, but these have not been defined yet.


Doug: I would like to ask a second part of this.  Regarding Application level one way message, are we required to use a one-way message at soap level for the mapping.


Tom: this restriction comes if one uses the standard wsdl port binding of type soap-http/post, and the BP 1.0 restrictions.


Tom: the question is: do we want to continue to allow usage of wsdl request/response operation type with a wsdl port soap/http-post binding, with the use of the callback or poll reply pattern.


Tom: is anyone opposed to removing the text in 1.085 which restricts usage of request response operations with callback or poll reply patterns (when using the soap/http-post wsdl port binding).


Nobody expressed opposition to removing the restriction.


Tom: There is some work need perhaps to hone up Jacques proposed text.   The figures have no respond primitive shown.


Jacques: I will look at the figures to fix the problem






·  about latest contribution + 1 observation
From Jacques Durand <JDurand@us.fujitsu.com> on
13 Aug 2004 01:49:42 -0000

Doug made the case for his edit of 2.5 where only SOAP One-way (not SOAP request-response) is now used for defining the Callback reply pattern (and Poll ) in Section 2.5 ( I initially did not write this restriction), by pointing that he was only aligning the definitions so that they are compatible with the HTTP binding requirements (Section 6), that require these messages to adjust to SOAP One-way, and One-way only. So indeed, section 2.5 and section 6 are now more consistent with each other.


I must say I had not focused much on this section (6) before, but I have to point out something important about its current wording:


After a careful reading of Section 6.2 and 6.3,  my conclusion is the following:

For RMP implementations that are BP 1.0 compliant, the current wording of Section 6.2/3 makes it impossible to use Callback and Poll reply patterns for messages that relate to WSDL request-response operation types (see explanation below).


 I know some of us had proposed this (Tom) before, but I am not sure this is what the TC really intended, as we did not pursue this idea.


Certainly, the now defunct Table 5.2 contradicted this restriction.

 I personally have no strong opinion on this yet would rather not have this restriction.



 Section 6.2 describes precise HTTP requirements related to BP 1.0  for a Callback response in case of Faults ("empty HTTP entity-body", etc) .Two statements here are restricting the use of Callback as applicable only to WSDL One-way operation types.


- L1487 (item 2) clearly states that no SOAP envelope should go in the HTTP response, at least in normal (non fault) cases. This combined with BP 1.0 rules out the use of WSDL request-response operations, which bind to HTTP request-response (via the SOAP binding mandated in BP1.0. Although this can be seen as quite restricting, that also can be seen as a major helper  in SOAP interoperability.).


- L1479-1482 requires NO SOAP fault to be returned in case of error. But  R1029 in BP 1.0 : ("Where the normal outcome of processing a SOAP message would have resulted in the transmission of a SOAP response, but rather a SOAP Fault is generated instead, a RECEIVER MUST transmit a SOAP Fault message in place of the response.") requires a SOAP fault to be returned when a SOAP response was in order. And BP 1.0 always requires a SOAP response over HTTP response,  for output messages that are defined for WSDL requrest-responses operations. So these operations must always generate a SOAP Fault on the HTTP response, which conflicts with our requirement.


We havea  similar situation for Poll pattern (6.3)



If the TC intends to accept this restriction, that should be made more explicit and at higher level (our spec is also for WS users who think in terms of what kind of reliability features they can use with what Web service operations, not just for developers who will look at what HTTP binding they should use.)


If not, I would suggest we reword 6.2 / 6.3 (to accommodate both WSDL one-way and request-response), and relax the One-way restriction for Callback reliable message.




·  Contribution taking away one-way restriction on Callback and Poll
From Tom Rutt <tom@coastin.com> on
15 Aug 2004 16:39:50 -0000  

Page: 11

Sequence number: 1

Type: Typographic error

line 336 - "between between"


Page: 13

Sequence number: 1

Type: Undue Restriction

lines 407-412 - Jacques email points out that this restriction of

callback Reply pattern to soap One Way is a technical change which is

not required for the protocol to work. While releasing this restriction

may not impact most use cases for the protocol, it takes away a

capability which has always existed in previous CDs.


Page: 14

Sequence number: 1

Type: Undue Restriction

lines 415-427: This new text introduces a restriction of poll request to

one-way soap mep, which is not required for the protocol to work. This

restriction is not necessary for the protocol to work.


The following suggestions are superceded by the more complete proposal from Jacques below.


Page: 52

Sequence number: 1

Type: Undue Restriction

line 1416: While the statement that , for Callback Reply pattern, the

HTTP response has no message body is appropriate for the example, it is

not a restriction required by the protocol. Should clarify that "in this

example, the HTTP response".


Sequence number: 2

Type: Undue Restriction

lines 1409-14ll: the sentence "To achieve this, the Receiving RMP MUST

NOT return a SOAP Fault and the HTTP response entity body SHALL be empty."

is pertinent only for OneWay operations, since request/response is

allowed by the protocol, this statment must be weakened to the one way case.


Page: 54

Sequence number: 1

Type: Undue Restriction

lines 1484-1485: As in the callback text, This sentence is only pertient

to one way operations, and it should be clarified that it is not a

requirement for request response operations.


Page: 55

Sequence number: 1

Type: Undue restriction

line 1494: While the statement that, for Poll reply pattern, the HTTP

response has no message body is appropriate for the example, it is not a

restriction required by the protocol. Should clarify by inserting "in

this example, the HTTP response".




·  Re: [wsrm] Contribution taking away one-way restriction on Callbackand Poll
From Doug Bunting <Doug.Bunting@Sun.COM> on
16 Aug 2004 02:26:09 -0000

·  Re: [wsrm] Contribution taking away one-way restriction on Callbackand Poll
From Tom Rutt <tom@coastin.com> on
16 Aug 2004 17:00:49 -0000

·  Issue on support of request/response for callback and poll
From Tom Rutt <tom@coastin.com> on
16 Aug 2004 18:22:30 -0000

Doug has made the point that his interpretation is that the section 6 binding is correct, and since it has no examples for request/response operations with callback or poll, it precludes it.


Doug's view does simplify the protocol, since for callback and poll the receiving RMP never has to determine if a response is expected for the original request.


However, the callback and poll response always are returned the same way for either one-way or request/response operations, so the only complication for my interpretation of the spec occurs if the Receiving RMP has to participate in the return of the http response to the original message.


It states in section 2.2 hat the Receiving RMP must be aware of whether a respond is required matching a Deliver, so the added complexity to support my interpretation is not great.


Tom Rutt


·  RE: [wsrm] Contribution taking away one-way restriction on Callback and Poll
From Jacques Durand <JDurand@us.fujitsu.com> on
16 Aug 2004 21:06:49 -0000

I believe our latest requirements document required Callback and Poll to accommodate both One-way and Request-response MEPs (see wsrm-reqm-issues-2004-01-15.xml:




        1. Agree to have requirement for Spec having a solution for response Ack binding pattern, for both one way and request/response MEP<br />


        2. Agree to have requirement for Spec having a solution for Callback Ack binding pattern, for both one way and request/response MEP<br />


        3. Add new requirment for spec having a solution for sender to recieve delayed Acks when it is not willing to recieve underlying protocol requests, for one way MEP




                        Proposals 1 and 2 accepted<br />

                        Proposal 3 accepted





·  HTTP binding upgrade for Callback : proposal
From Jacques Durand <JDurand@us.fujitsu.com> on
17 Aug 2004 04:10:35 -0000

Title: HTTP binding upgrade for Callback : proposal


Here is a more precise proposal on how the HTTP binding of Callback (and Poll) requests (Section 6.2 and 6.3)  can:

(1) support both One-way and Request-response SOAP MEPs,

(2) remain fully conforming with BP 1.0


Summary of HTTP binding requirements as they would have to be reworded in 6.2:


(A) general requirements (same as before):


- the initial message carrying the RM Request with Callback element, is an HTTP request.

- the RM Reply must be returned  on a different HTTP connection (in a request)


(B) requirements related to BP 1.0 conformance:


(b1)  If the HTTP request carrying  the Callback reply pattern element is binding to a WSDL One-way operation:

(then current requirements are OK):

- no SOAP envelope should be returned in the HTTP response (HTTP entity-body is empty)

- in case of RM fault, NO SOAP Fault MUST be returned (and HTTP status code should be...)

(NOTE: Abstracting this from WSDL, we can require this for any SOAP One-way MEP)


(b2)  If the HTTP request carrying  the Callback reply pattern element is binding to a WSDL Request-response operation

(this need be added):

- a SOAP envelope may be returned in the HTTP response by the responding party (Consumer)

- in case of RM fault, a SOAP Fault MUST be returned (and following same requirements as for Response reply pattern, L1033-1047 Section 4.5...) and L1048-1050 must be corrected accordingly.


(NOTE: Abstracting this from WSDL, we can require this for any SOAP Request-response MEP)


I'll send a "contribution" matching these asap, as Tom's contribution remains silent on the (b2) part above.



Regarding (B) above, a precision/correction must be added to my previous sending:


When complying to BP 1.0, a Receiving RMP (if not the Sending RMP) must be able to distinguish the case (b1) from (b2) above,


especially in order to know how to handle faults. But it is always expected that this features is supported by BP 1.0 compliant WS stacks on which the RMP is deployed, so that an implementor of WS-R is always in a measure to know when to add a SOAP Fault in the body (b2), and when not (b1), in case of RM error, and this without having to be explicitly instructed of which MEP is being used.


The requirement that an RMP who invokes "Deliver" knows whether or not a related "Respond" will be invoked, is satisfied in the same manner.


Some implementation examples:


(case 1) the RM features are implemented as a Java handler in a WS stack complying with BP 1.0 (e.g. Axis 1.2).

 In that case, when a request is faulted due to RM fault, the handler will systematically generate an exception.

The effect of this exception tells the responding RM handler what to do: if the stack generates an empty HTTP response with the


right status code as BP 1.0 requires for One-ways WSDL ops, then our handler will not add anything to it (b1). If the stack generates


an HTTP response with a SOAP Fault as BP 1.0 requires for Request-response WSDL ops,  then our handler will make sure the Fault has the right code, and let the WS stack forward it to Sender (b2).


(case 2) the RMP is an endpoint itself. In that case, it has knowledge of the [WSDL] operation types the messages it receives/sends bind to.


If no WSDL is used, the RMP will still have knowledge of the SOAP MEP involved.






The contribution http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8742/WS-Reliability-1085-JD.pdf applies Jacques final proposal to the changes in the contribution from Tom Rutt, to draft 1.085.

5.2      Anish Proposal for definition of Property

· Suggestions to improve wordings of features and properties
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
17 Aug 2004 18:02:27 -0000


1) In section B.1 (Introduction), there is a bullet list consisting of

feature (and its definition), property (and its definition) and

compositor (and its definition). I would like to propose that we keep

the bullet list, but remove the definitions and replace it with forward

references to the appropriate sections where the definition occurs)


  * feature <reference-to-B.3.2>

  * property <reference-to-B.3.3>

  * compositor <reference-to-B.3.1>


This would mean that the definition will occur only once in the spec.


2) At the end of the 2nd sentence in B.3.3 add:

"A property can occur only as a child of a compositor."


The complete paragraph now will be:

"A property is identified by a QName. A property is an assertion or

constraint on a specific RM capability and its value(s). A property can

occur only as a child of a compositor."


Mark peel moved to accept Anish proposal, seconded by sunil.


No opposition to accepting Anish’s proposal.



Two contributions were posted by the chair:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8749/WS-Reliability-1085-ak.pdf applies the proposal from anish to the draft 1.085


http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8747/WS-Reliability-1085-jdak.pdf applies the proposal to the contribution 1.085jd, from Jacques,  to remove restriction of callback and Poll Reply patterns to one-way


6         Straw poll on whether changes from CD .992 are substantive.

Since the vote on CD might be influenced by whether that CD will be put out for another public review, the chair proposes an informal straw poll to determine whether the changes are considered substantive from CD .992.


Split: 6 voting members said substantive, 6 voting members said not substantive.  Some members who indicated substantive stated they might change their opinion to not substantive at the time of the real vote.


Thus the decision as to whether the changes from CD .992 are substantive will be left to a vote when the next CD is agreed.

7         Scheduled Vote for CD (only if all comments are resolved and we are quorate)


wait till Aug 24.

1         Scheduled Votes for further progression (only if CD is voted yes)

No cd to discuss

2         Discussion of document progression and future meeting schedule


Goal is to Vote on CD at next meeting.


Based on agreement to not adding new restriction on use of wsdl request response with soap/http-post binding and callback or poll reply pattern, Chair suggested that we use contribution 1085-jdak (http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8747/WS-Reliability-1085-jdak.pdf) as the basis for comments.  This incorporates Jacques changes, and Anish’s clarification of property.


Comments due to wsrm list by Thursday Noon Pacific Time on 1085-jdak , used as the basis for comments.


Action: Jacques will provide a new draft 1.086 By Thursday evening, to resolve any comments posted to the list by Thursday Noon..


Go for CD vote at the next meeting.




Discussion on next face to face meeting


From Aug 10 minutes:

Tom: lets consider two possible tracks: 

  1. A: changes from CD .992 are voted as not substantive – we can submit to oasis member vote on Sept 15.  They send out on October 1 the  30 day member vote,  we get comments by October 31.  This points to a Face to face to resolve member comments in November
  2. B: changes from CD .992 are voted as substantive – can initiate a new public review could initiate on Sept 25th. Closing Sep 25th.   Earliest Oasis member vote submission on October 15, with Oasis member vote going out Nov 1 ending Nov 31.  This would lead to a Face to Face in early October (to resolve any public review comments) or December (to resolve member comments).


Agree to another two hour conference call next week.


Go for a CD vote with all other possible votes.


Alan: I think it would be good to have an interop for developers at the next Face to face.  NEC cannot participate in an early October interop.  The October 4 date is too early.


Jeff The Brussels event is not meaningful.


Tom: We are either talking about a face to face in November or December, timed to address the Oasis member comments.


Alan: Interop is important.


Tom : the spec has not changed much from the  interop.  The implementation changes from the last CD are not substantive.


Bob: we need to have relatively friendly member interop which is not widely publicized.  Subject to its outcome, we can do a public interop at a platform event.  I do not want to confuse those into one event.


Hitachi can be ready early October, the second or third of October would be ok.


Tom: a November meeting could accommodate the interop event.


Jeff: the interop event does not need to be timed tightly with our meetings.


Bob: I have put out a request for timing, when the responses come in, we can determine at time which accommodates us all for the private interop


The public interop should be timed with some significant conference giving an appropriate audience.


Tom: the next f2f should be based on evaluating member comments. 


·  Agenda items for next week's call
From "Alan Weissberger" <ajwdct@technologist.com> on 10 Aug 2004 23:35:43 -0000


Defer to next week.


·  Gartner 11/04 demo opportunity
From "Alan Weissberger" <ajwdct@technologist.com> on 14 Aug 2004 01:39:43 -0000



Bob F moved to adjourn Alan seconded.


Nobody opposed.



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