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: full agenda for may 04 teleconf

the full agenda with links is attached.

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

Full Agenda of WSRM TC Conference Call – Apr 20, 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)


Conference Bridge number
Toll only : 1-512-225-3050
Participant code: 716071


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




 Meeting ?? 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



xx moved to approve f2f  minutes.  YY seconded.


?? Opposition, Minutes ?? approved


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) Pending



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”.


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) Pending


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.


4.13Action 042904-11 – (Jacques) Pending


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:




also, to be discussed with this:


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

5.1      Syntax 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 looong 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.







5.2      Clarification 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





6         Discussion of Document Progression.


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. The 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.





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