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 5/18 Teleconf

The prelim minutes are attached.

Please provide any corrections to the list before Friday.

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 18, 2004


The meeting of the WSRM TC  will take place by teleconference 

Tuesday, May 18, 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 for WS-Reliability


2         Roll Call


First Name

Last Name




Voting Level










TC Chair



















NEC Corporation






Nortel Networks
























Sun Microsystems






Sun Microsystems




 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 May 4 teleconf are posted at:



These include Jeff M in the roll call.


The minutes of May 11 Teleconf are posted at:




Defer approval to next meeting.


4         Status of Action Items


 ·  Action Item list from 5/11 meeting
From Tom Rutt <tom@coastin.com> on
18 May 2004 16:00:29 -0000


Iwasa to incorporate resolutions from 5/11 meeting on 11.14


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 042904-3  (Jacques) Pending

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

4.3      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
Closed no text provided.  Will discuss.

4.4      Action 050404-1 (Iwasa)

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

4.5      Action 050404-2 (Iwasa)

Action: Iwasa should check if item 7.13 is done.

4.6      Action 050404-3 (Iwasa)

Action iwasa needs to clarify resolution of item 10.3.
Will check the appendix for the updates.

4.7      Action 050404-4 (Iwasa)

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

4.8      Action 050404-5 (Iwasa)

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.

4.9      Action 050404-7 (Iwasa and Jacques)

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



4.10Action 051104-1 (Tom)

Action: Tom will reopen issue on not supported feature fault for discussion at next week meeting.



4.11Action 051104-2 (Iwasa)


Ø Action: Iwasa to apply PC11.6 resolution



4.12Action 051104-3 (Tony)


Ø Action Tony will take PC 11.11 to email discussion



4.13Action 051104-4 (Iwasa and Jacques)


Action:  Editors shall incorporate PC11.14 into next draft



4.14Action 051104-5 (Tony)


PC11.15 and 11.19


Tony: Action to send to the list the exact change required on the .996 text.



4.15Action 051104-6 (Iwasa)

Ø Iwasa: action to add period if missing for PC11.20


4.16Action 051104-7 (Iwasa)


Ø Action: Iwasa will turn smart quotes to normal quotes.  Tom will send the required edits to remove smart quotes to Iwasa

Still open

4.17Action 051104-8 (Tom)


Ø Action: tom will start email discussion on this normative statement of our soap http post binding, and proper conformance text.


4.18Action 051104-9 (Anish)


Ø Anish action to provide amended proposal on reply to element, target for approval at next meeting.

Closed  will discuss at meeting


4.19Action 051104-10 (Jacques)


The current answer is only about reply patterns.

Ø Jacques; Action: Jacques will write an answer to the FAW question on how WS-Reliability relates to WSDL operation types. 




Ø Action: Iwasa will update the issues list on closure.



5         Discussion of Issues and editorial Comments

The following issues list not updated from last weeks minutes yet) includes open items which need further discussion:




5.1      PC3.14 Not Supported Feature Fault


Alan Weissberger 
Title: Not Supported Feature Fault condition 
Line 408-406: If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender Alan suggested: MUST BE 
Proposal: the text regarding MUST send for faults should be stated in a general manner to accommodate polling or delayed callback.  A single section to explain what _sending a fault_ means. _Sending an RMfault must be interpreted differently depending on the reply pattern in use._ 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 Resolution: agreed not yet fully applied.
From Last week’s minutes;
Tom: Issue on not supported feature: this is application specific, leave to profiles.  
Bob F: I agree this detail can be left to profiles.
Jacques: this is not critical to the reliablility protocol.  An implementation would still work if it sends no faults at all.  Faults could be viewed as convenience feature.  We need to be consistent across the spec.
No opposition to closing without change statement.
Close Issue 3.14 with no change, moved by Bob, seconded by Iwasa.
No opposition will close Issue 3.14 without change.

5.2      Editorial comments from Tony Graham (items PC11.x)


Mail from Tony Graham:


·  Re: [wsrm] New Editor's draft .996 posted (with Jacques Refactoringchanges)
From Tony Graham <Tony.Graham@Sun.COM> on
3 May 2004 22:30:18 -0000


