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 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 July 2008 08:08:45 GMT