RE: mustUnderstand on client side

Henrik wrote:
> Given the discussion, I think we have this case covered in that if the
> receiving SOAP processor doesn't deal with the mustUnderstand then it
> faults. Having the SOAP processor fault doesn't mean that a fault
> message MUST be sent somewhere. SOAP is deliberately silent on this
> issue.

I agree, the SOAP spec does provide some guidance for the case where a
processor
fails to understand a mustUnderstand header. I believe the SOAP spec should
also provide
some guidance for "how to respond" to a mustUnderstand fault, and this is
where the
spec is deliberately silent, as Henrik said.

Can you share the authors reasoning behind the deliberate silence?

Thanks,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> Sent: Wednesday, May 02, 2001 1:37 PM
> To: 'Doug Davis'
> Cc: Noah_Mendelsohn@lotus.com; Dick Brooks; xml-dist-app@w3.org
> Subject: RE: mustUnderstand on client side
>
>
>
> >For example, the case that started the entire thread:
> >
> >  an XMLP client(http client) receives a MustUnderstand
> >  header, that it doesn't understand, from an XMLP server
> >
> >What does it do? And what should the XMLP spec say it
> >should do?
>
> Given the discussion, I think we have this case covered in that if the
> receiving SOAP processor doesn't deal with the mustUnderstand then it
> faults. Having the SOAP processor fault doesn't mean that a fault
> message MUST be sent somewhere. SOAP is deliberately silent on this
> issue.
>
> >IMHO, it should say something along the lines of:
> >  If an XMLP processor faults and it is possible for a
> >  message to be sent back to the originator of the
> >  message then a fault MUST be sent back.  If a message
> >  can not be sent back to the originator then a fault
> >  should be processed (ie. thrown) at the XMLP processor
> >  that detected the error.
> >
> >Or something like that.  The point isn't so much the
> >exact wording of the rule, but rather that I think we need
> >to be somewhat specific about what happens because right
> >now the SOAP spec is vague about this.
>
> I don't think we should require this - there are cases where there might
> be a bi-directional channel but the initial sender in fact doesn't want
> a response or where a fault should be sent to some other place than the
> initial sender.
>
> One can imagine describing such semantics in a module - which for
> example is related to routing.
>
> Henrik

Received on Wednesday, 2 May 2001 14:54:15 UTC