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

Re: Proposal: Module for checking mustUnderstand headers have been processed

From: Doug Davis <dug@us.ibm.com>
Date: Fri, 11 May 2001 08:26:23 -0700
To: Noah_Mendelsohn@lotus.com
Cc: "Martin Gudgin" <marting@develop.com>, "XML Protocol Comments" <xml-dist-app@w3.org>
Message-ID: <OF65AFAFED.B3C08F44-ON88256A49.0053A788@raleigh.ibm.com >
In your consideration of the issues please consider the
impact this change would have on the "simple" part of
SOAP (and our goal of keeping it simple).  If we do not
change the spec and the general consensus is that
targeted MU's should be ignored by the ultimate destination
then Martin's suggestion is the way to go (once we work
out the issues your analyzing).  However, as he already
pointed out this new header will make something that is
syntactically correct (targeting this new header) and make
it semantically incorrect (ie. the actor should ignore it
or fault on it).  I'm concerned that this reduces the
simplicity factor by introducing special rules.

I would much rather take a different approach - and change
the spec.  If we leave the spec as is, and consensus says
that targeted MU's should be ignored by the ultimate
destination, then I would claim that it becomes a useless
feature of SOAP.  A client who's business relies on
a targeted header being understood (and therefore sets the MU
flag to 1) will never be told that it was ignored (which
btw the spec does agree that silently ignoring MU's is
a bad thing).  So, if a client can not reliably count on
being told if this header was ignored I would claim that
no one will(or should) use it - so why not simply change
the spec to take a useless feature and make it meaningful
by requiring the ultimate destination to check for targeted
MU headers?


Noah_Mendelsohn@lotus.com on 05/11/2001 05:51:25 AM

To:   "Martin Gudgin" <marting@develop.com>
cc:   Doug Davis/Raleigh/IBM@IBMUS, "XML Protocol Comments"
Subject:  Re: Proposal: Module for checking mustUnderstand headers have
      been processed

>> I was only dealing with the ultimate destination case but
>> thinking about it if all actors dealt with it the same way it
>> would give us the ability to have this thing checked at any point
>> in the chain.
>> The problem is though that without any notion of path it's only
>> the ultimate destination that knows all other actors should have
>> done their stuff. Any actor in the chain would not know if a
>> targetted mustunderstand='1' block had been missed or had not yet
>> reached the intermediary it was targetted at :-(
>> So, it depends on what we want to do. I would say that for now,
>> actor is not allowed on this header. If we later get some notion
>> of path/ordering maybe we could allow it at that point.
>> Gudge

Right, exactly.  I believe it is just this combination of issues for which
the group gave me a "to do" to hatch at least a partial analysis by end of
day today.  I'm scrambling and will try to get something together.

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

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