Detailed proposal to resolve Rel 108 and 115

[Tom Rutt <tom@coastin.com>]

Attached is a detaile proposal.

The exact details of the schema change and text for the response element 
section will be sent in a later email,
after review by the subteam on the schema.

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


Proposal to Resolve Rel 108/115 thru unified Response Element

Make RM-fault reporting mechanism orthgonal 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 for a 
response reply pattern message having a batch of prior (especially if the transport 
connection is no longer available to send theme in their own responses) acks or fault 
indications.   


Thus perhaps we can soften the wording to allow a receiving RMP to batch both acks and 
fault indications on the response, for all reply patterns.  Giving extra information to the 
Sending RMP would help in cases where the previous tranport connection is no longer 
available to  return a prior ack.  If it goes to the wrong source, then it can be safely 
ignored by that source (because the other source would resend the prior message).  In 
cases where the sending RMP knows about the message IDs it will most likely appreciate 
the extra reply information.


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 singlton 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 singlton group ack this sequence number list is empty).  
This proposed response  mec does not include fault detail info, however that could go 
into extenstions to the fault element if so warranted.
 
  (the detailed changes  required will be sent out in a forthcoming mail after we get 
agreement in a small team working on the schema details)

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: (a little more complicated)
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 an be 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 
implementations,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 defintion, 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.
“