RE: mustUnderstand on client side

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

My experience comes mainly from the EDI world so I'll use and example from
the EDI culture to explain why I believe mustUnderstand semantics and
behavior must be clearly defined in XMLP and these rules must apply to
*all* SOAP message exchanges, regardless of the direction (request or
response).

The ANSI X12 community uses a version field within a message envelope
to identify the "rules" that govern a message exchange. A party that sends a
version "3040" is telling the receiver they follow the semantics defined
by version 3040 and they may not be capable of processing a message with a
higher version number (e.g. "4010").   A party with "higher" processing
capabilities will "drop back" to use an earlier version (e.g. "3040")
in order to "sync" up with a trading partner.

It's my understanding that SOAP has no such versioning mechanism to "sync"
communicating parties, but instead relies on a freely extensible,
mustUnderstand
attribute to ensure that two parties "understand the protocol". As SOAP
implementers evolve their implementations over time it's very likely there
will be different levels of support for the same "service" (e.g. process
purchase order)
(as in the EDI case described above) across a trading community.
It appears to me that mustUnderstand is the only way, given the current
design, to "ensure"
that two parties are in "sync". If XMLP allows the receiver of a response
message to
ignore mustUnderstand then there is no way for the responder to know for
sure that
the response message was actually understood.

Regards,

Dick Brooks
http://www.8760.com/

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Noah_Mendelsohn@lotus.com
Sent: Monday, April 30, 2001 7:16 PM
To: xml-dist-app@w3.org
Subject: Re: mustUnderstand on client side



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 Tuesday, 1 May 2001 09:33:15 UTC