5.2.1      PC11.11


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


   I would like this to be explained to me.







Tony Graham


Title: Section 1.6 line 288, 304

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

Proposal: Need resolution. (Not applied)Proposal: replacing _The time_ with _The order_



Agreed to proposed editorial resolution above, which was provided by Iwasa.. 


5.2.2      PC11.15


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.






Tony Graham


Title: line 336 of .993

Description: A reply may now include multiple Acknowledgment Indications.

Proposal: Needs text, if required.



Mail from Tony:


·  PC11.15
From Tony Graham <Tony.Graham@Sun.COM> on
18 May 2004 21:22:25 -0000


Lines 201-202 of 0.997:


An indication referring to a previous message, that is either an

Acknowledgment Indication or a Reliable Messaging Fault Indication.


Proposed replacement:


An indication from the Receiving RMP of the success or failure of the

deliver operation of one or more previous messages that were sent by

the Sending RMP.





Tony Graham


Tom: the term reply was intended to be for a single request message.  The response could contain the replies for multiple messages.


Response could be a definition for multiple replies.


Take this back to the list for further discussion.


5.3      PC11.19






Tony Graham


Title: line 366 of .993

Description: "between the application layer, the sender and receiver RMPs" does notscan.

Proposal: 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.



The line 336. has nothing to do with multiple acks


Tony: Action to send to the list the exact change required on the .996 text.




Mail from Tony:

·  PC11.19
From Tony Graham <Tony.Graham@Sun.COM> on
18 May 2004 21:27:59 -0000


My comment on the text:
   between the application layer, the sender and receiver RMPs
was purely about the punctuation.
I do not have the same quibble about lines 294-295 of 0.997.


Closed as accommodated by Jacques editing, will do final punctuation check linter.

5.3.1      PC11.24





Tony Graham


Title: Section 3, Reliability Features

Description: "Business payload" is undefined.

Proposal: Line 499Needs definition for Business payload or replacement text

Resolution: still open




Leave this open.


Take to the list.


5.3.2      PC11.5






Tony Graham


Title: section 1.3 notiation conventions

Description: section 1.5 - xml declarations in example

Proposal: 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



Discussion from Last week

Tony: we could leave to the Editors. 


Doug: the xml declaration is an optional part of an xml instance.  Soap does not require the xml declaration.  As long as it is in utf-8 any parser should work.


Suggested  to remove to xml declarations in the examples.


Leave open have discussion on email.

Pending resolution agreed to remove.


Ø Iwasa take action to remove the xml declarations from the examples.


Agreed to remove.


5.4      PC13 HTTP POST as Mandatory






Tom Ruttl


Title: HTTP POST Binding Clarification

Description: We need to clarifiy that the mandatory binding in the spec is to use htttp post.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.

Proposal: Needs discussion




Discussion from 5/11:

What is the conformance requirement of this spec with respect to soap over HTTP.


The soap binding we have could be normative but optional complienace point.


Define a compliance point in the conformance section. For this compliance point.


Sunil The protocol is supposed to be transport agnostic.  There has to be a soap binding to transport.


Anish: you can use a binding which supports soap.  Is it enough to say HTTP post binding.  We could say HTTP post method.  It would be more appropriate to state WSDL 1.1 soap binding. Can used the binding which is defined in soap 1.1


Tom:  Agreed in principal,  we will define a normative soap binding, but not require that binding for conformance.


We talk about WSI compliant in another section.  This is only meaningful with http binding.


Mail from Tom Rutt:


 ·  Clarification of HTTP POST Binding for WS_Reliability
From Tom Rutt <tom@coastin.com> on
18 May 2004 21:22:35 -0000


Add the following paragraph to the intro to section 6


This section specifies a normative binding of WS-Reliability soap header elements, using the SOAP binding to HTTP, as specified in Section 6 of SOAP 1.1.   The WS-Reliability header elements, when mapped to an HTTP request, must be carried in an HTTP POST operation.



Add the following sentence to the conformance clause:


The binding of WS-Reliability protocol specified in Section 6 of this specification, using SOAP HTTP binding defined in section 6 of SOAP 1.1, must be used when this specification is bound to SOAP over HTTP.



