OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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