New Proposal to resolve Rel 108 and 115

[Tom Rutt <tom@coastin.com>]

Attached is the new proposal to resolve rel 108 and 115.

This supercedes the earlier proposal.

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


New Proposal to Resolve Rel 108/115 thru unified Response Element

This proposes to make RM-fault reporting mechanism orthogonal to Soap Fault 
model.

The soap fault model will remain in place for faults associated with the soap 
body of the request.

I propose that we not not map RM-fault to soap fault for any of our response 
reply patterns.

Conceptually, it works to keep the rm fault model and the soap fault model 
separate and distinct

If we take this principal, there is no Fundamental problem having a rm-response 
indicate both acknowledgements and RM faults.

So given the above rational I propose the following detailed changes to resolve 
R108/115:

Rewrite the Response Element section, 3.4 and schema to allow to have one 
element returned per group being reported. 

That element has a groupID attribute, and zero or more lists.
a) a list of sequence numbers to report messages in that group which have been 
delivered. (for a singleton group ack this sequence number list is empty)
b) for each fault code which has been encountered for messages in that group, an 
element which has the fault code and a list of sequence numbers which faulted 
due to that code (for a singleton group ack this sequence number list is empty).  

This proposed response  mechanism does not include fault detail info, however 
that could go into extensions to the reply elements if so warranted.
 
The detailed proposed changes to the schema and the response element text are 
posted at:
  http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5628/ws-
reliability-SchemaProposal-2-23.zip 

Other changes are proposed as follows:
---------
Remove the Fault element section, 3.5.

In Section 4, on Faults: 

Lines 1243-1261 need to be replaced with the following:
“
4   Fault Processing
This section describes the protocol specific fault codes that are needed to 
better describe the reason for ws reliability protocol processing failures .

We categorize the faults into 2 categories based on whether the fault was 
generated because Reliable Messaging Headers are malformed or invalid or because 
of the some runtime processing errors encountered by the RMP. 

The former category is called Invalid Message Format fault set and the latter is 
called Request Processing  fault set. They are explained in detail in the 
following sections.


These protocol specific fault codes are returned by the receiving RMP within the 
response  header element. 

The WS reliability protocol does not directly map our rm faults  to the soap 
fault model.

The soap fault model is used for reporting faults due to the request payload, 
which fits the soap fault model better.

Thus an rm-fault could come in a soap fault message, but the reason for the soap 
fault would be due to problems caused by the message payoad

Example case 1:
For wsdl request/response operation types, a soap fault can occur for a reliable 
request which was delivered , but then encountered an application level fault 
due to something wrong in the payload  (soap body of request which is not under 
control of Sending RMP) or application processing space outside the realm of the 
Receiving rmp.

That means a reliable messsage acknolwedgement can be delivered on a soap fault.

Example case 2: 
For the response reply pattern, used with wsdl two way operation type, the 
return message could conceivably carry an indication of an RM fault, which is 
not itself carried on a soap fault.  The exact behaviour in such a case might be 
an implementation matter.

A message with an RM fault indication MUST not be delivered by the Receiving RMP.  
If the message cannot be delivered due, say  an  request  fault, then there 
would be no meaningful data for the responder to put  into the soap body for the 
WSDL response.

In some implementations, the responding application may not be available to 
participate in a decision to issue a Soap fault for this non delivered request. 
With such an implementation, the RM fault indication could be carried on an http 
response, which only includes the RM response header and an empty soap body.

Other implementations which are more aware of the wsdl operation definition, 
might be able to also realize that a soap fault has occurred for that messageID.  
With such an implementation for the response reply pattern case, the RM reply 
could be carried on a soap fault message associated with the wsdl operation 
itself.

4.1 Fault Codes For Reliable Messaging Failures

The following fault codes may be caried in an RM response element associated 
with a meesage ID.
“