RE: Question on section 2.7.1, Part 1

I agree with 1) but not with 2) because I think it only reflects part of
the story.

First, I think we agree that roles do have semantics and function in
some capacity. This is the case for both the roles that we define and
also implied in the processing model.

Second, I don't think the notion of removing unprocessed header blocks
is independent of role. It only applies to SOAP nodes that in some
capacity is an intermediary. For example, it doesn't apply to the
ultimate receiver as we explicitly say that at the time a messages
reaches the ultimate receiver then we are done. It also doesn't apply to
the initial sender as this implies generating a message and not
processing a message.

What we haven't done a good job at is explaining that the whole notion
of roles *is* about distributed processing based on a concept of a
message path. I think it would be good to clarify this but it is not a
stretch from what we have now although I do agree that it is not as
clear as it could be.

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>-----Original Message-----
>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Tuesday, October 08, 2002 10:52
>To: Henrik Frystyk Nielsen
>Cc: marc.hadley@sun.com; Martin Gudgin; moreau@crf.canon.fr; 
>Nilo.Mitra@am1.ericsson.se; www-archive@w3.org
>Subject: 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 17:49:01 UTC