[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: action list status for discussion at meeting
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 5133Title: 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 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.” 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 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]