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