Iwasa: it would be better to make a strong conformance statement.


Anish: What do you intend on this wording.  Are other protocol transport bindings allowed.


Tom: the intent is If you use this spec with SOAP over HTTP you must use the binding in section 6.


Take this to the list.

5.5      PC14 Extensibility of ReplyTo attribute






Anish Karmarkar


Title: replyTo attribute extensibility

Description: 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: AnishEmailMay04

Proposal: Meeting discussion: perhaps making ReplyTo an element with open content (any) for extensibility) with default restriction (in absence of other agreements) for HTTP POST Binding to be a URL for HTTP requestNeeds discusion



·  ·  Action 051104-9 (Anish) -- modified proposal for the 'replyTo' attribute
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
18 May 2004 21:30:28 -0000


New proposal from anish:




I took an action to provide an amended proposal on reply to element. This email fulfills that action.


Here is the modified proposal for the 'replyTo' attribute (the modifications are: removed the reference-scheme URI identifier for the case when only URIs are used, describes default for the ReplyTo element, makes the reference-schema attribute optional and provides a namespace URI for the type ServiceRefType):


This proposal replaces the 'replyTo' attribute with a 'ReplyTo' element with an open content and defines the default referencing scheme (URI) when used with WS-R. This allows WS-R to be used with URI and makes it extensible to use other addressing schemes (WSRef, EPR or whatever may emerge out of other standards TCs/WGs).


The crux of the proposal is as follows:


1) The replyTo attribute is used in two places: a) On the ReplyPattern element, and b) PollRequest element. This attribute is replaced with an element called 'ReplyTo' described below.


2) Define a new global schema type in the namespace "http://www.oasis-open.org/committees/wsrm/schema/1.1/reference" as follows:


<xsd:complexType name="ServiceRefType">


   <xsd:any namespace="##other" processContents="lax" minOccurs="1" maxOccurs="1"/>


  <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="optional"/>



3) Define a new global element decl in the WS-R namespace:


<xs:element name="ReplyTo" type="wsrm:ServiceRefType"/>


The value of the attribute reference-scheme specifies the "type" of the addressing scheme. When used in WS-R, if the attribute reference-scheme is not present then the reply-to address is a URI.


4) For the type PollRequestType convert the attribute 'replyTo' to an element 'ReplyTo' of type 'ServiceRefType' with minOccurs=0. PollRequestType schema type will be as follows:


<xsd:complexType name="PollRequestType">


    <xsd:extension base="wsrm:HeaderBaseType">


        <xsd:element name="RefToMessageIds" type="wsrm:RefToMessageIdsType" maxOccurs="unbounded"/>

        <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/>






5) For the type ReplyPatternType make it a complex content containing sequence of two elements 'Value' and 'ReplyTo as follows:


<xsd:complexType name="ReplyPatternType">


    <xsd:element name="Value" type="wsrm:ReplyPatterTypeValues"/>

    <xsd:element ref="wsrm:ReplyTo" minOccurs="0"/>





Details of changes required:


1) Modify the schema as stated above and create a new schema for NS "http://www.oasis-open.org/committees/wsrm/schema/1.1/reference" as stated above.


2) Remove line 644


3) Table 5:

s/none/Value, ReplyTo

remove "replyTo(URI"


4) Section 4.2.3 will have to change to say that the element 'Value' can have the values 'Response', 'Callback' or 'Poll'. In addition, a table for element 'Value' and 'ReplyTo' will have to be added. The description of replyTo attribute has to change to describe the element wsrm:ReplyTo. The meaning of the attribute 'reference-scheme' will have to be added along with the fact that the default is a URI.


5) Section 5.3, add a table for describing the ReplyTo element


6) Table 9 should be modified to remove 'replyTo(URI)' from the attribute row and 'ReplyTo" element should be added to the child elements row.


7) Replace lines 742-745 with the description of the 'ReplyTo' element, similar to (4) above.


8) Table 16, penultimate row, 2nd column:

s/replyTo attribute/ReplyTo element


9) replace 1331-1332 as follows:




