RE: mustUnderstand on client side

I'd like to move the conversation into a more concrete
realm, if I may.  I think we all basically agree that
MustUnderstands must be understood and if not then fault.
That part is easy.  What I'd like for us to do is to
figure out what to say in the XMLP spec to help
implementors in the nontrivial cases.  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?

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.

-Dug


"Henrik Frystyk Nielsen" <frystyk@microsoft.com>@w3.org on 05/02/2001
11:52:16 AM

Please respond to <frystyk@microsoft.com>

Sent by:  xml-dist-app-request@w3.org


To:   <Noah_Mendelsohn@lotus.com>
cc:   <dick@8760.com>, <xml-dist-app@w3.org>
Subject:  RE: mustUnderstand on client side




Well stated! I think you bring up an important point in suggesting the
possibility of not just looking at r/r but also include more
conversation style message exchange patterns and even how these might
relate to guaranteed delivery etc. This is not to say that I think we
are to define guaranteed delivery but we have to consider the
composability aspect.

Henrik

>To paraphrase what I think Henrik is saying (I.e. to make sure
>we agree),
>I do think we have reasonably clear semantics in SOAP for
>mustUnderstand
>at the client.  They are the same as anywhere else:  get a
>message with a
>mustUnderstand header that you don't understand, you (a) don't
>process the
>message and (b) generate a fault.  Now, whether the fault is reliably
>delivered anywhere is not specified, but (a) is really a significant
>building block.  If a responder sends mustUnderstand then it
>knows that
>the message won't be processed if not understood.  In particular
>deployment scenarios, one could imagine sending the fault
>back, but then
>you get into the usual circularity.  What if the fault can't
>be delivered?
> How long must the responder stay around waiting for it?  You
>really are
>in the realm not of request/response, but conversation with r/r hidden
>within the conversation.  That is something we might consider as a
>supported pattern for XMLP, and in that case I think we can specify
>delivery rules for the client fault.  So, I claim SOAP gives you the
>building blocks you reasonably need for one scenario or another.

Received on Wednesday, 2 May 2001 13:20:54 UTC