Re: [wsrm] Detailed proposal to allow Batching of Acks and RM faultsusing Response Reply pattern.

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 Agree with the new wordings.

 A unrelated question (wrt to this topic), but related to RM Faults and SOAP Faults
 is, if we are using RM Faults for RM stuff and not SOAP faults, what is the replacement
 for faultcode/faultstring (for 1.1 case and Code/Reason for 1.2 case) in the RM Faults.

 My earlier proposal for Faults said send Client/Server (Sender/Receiver for 1.2) codes
 depending the RM fault. We had 2 different categories of RM Faults which we clearly
 distinguished. An issue we never solved with the old approach was  when batching faults,
 if we have to send some Client and some Server faults, what should be the faultCode
 inside the SOAP Fault.

 This is not an issue if we are not using SOAP Faults.

 What to do with the RM Faults case? Shall we say it's upto the client to distinguish it
 based on the type of fault as specified in the specification.

 And what about the fault string?

 -Sunil

Tom Rutt wrote:

> Tom Rutt wrote:
>
> > Lines 1019 thru 1024 currently state the following:
> >
> > “
> > - *Response *: An Acknowledgment message (or Fault message) MUST be
> > sent back
> > directly in the response to the Reliable Message. This pattern is not
> > applicable for one-way application level MEP. The acknowledgment
> > message that can be sent back in the response is for the message in the
> > request only. Acknowledgment message for the former request
> > MUST NOT be sent back.
> > “
> >
> > To allow the receiving RMP to return acks or falts for former
> > requests, the last two sentences are too strong:
>
> Discussions have led to a concensus that the spec should be silent on
> sending extra information in the response for the response reply pattern.
>
> The proposal to resolve rel 108 and rel 115 includes restrictions on a
> response element pertaining to  response reply pattern.  These are
> the more approprate way to state the requirment, without disallowing
> extensions to provide more information.
>
> Delete  the last two sentences:
> "
> The acknowledgment message that can be sent back in the response is for
> the message in the
> request only. Acknowledgment message for the former request MUST NOT be
> sent back.
> "
>
> >
>
> --
> ----------------------------------------------------
> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
> 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.