<ReplyPattern replyTo="http://wsrsender.org/abc/wsrListnener">

















10) Line 639, 723, 986, 1376, 1379, 1390, 1437, 1438, 1448, 1453: s/replyTo attribute/ReplyTo element


11) replace 1466-1473 as follows:




<PollRequest xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" replyTo=”http://wsr-sender.org/xyz/servlet/wsrmListnener” soap:mustUnderstand="1">

  <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org">

    <SequenceNumberRange from="0" to="20"/>








<PollRequest xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"" soap:mustUnderstand="1">

  <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org">

    <SequenceNumberRange from="0" to="20"/>









12) Section A.V.F (lines 1775-1777):

Replace the section to conform to the new schema type wsrmr:ServiceRefType




A.V.F. ReplyTo URI

This property is identified by the QName "wsrmf:ReplyTo" and corresponds to the semantics

specified by the WS-Reliability reply-to. The type of this property is xs:anyURI.






A.V.F ReplyTo

This property is identified by the QName "wsrmf:ReplyTo" and corresponds to the semantics

specified by the WS-Reliability reply-to. The type of this property is wsrmr:ReplyTo.




13) In section A.VI,


a) add:


<xs:import namespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/reference"/>


after line 1784


b) add a namespace prefix 'wsrmr' corresponding to the NS  http://www.oasis-open.org/committees/wsrm/schema/1.1/reference


c) and replace 1797 with:


<xs:element name="ReplyTo" type="wsrmr:ServiceRefType"/>









Anish summarized:

There is a new namespace URI   1.1/reference.


Make attribute reference type optional in schema for service ref type.


For the Reply to element in WS-Reliability name space, if reference type attribute is not present, the default for the reply to element, used in WS-Reliability is URI  .


There is a typo on 13 b) need to add /reference


Agreed to put this on the agenda for next week.


Be prepared to vote on this proposal next week.


Doug: in the Reply to element in WSRM namespace is the default in the spec or in the schema.


Anish: it is not in the schema it is in the specification.


Doug moved to accept the proposal, Anish seconded.


State in the text not the schema, can repeat in each header used.


No opposition, motion passes.


6         Discussion of Document Progression.

Iwasa will repost the open office documents and put diffs of .997 against .996.


New editor draft by end of week for .998.


Resolve all issue by next week.


Documents by wed morning to do final editorial review.


Could conceivable issue 7 day cd ballot on June 12, to close June 9.


Doug, why not have a cd ballot at June 8 meeting.


Very stable document agreed by June 1.


We would have to resolve all open issue by next meeting.


Meeting CD ballot June 8


Doug asked the group if the feeling of the TC since the previous public review are sufficent to merit another public review.


Only two schema changes:  Start attribute and Reply to attribute.


Considerable editorial clarification throughout the document.


Bob: we have not changed the protocol operation much at all.


Doug: we do not have to, however is a substantially better written spec something that would promote more public review.  


Iwasa: most of the comments on public review, were from TC members, so I think the TC final review is enough.


Bob: while we have not made big changes, we have an open process which states public review is required.  I do think we would get any more comments from additional people.


The sessions  at OASIS caused some further clarification.  Unless we change the operation of the protocol or provide another mode of operation, the changes are not large.


Hitachi is working with the spec today, but until it stops changing we cannot finalize our implementation.  We could have an implementation in days or weeks.


Fujitsu is in the final stages of implementing the spec.


Oracle has not implemented the reply to, now that it stable we can.


Action: Give it to the  Demo Subcommittee to work on these letters.  Successfully using consistent with OASIS IPR policy


Tom will try to locate earlier submission to show Bob.


Bob will check with NEC..


7         Frequently Asked Questions


·  Updated WSRM FAQ
From Tom Rutt <tom@coastin.com> on 11 May 2004 01:11:54 -0000


The question:


Q: How does the WS-Reliability protocol relate to WSDL operation types?


The current answer is only about reply patterns.

Ø Jacques; Action: Jacques will write an answer to this question. 

After that we can decide if we need another question about reply pattern specifically.


Leave it open.


Motion to adjourn Bob F, anish seconded.

No opposition.

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