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

Re: mustUnderstand on client side

From: <Noah_Mendelsohn@lotus.com>
Date: Mon, 30 Apr 2001 20:16:27 -0400
To: xml-dist-app@w3.org
Message-ID: <OFD5630E24.B05174C7-ON85256A3F.0001823B@lotus.com>

I think I see this problem a little differently.

1. There has always been some question as to what happens to any faults
generated upon receipt of a one-way message.  Presumably, they are lost.  I
think that a mustUnderstand failure at the client is, as Mark suggests,
quite similar to a variety of other client side failures.  Furthermore, I
suspect that response messages will share many characteristics with one-way
messages.  In both cases, I think is reasonable to assume that the sender
(in this case, the responder to the original request) is no longer
available.

2. I am somewhat less concerned than Dick and Roger regarding the dangers
for applications.  The request/response nature of an interaction such as
submitting a purchase order is known to both parties, and definitely to the
responder which accepted and understood the purchase order request in the
first place.  If a response is sent with a mustUnderstand header, then
surely the responder understands that any resulting client side faults are
going to be lost.  So, at best that responder would understand that the
client is warned not to process the incomprehensible message.  Applications
would thus be ill-advised to use such mustUnderstand constructions in any
scenarios likely to suffer from the problems raised by Dick or Roger.
Stated simply:  nobody is forcing the responder to use mustUnderstand
headers in situations where they are going to cause trouble.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
Received on Monday, 30 April 2001 20:21:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:00 GMT