I like the wording:
When the Response RM-Reply Pattern is in use and the message cannot
be delivered to the Consumer, a SOAP Fault MUST be generated in addition
to the RM Fault.
This takes duplicate elimination out of the scope of the statment,
because it is not an RM fault, I am happy
with Doug's suggestion.
Jacques Durand wrote:
> Rewording for 1.01:
> - either solution is fine with me.
>
> Rewording lines 949-951 :
> - while I understand the concern, "do not rely exclusively on SOAP
> Faults" would suggest we
> still rely a good deal on it even if not completely,
> when in fact we do not rely at all in 99% of cases.
> How about "only rely marginally on the SOAP Fault model..." instead?
>
I think the marginality is a value judgement. I think Doug's words are
fine.
Tom Rutt
> Jacques
>
>
> R-----Original Message-----
> From: Doug Bunting [mailto:]
> Sent: Tuesday, June 08, 2004 5:26 PM
> To:
> Subject: [wsrm] proposed wording for bullet in 4.5
>
>
> During the call, our primary discussion began with the second to last
> bullet in section 4.5. In the 1.1-1.02 draft (as shown in the footer),
> sometimes called "1.01" and published 4 June 2004, this bullet appears at
> lines 958 though 964. I believe these comments overlap Tom's suggestions
> in his "Detailed Editorial Fixes for Sections 1 - 4 of ED 1.01" email
> identified as for "Line 961 through 965".
>
> Please note that this section is entitled "Fault Codes for Reliable
> Message
> Failures". As such, it is specific to faulting.
>
> The text reads in 1.01:
>
> "
> In case of a Response RM-Reply Pattern was required, and when the message
> cannot
> be delivered to the Consumer due to a failure in processing the RM
> headers,
> then a
> SOAP Fault MUST be generated in addition to the RM-Reply that contains
> the
> RM Fault.
> Because either a well-formed response or a SOAP Fault is expected on the
> sending
> side, then the response leg of the transaction MUST contain a SOAP
> Fault in
> the SOAP
> Body when no business response is available. More details are given in
> the HTTP
> Binding section.
> "
>
> Taking two of Mark Peel's suggestions (for line 958), one of Tom's
> (removing "that contains the RM fault") and the clarity we found
> during the
> teleconference, the new bullet would read:
>
> "
> When the Response RM-Reply Pattern is in use and the message cannot be
> delivered to the Consumer, the underlying protocol response MUST
> contain a
> SOAP Fault (in the SOAP Body) in addition to the appropriate RM Fault (in
> the SOAP Header).
> The sending RMP and producer expect either a complete response or a SOAP
> Fault when using the Response RM-Reply Pattern and this requirement
> satisfies those expectations.
> More details are given in the HTTP Binding section.
> "
>
> We have not previously discussed the second or third sentences of this
> draft. The above changes remove some duplicate text from the second
> sentence, moves some into the first sentence and rewords the
> remainder. If
> the group prefers less editorial changes and limiting the updates to the
> first sentence, I would suggest at least removing an extraneous "then"
> from
> the second. The new first sentence for this alternative would be:
>
> "
> When the Response RM-Reply Pattern is in use and the message cannot
> be delivered to the Consumer, a
> SOAP Fault MUST be generated in addition to the RM Fault.
> "
>
>
> Separately, lines 949-951 include the following sentence:
>
> "
> These protocol specific fault codes are
> returned by the Receiving RMP within the response header element.
> Reliable
> Message Faults are
> carried in the SOAP Header, and do not rely on the SOAP Fault model
> for the
> following reasons:
> "
>
> I believe the "do not reply" phrase is somewhat historical since SOAP
> Faults have been added and removed at various times. I suggest saying
> "do
> not reply exclusively" instead. The full sentence would then be:
>
> "
> These protocol specific fault codes are
> returned by the Receiving RMP within the response header element.
> Reliable
> Message Faults are
> carried in the SOAP Header, and do not rely exclusively on the SOAP Fault
> model for the following reasons:
> "
>
> thanx,
> doug
>
>
> 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.
>
--
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133