action list status for discussion at meeting

[Tom Rutt <tom@coastin.com>]

Attached is the status of the action list.

The items in Red need to be discussed at today's call..

We need to check if Iwasa's action items are incorporated in the latest 
draft.

Tom Rutt
WSRM Chair

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Action Item List from Jan Face To Face Meeting

Action Item List Status - from Jan Face To Face Meeting

01/27/04

 

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 20^th. 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 20^th.  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.”

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

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

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

 

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

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

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

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

 

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

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

 

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

 

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

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

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