Hi Sunil,
If we add "messageType" attribute for Response Element,
which value is either "Acknowledgment" or "Fault",
that would solve the issue.
Thanks,
Iwasa
----- Original Message -----
From: "Sunil Kunisetty" <>
To: "iwasa" <>
Cc: "wsrm" <>
Sent: Monday, February 02, 2004 4:12 PM
Subject: Re: [wsrm] Ack message and Fault message
>
> Hi Iwasa,
>
> iwasa wrote:
>
> > Sunil,
> >
> > I found one other question - which is potentially
> > new issue.
> >
> > Before diving into new question,
> > let me draw some quick example here
> > to make sure what you said:
> >
> > 1.Normal Ack Message without piggybacking
> > <soap:envelope>
> > <soap:header>
> > <rm:Response>
> > <rm:RefToMessageIds>
> > <SequenceNumRange/>
> > </rm:RefToMessageIds>
> > </rm:Response>
> > </soap:header>
> > <soap:body/>
> >
>
> The above example should also have a MessageHeader Header with
> MessageId with no SeqNum. , ExpiryTime and ReplyPattern (will be the same
> value as that of the Request - see REL 99).
>
> >
> > 2.Fault Message with SOAP1.1
> > <soap:envelope>
> > <soap:header>
> > <rm:Fault>xxxx Fault</rm:Fault>
> > </soap:header>
> > <soap:body/>
> >
>
> Even Fault will have a MessageHeader/. Infact, a RM Fault message will
have
> a MessageHeader, Response (bcoz we need to RefToMessageId) and a
> SOAP Body with SOAP Fault contents.
>
> Thinking about it, I feel that RM Response Header should have an
attribute
> called messageType to easily distinguish Ack. message with Fault message
> just as we had it in our version we submitted to this TC. Let me send a
> separate mail raising this issue.
>
> >
> > What I wanted to make sure were:
> > 1. Ack message without piggybacking
> > do not include <rm:Header> element.
> > 2. Fault message without piggybacking
> > do not include <rm:Header> element.
> > And it seems to be correct with Sunil's reply.
>
> No, that's not true. Every RM message should have the MessageHeader.
> I did mention this clearly in my previous mail . See below too:
> " MessageHeader has to exist for every RM message"
>
> >
> >
> > The new question is how we can notify
> > MessageId in the Fault Message.
> > I believe Fault message have to include
> > RefToMessageId for the fault.
> > Example 2 above can't identify the original
> > message that caused the fault.
>
> It gets the RefToMessageId from the Response element,
> So what's missing is the easy to figure out whether it's
> an Ack. or Fault message given the Response element alone.
>
> So in the spec. we submitted to the TC, we had a message-type
> element. We need to reintroduce it.
>
> >
> >
> > There are three ways to fix this issue:
> > The first one is Fault message also include Response
> > element(Example 3 below).
> >
>
> I was always under the above assumption based on our
> initial spec.
>
> >
> > The second one is
> > to change location of Fault element as child element
> > of Response element and allow it appears for Fault
> > message only.
> >
>
> The problem with the above approach will be that for SOAP 1.2
> we won't be needing the Fault Header and hence it will be
> very confusing.
>
> >
> > The third one is
> > to add new Code element and RefToMessageId
> > element under Fault element(Example 5 below).
> > And I prefer the last one, since the first two may be
> > confusing. How do you think?
>
> This has the same drawback as the above one for SOAP 1.2.
> We need to isolate Fault with Response so that we can keep
> the same syntax for Response in both SOAP 1.1 and 1.2 case.
>
> >
> > 3.Candidate Fault Message with SOAP1.1 (1)
> > <soap:envelope>
> > <soap:header>
> > <rm:Response>
> > <rm:RefToMessageIds>
> > <SequenceNumRange/>
> > </rm:RefToMessageIds>
> > </rm:Response>
> > <rm:Fault>xxxx Fault</rm:Fault>
> > </soap:header>
> > <soap:body/>
> >
>
> The above is my preferred with an additional messageType attribute.
> See my next mail following this one.
>
> >
> > 4.Candidate Fault Message with SOAP1.1 (2)
> > <soap:envelope>
> > <soap:header>
> > <rm:Response>
> > <rm:Fault>xxxx Fault</rm:Fault>
> > <rm:RefToMessageIds>
> > <SequenceNumRange/>
> > </rm:RefToMessageIds>
> > </rm:Response>
> > <rm:Fault>xxxx Fault</rm:Fault>
> > </soap:header>
> > <soap:body/>
> >
> > 5.Candidate Fault Message with SOAP1.1 (3)
> > <soap:envelope>
> > <soap:header>
> > <rm:Fault>
> > <rm:Code>xxxx Fault</rm:Code>
> > <rm:RefToMessageIds>
> > <SequenceNumRange/>
> > </rm:RefToMessageIds>
> > </rm:Fault>
> > </soap:header>
> > <soap:body/>
> >
> > If I misunderstood or I am missing something,
>
> I guess you have identified a bug/shortcoming :-)
>
> >
> > please let me know.
>
> Good catch!
>
> >
> >
> > Thanks,
> >
> > Iwasa
> >
> > ----- Original Message -----
> > From: "Sunil Kunisetty" <>
> > To: "iwasa" <>
> > Cc: "wsrm" <>
> > Sent: Saturday, January 31, 2004 1:07 AM
> > Subject: Re: [wsrm] Ack message and Fault message
> >
> > >
> > > Iwasa,
> > >
> > > Ack. is ALWAYS included in the Response element and MessageHeader
> > > has to exist for every RM message. This is the case even for
> > piggybacking.
> > > The difference between a normal ack. and piggybacked ack. is that, in
the
> > > latter case the (ack|fault) response is sent along with another
requeust,
> > > which means it will have a MessageHeader, Request, and Response
element.
> > > A normal ack. just has a MessageHeader and Response
> > >
> > > The same applies for Faults (the difference being instead of using
> > Response
> > > element, we will be usiing the Fault element) also except that for a
SOAP
> > 1.2
> > > RM msg, we never use the Fault element.
> > >
> > > HTH,
> > > -Sunil
> > >
> > > iwasa wrote:
> > >
> > > > All,
> > > >
> > > > I'm working on the examples. And I think I need to make
> > > > sure that:
> > > > 1) The Acknowledgment message is including
> > > > Response element, but not MessageHeader element
> > > > except piggybacking. Is this correct?
> > > > 2) The Fault message is including Fault element,
> > > > but not MessageHeader element exept piggybacking.
> > > > Is this also correct?
> > > >
> > > > There is no statement for 2) above in the spec.
> > > >
> > > > If there is no argument, I will include some text to resolve
> > > > this.
> > > >
> > > > Thanks,
> > > >
> > > > Iwasa
> > > >
> > > > 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.
> > >
>
