Re: [wsrm] REL-xyz:proposal to add a new attribute (messageType)toResponse element

Tony Graham wrote:
Sunil Kunisetty <> wrote
at Mon, 09 Feb 2004 17:26:10 -0800:

> Tony Graham wrote:

> > Sunil Kunisetty <> wrote at Mon, 09
Feb 2004 11:11:06 -0800:

> > ...

> > > Sunil Kunisetty wrote:

> > >

> > > >  I like to suggest that we add an attribute by name messageType
to the

> > > >  response Header element to easily distinguish a RM-Fault
message with

> > > >  an RM-Ack. Message. Currently we need to check for the
existence of

> > > >  the Fault Header (for SOAP 1.1_ to distinguish an Ack.
To a Fault.

> > > >  This is some what tedious and instead having a simple
attribute with the type

> > > >  of the message will make it simpler and less error prone.

> >

> > If checking for the existence of a SOAP Header Element is tedious
and

> > error prone, then setting an attribute under some circumstances
is, if

> > anything, more tedious and error prone.

> >

>

>  Checking itself is not the only problem, the problem is the
dependency.

>  I've sent a more detailed response today morning. Let me know
if

>  you see any problems with my reasoning.

I fear that adding an attribute is a workaround, not a solution, but
I

will need to look at your response in more detail.
 Please. Let me know if you still see an issue.
 

> > A better optimisation would be to put the Fault element, if any,

> > *inside* the Response element or to allow the content of the Response

> > element inside the Fault element.

>

>  That would have been one option. However, currently for SOAP
1.1 case

>  we send the Fault using a Header and for SOAP 1.2 case we
use the

>  SOAP 1.2 Fault/subcode mechanism. Because of the latter
we couldn't

>  embed the Fault inside the Response.

I figured SOAP 1.2 would figure in it.

A SOAP 1.2 Fault element inside a SOAP header block has no
 In the 1.2 case,  Faults are sent inside the Body/Fault and
not in a Header

 unlike the 1.1 case. That's why we don't want to  intermix
fault codes in

 the Response element.
 

SOAP-defined semantics anyway, which is where you have to put the

Fault element if you were piggybacking the Fault message on a Normal

message (not that we seem to have the term anymore).

In any case, you could put the message id information inside the SOAP

Detail element of a SOAP 1.2 Fault element.
 Yes. That's what we are doing. That's what I meant above by "for
SOAP 1.2 case we use the

     SOAP 1.2 Fault/subcode mechanism. Because
of the latter we couldn't

 embed the Fault inside the Response."
 

> > Either of those would make the fault processing more useful with
the

> > Poll reply pattern since you could then return a set of faults
and

> > acknowledgments in the response to a PollRequest.

>

>  At the time we don't support set-of-faults case. What we have
currently

>  is the all or none approach.

>

> >

> >

> > I still suspect that Sunil misunderstood me in his response to
my

> > message of 16th January:

> >

> >  | > 748     While a PollRequest can request
acknowledgment of a messages

> >  | >         with
a range of sequence number values, it is not clear what

> >  | >         happens
when one or more of the messages in that range caused

> >  | >         faults.

>

>  If the request itself is wrong, such as, wrong range or wrong
group

>  id. no., then we send either the InvalidPollRequest or

>  InvalidMessageId, or InvalidMessageParameters depending upon
the

>  cause.

>

>  If the request information is correct or valid, then the Response

>  contain message ids that are delivered. Response doesn't contain

>  message ids that resulted in faults.

So the sending RMP never gets a fault for a Reliable Message that was

 Yes and No.

 Yes, you get the Fault if you  use the Callback or Response
Reply Pattern.

 No for Poll.  It's a known limitation for Poll  - 
a trade off for simplicity.

 That's why it is a more a Poll request rather a Status request.
 

sent containing an error?  What does that say about the "per Reliable

Message" Notify "abstract operation" for the Poll RM-Reply Pattern?

Also, isn't the sending RMP just going to keep resending the same

flawed message since it never receives an Acknowledgment for it?
 You can still get the fault if you use the Callback or Response pattern.

 Only for Poll, you don't get. Poll just sends the list of messages
that

 was delivered to the next layer, unless processing the Poll request

 itself fails.

 We need to clarify this in our specification.

 thx!

 -Sunil