RE: Proposal for new last call issue: Some unprocessed headers should stay

Henrik, 

I think we're now getting to something real. Please see inside.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Wed, 16 Oct 2002, Henrik Frystyk Nielsen wrote:

 > I am sorry if I was not clear in my response. While I am not arguing
 > that an attribute could be made to work because I know that it can, I am
 > arguing that this is overkill for solving the problem of how to allow a
 > header block to be forwarded even though it is ignored. Yes, it is a
 > limitation that "relay" is a specialized role, but I think it is a
 > reasonable limitation given the semantics we are after.

Below I'll try to show why I don't think the special "relay" role 
works in many of the scenarios and why you wouldn't want to use 
"next" to implement a non-mU hop-by-hop mechanism.

 > We could have written the SOAP spec in such a way that each role would
 > define its own semantics which would mean that we didn't have to define
 > any in the base spec. However, for better or for worse, we did define
 > actual roles in the spec and I think "relay" is just another one. One of
 > the reasons for doing this is that we are trying to avoid N number of
 > ways for specifying "next", "none", and now "relay". 

The roles so far (next, none, ultimateReceiver) are all really 
targeting. "relay" adds further semantics to that. That's 
introducing an overload on the function of a role.

 > >1) targeting the first node playing a given custom role
 > 	Role="custom"
 > 	Header block does not define relaying of that block

yes

 > >2) targeting the first understanding node playing a given custom role
 > 	Role="relay"
 > 	Header block does not define relaying of that block

I disagree here because the scenario wants the first "cache manager",
not the first "node willing to relay unprocessed headers" which is what
the role "relay" is. So you can't target the first understanding "cache
manager".

 > >3) targeting the first understanding node
 > 	Role="relay"
 > 	Header block does not define relaying of that block

It is necessary that the understanding node plays the special role, and
as I believe this would either lead to virtually all nodes in any system
playing this role or to possible conflicts if two different headers
wanted to use the relaying semantics on two different sets of nodes
along the message path.

 > >4) targeting all the nodes playing a given custom role
 > 	Role="relay"
 > 	Header block defines relaying of that block

Again, the custom role was like in scenario 2, therefore the new role
doesn't satisfy this scenario.

 > >5) targeting all the understanding nodes playing a given custom role
 > 	Role="relay"
 > 	Header block defines relaying of that block

Same as above.

 > >6) targeting all the understanding nodes
 > 	Role="relay"
 > 	Header block defines relaying of that block

Same problems as with scenario 3.

 > In effect, the only bit of information used is whether an ignored header
 > block should be forwarded or not. Even with a "relay" role, the reason
 > why I am against flipping the default is that it makes it impossible to
 > deploy hop-by-hop scoped features without using mU=true.

If by hop-by-hop you mean for example (de)compression on a slow link,
you have two roles already: "nodeBeforeSlowLink" that does the
compression and adds a decompression header targeted at the second role,
"nodeAfterSlowLink"; in this design the header would probably be mU
because we can assume nodel later need the data in an uncompressed form.

So again, can you sketch in more detail what you want to do and why the
flipped default would prevent you from doing it? I'm afraid I don't know
enough about your hop-by-hop usecases to see that the flipped default
makes them impossible.

Kind regards,

Jacek

Received on Thursday, 17 October 2002 07:57:29 UTC