sending rm replies with soap faults

[Tom Rutt <tom@coastin.com>]

The behaviour of sending an rm reply with a soap fault when the message 
cannot be delivered
has been in the document for a while.

Draft .992 (the last CD) has the following in section 4.5
"
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.
1043
1044
1045
1046
1047
"

There were several edits of this wording, the last being suggest by 
Jacques in going from
.999 to 1.01:

.996 text in Fault section:

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.
1043
1044
1045
1046
1047
"

By draft .999 the text had been edited to the following:
"
In case of a Request-Response WSDL operation type, when the message 
cannot be
passed to the consumer due to a failure in processing the RM headers, 
and therefore
no application response can be returned, a SOAP Fault MUST be returned. 
If the RM
Fault is a Message Format fault, a SOAP client fault MUST be returned. 
If it is a
Message Processing fault, a soap:server fault MUST be returned. The 
latter case also
applies to responses to duplicate messages that are not delivered., In 
case a
“Response” ReplyPattern was required, the RM-Reply MUST be returned in the
header of the SOAP Fault message.
956
957
958
959
960
961
962
"

This changed the reason to "faulure in processing WS RM headers", but it 
kept the duplicate elimination condition.

There was another edit, suggested by Jacques to go from .999 to 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.
962
963
964
965
966
967
"

This last edit took away the text about duplicate elimination. The edit 
I proposed from 1.01 was trying to
generize the cause to be more than just a RM message header fault.

I was concerned that people would read this to be just Message Format 
Fault category, to the exclusion of
message processing fault category. I suggested the following change to 
remedy this:

"
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,
or other ws-reliability protocol related causes (such as elimination of 
duplicate
delivery), 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.
970
971
972
973
974
975
976
"
This was put in 1.01E. Doug objected to the edit, but his reasons for 
rejection apply to all the
preceeding versions of this paragraph.

Based on the discussion, I will move the text back to the way it was in 
1.01,
but I would rather have the text be changed from 1.01 to the following,

"
In case a Response RM-Reply Pattern is required, and when the message
cannot be delivered to the Consumer, then a SOAP Fault MUST be generated 
in addition to the RM-Reply for that message. 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.
970
971
972
973
974
975
976
"

This wording admits the duplicate elimination case, and avoids the 
confusion that the only thing causing
this behaviour is a message Format error.

Thoughts?

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133