- 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>
>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 UTC