W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

RE: mustUnderstand on client side

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Wed, 2 May 2001 11:37:21 -0700
To: "'Doug Davis'" <dug@us.ibm.com>
Cc: <Noah_Mendelsohn@lotus.com>, <dick@8760.com>, <xml-dist-app@w3.org>
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CBBA@red-msg-07.redmond.corp.microsoft.com>

>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:38:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT