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

RE: mustUnderstand on client side

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 2 May 2001 11:26:01 -0400
To: <frystyk@microsoft.com>
Cc: dick@8760.com, xml-dist-app@w3.org
Message-ID: <OF1E853CA3.AC395E44-ON85256A40.0054E7FA@lotus.com>
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.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 2 May 2001 11:29:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC