W3C home > Mailing lists > Public > www-archive@w3.org > October 2002

Re: Question on section 2.7.1, Part 1

From: Marc Hadley <marc.hadley@sun.com>
Date: Tue, 8 Oct 2002 14:17:07 -0400
Cc: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>, "Martin Gudgin" <mgudgin@microsoft.com>, moreau@crf.canon.fr, Nilo.Mitra@am1.ericsson.se, www-archive@w3.org
To: noah_mendelsohn@us.ibm.com
Message-Id: <275C5060-DAEA-11D6-A80C-0003937568DC@sun.com>

On Tuesday, Oct 8, 2002, at 13:52 US/Eastern, 
noah_mendelsohn@us.ibm.com wrote:
>>> As for the meta concern, my feeling is that we
>>> should focus on last call issues unless we
>>> really think something is fundamentally broken.
> ...and I'm about 80% convinced that something is broken, or better 
> stated,
> I think we may be lacking a capability that users will find very
> important, and that cannot easily be added in a future release.  The 
> line
> of reasoning is:
> * It's important to be able to have a non-mU header that will be 
> addressed
> to each intermediary, and that will stay in the message if not 
> processed
> (all are in agreement, I think, that if you process it the processing 
> can
> determine whether it stays.)
Why is it important that the header *not* be "mustUnderstand='1'" ? 
Isn't the whole purpose of mustUnderstand to make sure that the 
sematics conveyed by the header (e.g. reinsert me) are followed and if 
not that a specified failure mode is followed ?

> * I don't see the current processing rules as allowing a role to be
> created that could be used as an alternative to "next", but with the
> necessary semantic.  That's because I think the need to remove 
> unprocessed
> messages is stated independent of the role in our normative spec.  If 
> two
> such headers arrive addressed to this role, and I process one of the
> headers, then it's observable that I have assumed the role (or else I
> couldn't have processed any of them.)  If I don't understand and/or 
> don't
> process header 2, I believe our normative text says I must remove it.
I agree that role shouldn't be overloaded in this manner.


Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.
Received on Tuesday, 8 October 2002 14:17:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:54 UTC