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

Jacek,

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.

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

If you buy this assumption, then I think the relay role can support all
scenarios as follows:

>1) targeting the first node playing a given custom role

	Role="custom"
	Header block does not define relaying of that block

>2) targeting the first understanding node playing a given custom role

	Role="relay"
	Header block does not define relaying of that block

>3) targeting the first understanding node

	Role="relay"
	Header block does not define relaying of that block

>4) targeting all the nodes playing a given custom role

	Role="relay"
	Header block defines relaying of that block

>5) targeting all the understanding nodes playing a given custom role

	Role="relay"
	Header block defines relaying of that block

>6) targeting all the understanding nodes

	Role="relay"
	Header block defines relaying of that block

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.

>Btw, why are you leaving out the possibility of adding an 
>attribute? I haven't noticed a message where you'd say you 
>can't live with this solution (but then I haven't been 
>following the thread in its completeness).

I merely left it out of the paragraph as I tried to address the issue of
default behavior which I think is somewhat orthogonal. That I don't like
the attribute for the reasons above is of course a related matter ;)

>If anything in my message is wrong (missing scenarios, wrong 
>values in the table or the intended semantics of a role name), 
>please say so explicitly because otherwise I might not catch it.

Hope this makes sense,

Henrik

Received on Wednesday, 16 October 2002 19:31:38 UTC