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 today's call

attached is the full agenda for today's call

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

Full Agenda WSRM TC Conference Call – Jan 27, 2004


The meeting of the WSRM TC took place by teleconference 
Tuesday Jan 06 2004, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)
Conference call Dial-in number : Toll number (only): 1-512-225-3050 Participant code: 89772 

0         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 - http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5166/Minutes-Jan04f2f-b.htm

3 Discussion of New Orleans Meeting and Conference papers

4 Discussion of Action Items - http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5090/Action%20Item%20List%20from%20Jan%20Face%20To%20Face%20Meeting.htm

5 Discussions of Issues Agenda approves

1         Roll Call


Meeting was quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.


??? agreed to serve for issue resolutions.

2.2      Approval of previous meeting minutes

xx moved to accept the Jan f2f  minutes. Zzz  seconded.
?? opposition, f2f  minutes approved.


3         Discussion of New Orleans Meeting and Conference

Tom Rutt received the following mail from Oasis Staff:

Hello Chairs,


This is the preliminary schedule that we have for TC meetings in New

Orleans. As you can imagine, we need to guarantee a quantity of sleeping

rooms in order to get the meeting room space at no charge, so it's important

that I get a final commitment. Please confirm the number of TC members that

have booked their rooms and please confirm the meeting times for your TC. I

can not confirm meeting rooms until reservations are made. Also, please let

me know if you need 1/2 day instead of full day, plan to meet from

8:00am-12:00pm or 1:00-5:00pm. Thank you for your prompt reply.





Small Room One


Wednesday - OASIS Board

Thursday - OASIS Board



Small Room Two


Wednesday - OASIS WS Reliable Messaging TC

Thursday - OASIS WS Reliable Messaging TC



Large Room Three


Wednesday - OASIS Legal XML Member Section Electronic Court Filing Technical


Thursday - OASIS Legal XML Member Section Electronic Court Filing Technical




Large Room Four


Wednesday - OASIS ebXML Registry TC

Thursday -  WS-CAF TC



Small Room Five


Wednesday - OASIS XDI TC

Thursday - OASIS Emergency Management TC


Small Room Six


Wednesday - OASIS ebXML CPPA

Thursday - OASIS CAM TC


Small Room Seven


Wednesday - OASIS ebXML Messaging TC

Thursday - OASIS ebXML Messaging TC



4         Discussion of Action Item Status from Jan F2F meeting

Action Item List Status - from Jan Face To Face Meeting



1.      ACTION: Need to ensure faults in general being Cleaned up  Sunil will try to get a proposal to clean up fault text before the end of the F2f.. - DONE

2.      Action: Iwasa to apply changes for reo 44, then we will change status after done.

3.      Action: Iwasa is to produce a change barred version of all the changes made from the 1-06 document.  Use compare documents under Edit to do it.

4.      ACTION: Sunil took action to come up with additions to the model text for section 2.1 by Friday. – Done Suni updated section 2 for polling

5.      ACTION: Jacques will make a proposal to fix these group semantic concerns. Done, sent proposed updated wording to Iwasa, which he has consolidated in last spec draft. See section 2.2 ("Groups of messages and message identity").


6.      ACTION: Iwasa needs to remove the sentence on the description of invalidExipiryTime stating it is sent when the message expires.

7.      ACTION: Iwasa has to factor in the new syntax for the message Id schema in section 3.3.  The sections need to be rearranged since some items have been changed from elements to attributes., and some of the names have changed

8.      ACTION: Sunil will provide text to include in the specification for what is not covered by existing protocol for request/response support. – done, see AI 9

9.      ACTION: Sunil will put a statement in a note regarding reply pattern for one-way wsdl operations, to add to the operation/replypattern table.

  Section 2.9


  This specification supports Reliable Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response operation types only. While a Request-reponse operation can use any of the three RM-Reply patterns to receive acknowledgments or faults, an One-way operation can only use either Callback or Poll RM-Reply pattern. See the table below for a complete support matrix:


                        <insert chart 1>


  Insert another foot note for Supported items for R-R operation under Callback and Poll patterns.


  For that footnote, description should be: While the specification doesn’t prohibit using Callback or Poll RM-Reply patterns to receive acknowledgments or  faults for a Request-response operation, it is encouraged to use Response RM-Reply pattern for such operations as the acknowledgment or the fault can be sent on the same response itself thus saving extra round trips.


