- From: Marc Hadley <marc.hadley@sun.com>
- Date: Tue, 8 Oct 2002 14:17:07 -0400
- To: noah_mendelsohn@us.ibm.com
- 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
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. Regards, Marc. -- Marc Hadley <marc.hadley@sun.com> XML Technology Center, Sun Microsystems.
Received on Tuesday, 8 October 2002 14:17:03 UTC