RE: mustUnderstand on client side

Hi Doug,

I also think we should give some thought to what should happen if an XMLP
processor faults while processing a fault message! Missing details can lead
to melt down :-)

Stuart

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: 02 May 2001 18:19
> To: frystyk@microsoft.com
> Cc: Noah_Mendelsohn@lotus.com; dick@8760.com; xml-dist-app@w3.org
> Subject: 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 14:24:44 UTC