Re: [wsrm] Groups - WSRM TC Teleconference Meeting modified

Action Item List 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.

4. ACTION: Sunil took action to come up with additions to the model text for section 2.1 by Friday.

��Is this for polling ???

8. ACTION: Sunil� will provide text to include in the specification for what is not covered by existing protocol for request/response support.

��See the description for 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.

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 the resolution for AI-14.

� 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

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

��Guranteed Delivery will be most commonly used for an one-way message as the Sender won�t be knowing 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

�� 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 RM-Reply pattern. Sender sends a Poll request for a message it would like to inquire and

�� the Receiver sends a Poll response with the acknowledgement. A 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.

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

�

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

� Done. See the resolution for AI-14.

� 25.� ACTION: Sunil add text that a response to a poll may not coexist with a rm:request header.

� See the description for AI-19.

wsrm message