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

Jacek,

I am not aware of us ever having said anything about whether there is
one or many nodes that may act in a single role. Unless we are
introducing such semantics for roles in general (which I would not be
happy about) then I don't understand why you separate the scenarios of
the node acting in a role being special from the ones where any
subsequent nodes acting in that role.

If this is true then and I apply this to your scenarios, then I pretty
much up end with the table that Gudge sent out. That is, it really does
boil down to the case of what a relay is to do with an optional header
block targeted at it but which it doesn't understand: should it drop or
forward?

Settling on a default for what to do will make the other case harder.
Leaving out the possibility of adding an attribute, the point of my
scenario was that the relay role AND the current default would allow
both cases while maintaining the optionality. However, I can't see this
being the case if the default was turned the other way.

Am I missing something?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>it all boils down to the relative weights of supporting the 
>following scenarios of targeting (other scenarios are IMHO not 
>affected):
>
>1) targeting the first node playing a given custom role
>2) targeting the first understanding node playing a given custom role
>3) targeting the first understanding node
>4) targeting all the nodes playing a given custom role
>5) targeting all the understanding nodes playing a given custom role
>6) targeting all the understanding nodes

Received on Wednesday, 16 October 2002 17:45:00 UTC