[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] editorial comments on Latest editor's draft
Tom, By the way, why do you want to replace all Acknowledgment message and Fault message with RM-Reply? Even if we try to replace them, I don't think we can remove all of them, since RM-Reply need a definition of Acknowledgment message and Fault message to describe its own definition. See the current definition of RM-Reply: -- Reliable Messaging Reply (RM-Reply): A message which is either an Acknowledge Message or Reliable Messaging Fault message. -- So I don't think removing definition for Acknowledgment message and Fault message works. If I am missing something, please let me know. Iwasa ----- Original Message ----- From: "Tom Rutt" <tom@coastin.com> To: "wsrm" <wsrm@lists.oasis-open.org> Sent: Tuesday, March 02, 2004 5:52 AM Subject: [wsrm] editorial comments on Latest editor's draft > Attached is a text file with my editorial comments on the latest > editor's draft. > > There is a technical clarification on the use of soap faults for the > response reply pattern. > > There are several edits to eliminate "acknolwedgement message" or "fault > message" to replace with rm-reply terminology. > > With these editorial changes applied, It is my opinion that we have a > document which is ready for a TC candidate draft for vote. > > Tom Rutt > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > ---------------------------------------------------------------------------- ---- > Summary of Comments on > WS-Reliability-2004-02-26- tercom.pdf > Page: 10 > Sequence number: 1 > Section 1.7 Lines 316 - 319 - Change to " Reliable > Messaging Fault Indication - An indication, included in an > RM:Response element, which refers to a previous message > which encountered a Reliable Messaging fault condition at > the Receiving RMP. It signals to the sender of the referred > message that there was a failure to receive or process the > message." > > Sequence number: 2 > Section 1.7 Lines 310 - 314 : Change to "Acknowledgment > Indication - An indication, included in an RM:Response > element, which refers to a prevous message dellivered by > the Receiving RMP. An Acknolwedgment signals that the > acknolwdged message has been successfully delivered, > meaning that it has satisfied all the reliabiliyt > requiements placed on it for delivery." > > Sequence number: 3 > Section 1.7 Lines 321 - 322: Change to " Reliable Messaging > Reply (or RM-Reply): An indication in an RM:Response > element, referring to a previous message, that is either an > Acknowledgement Indication or a Reliable Messaging Fault > Indication. " > > Page: 14 > Sequence number: 1 > Section 2.2 Line 447 : Change "and the Acknowledgement > Message" to "and the RM Reply" > > Sequence number: 2 > Section 2.2 (1): The subtitle and Figure 1 title should be > "Response Message Reply Pattern". This is the correct name > of the pattern. > > Sequence number: 3 > Section 2.2 Line452 : change "Acknowledgement Message is > contained in" to "the RM Reply is contained in" > > Page: 15 > Sequence number: 1 > Section 2.2 Line 471 : Change "The Acknowledgment Message > is contained in" to "The RM Reply is contained in" > > Page: 16 > Sequence number: 1 > Section 3.1 line 495 : change "acknolwedgement message" to > "RM Reply for that message" > > Sequence number: 2 > Section 3.1 Line 500 : change "sender RMP fails to send the > message (i.e., no Acknowledgement is received), " to > "sender RMP > cannot guarantee that the message has been successfully > delivered by the receiving RMP, " > > Page: 25 > Sequence number: 1 > Section 4.2.3 Line 778 : Change "An Acknoledgemebnt message > (or Fault Message)" to "An rm-Reply" > > Page: 26 > Sequence number: 1 > Section 4.2.3 Line 787: The statement "The value of this > element in Request ..." is wrong. The requirements are > stated in the documentation of the response element., > Delete this sentence. > > Page: 28 > Sequence number: 1 > Section 4.3 Line 833 thru 836: change in each occurance on > these lines "Acknowledgement message" to "rm-Reply" > > Sequence number: 2 > Section 4.3 Line 837 and 838: change sentence to "The > response to a PollRequest message includes rm-reply > information about prior messages." > > Page: 29 > Sequence number: 1 > Section 4.3.1 Lines 864, 870, 872, and 875: change > "Acknowledgement Message" to "rm-reply" and "Acknowledgment > Messages" to "rm-replies" > > Page: 31 > Sequence number: 1 > Section 4.4 Lines 941 and 944: these two paragraphs need to > be recast as a bullet list under line 941. > > Page: 33 > Sequence number: 1 > 4.4.2.1 Line 972 : change title to "ReplyRange Element" > > Page: 34 > Sequence number: 1 > Section 4.5 Line 1000: change "invalid or because of the" > to "invalid due to" > > Sequence number: 2 > Section 4.5 Line 1009 and 1010: Change "the reason for the > SOAP Fault would be due to problems caused by the message > payload" to "the reason for the SOAP fault would be due to > problems associated with the WSDL operation message payload. > (e.g.., a problem with the soap:body of a request message > or the inability of the receiving RMP to return the WSDL > response in the soap:body of when using the response rm- > reply pattern). > > Sequence number: 3 > Section 4.5 Lines 1024 thru 1031: These two paragraphs need > to be rewritten. Change to the following: > "When using the response rm-reply pattern, a wsdl operation > reply will not always be available for the receiving RMP to > return with the rm-response. This will occur when there is > a reliable messaging fault for the message in the request, > or when the message in the request is a duplicate of a > prior delivered message with duplicate elimination in use. > > When a receiving RMP cannot return the wsdl operation > response for a request using the response reply pattern, it > MUST return the rm response in a SOAP Fault message. If the > rm fault encountered was due to a problem with the request > header element, a soap client fault MUST be returned. If > the rm fault encountered was due to a problem with > processing by the receiving RMP (including the inability to > return a response due to duplicate elimination), a > soap:server fault must be returned. > > Page: 36 > Sequence number: 1 > Section 4.5.l Line 1039: insert the following preamble at > the beginning of the paragraph, to "When the rm fault is > returned using the response rm reply pattern the following > apply:" and place the two sentences in a bullet list. > > Page: 37 > Sequence number: 1 > Section 4.5.2 Line 1049: insert the following preamble at > the beginning of the paragraph, to "When the rm fault is > returned using the > response rm reply pattern the following apply:" and plasce > the two sentences in a bullet list. > > Page: 61 > Sequence number: 1 > Line 1809 - delete this ResponsDisallowed fault code, since > it is handled by a soap fault, not an rm fault. > > > ---------------------------------------------------------------------------- ---- > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]