10.  ACTION: Iwasa will change MAY OPTIONAL for parameters to use cardinality instead, for the entire document.

11.  ACTION: Sunil will provide a complete spec of the wsdl extension feature before we decided on the resolution.

Done. Sent an email on Jan 20th. http://www.oasis-open.org/archives/wsrm/200401/msg00079.html

   -One change there after. Add the usage attribute with 2 different values (optional and required) on all the 3 elements.

12.  ACTION; Sunil will incorporate the processing faults into his fault proposal for review on Friday morning. – done see AI 14


13.  ACTION: Iwasa to change, in the first sentence of definition of guranteed delivery to: “A message submitted to the sending rmp with guaranteed delivery requested, will either be delivered by the receiving rmp, or the sending rmp will notify the submitter of failure. “

14.  ACTION: Sunil will provide a new section 4,

Done. Sent an email on Jan 20th.  http://www.oasis-open.org/archives/wsrm/200401/msg00078.html


15.  Action: Iwasa to add sentence: This element has cardinality zero or 1 in the rm-request message.

16.  ACTION: Iwasa to add explanation for the table rows in Section 3: e.g., for cardinality: “cardinality is a constraint on the number of instances of an item type which may be present in an enclosing item.”

17.  Action: Iwasa will finish updating section 3 to fully reflect the syntax changes for message references.

18.  Action: Sunil will update the schema. – done

Uploaded the schema (http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5057/ws-reliability-2004-01-16a.xsd)

     - Fixed a typo there after. Element name under MessageId should have been SequenceNum and not SequenceNumbe

19.  ACTION :Sunil will come up with text to resolve this issue on clarification of Poll semantics..

I’d like to propose that we add a new sub-section under Section 2 to explain in detail the Poll semantics and usage.


   Section 2.X Poll Reply Pattern Semantics and Usage


   Guaranteed Delivery will be most commonly used for a one-way message as the Sender know the status of the message delivery otherwise.


   So the most common use case would be to use AckRequested with Callback RM-Reply pattern so that the Sender can receive the acknowledgement or a fault on a listener at its end. However this pattern doesn’t help when the Sender is within a firewall, as one cannot receive requests without opening a firewall, thus causing security lapses.


An alternate solution would be for the Sender to ask the Receiver for the receiving status of the message it has sent earlier on a different channel. Such a pattern is called the poll RM-Reply pattern. The Sender sends a Poll request for a message it would like to inquire and the Receiver sends a Poll response with the acknowledgement.  The Sender can also batch multiple Poll requests for an efficient use. Receiver in such case will send acknowledgements for those messages it has received. If a Poll request is partially or completely  invalid or wrong, then the Receiver sends either a InvalidPollRequest  or InvalidMessageId Fault back.


Also, a RM Poll response MUST NOT be piggybacked on a different RM Poll request.


20.  ACTION: Iwasa will add sub-section to section 3 for Fault element.

21.  ACTION: Sunil will update to have the soap 1.2 mapping of ws-reliability will not use the rm:fault element, but instead will use the soap 1.2 Subcode element. Done

Done. I’ve mentioned in the Section 4.0 of my write-up.  Iwasa need to add this in Section 3 when describing the Fault element.

22.  ACTION: Iwasa will put soap 1.2 statement in the new section in 3 on rm:fault element.

23.  ACTION: Sunil will incorporate amended fault proposal into the Schema and into the new text for section 4. Done see AI 14


24.  ACTION: Iwasa will update section 3 to accommodate the new fault proposal

25.  ACTION: Sunil add text that a response to a poll may not coexist with a rm:request header.  Done see AI 19


26.  ACTION: Iwasa make the changes requested by Jacques for section 2 lead in.


27.  ACTION: Jacques will add clarification of sender/receiver synch of termination  criteria for his homework on clarifying group termination. Done, provided to Iwasa as an updated draft, where the Group termination section has been significantly reworded.

28.  ACTION: Iwasa will start working on new examples.

29.  Action: Editors will produce up to date issues list by the next meeting.




5         Discussion of Issues


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