RE: mustUnderstand on client side

> 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 :-)

+1


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: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
> Sent: Wednesday, May 02, 2001 1:24 PM
> To: 'Doug Davis'
> Cc: Noah_Mendelsohn@lotus.com; Dick Brooks; xml-dist-app@w3.org;
> frystyk@microsoft.com
> Subject: 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:34:05 UTC