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