RE: Question on section 2.7.1, Part 1

Henrik Frystyk Nielsen writes:

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

* 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 understand that neither of these two bullets is 100% clear cut, which is 
why I am asking the opinions of others getting this email in trying to 
decide whether it really is broken enough to raise this late in the game. 
If this analysis is true, it cannot be fixed by use of features and 
headers;  a new SOAP 1.3 or some such would be needed.  So, if that's 
true, we should either fix it now or not expect the function for a long 
time.  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 8 October 2002 13:54:49 UTC