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

Henrik,

I don't (yet?) see how changing the default is going to affect
negatively any application (a few role name redesigns may be necessary,
but I believe that's not many).

With the changed default, if a module doesn't specify anything about
relaying, none is done on processed headers, unprocessed headers would
be passed along believing that other node acting the same role would do
better.

On the other hand a module can include relaying in its specification and
it would work. My preference to push the relaying specification into
modules is based on my opinion that relaying is tied to a header's
semantics and therefore it is not an undue burden on the module's
designer.

Best regards,

                   Jacek Kopecky

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




On Wed, 2002-10-16 at 19:54, Henrik Frystyk Nielsen wrote:
> 
> >In this situation, I would prefer changing the default to keep 
> >unprocessed header entries, and deferring the relaying into 
> >modules where I think it really belongs; but I see how this 
> >might be perceived as a big change.
> 
> I think there are scenarios that call for both ignored header blocks to
> be removed and for them to be forwarded. An example of the former is
> some hop-by-hop oriented feature, and an example of the latter is some
> feature that isn't hop-by-hop specific.
> 
> IMO, it is not really a question of whether changing the default is a
> big change or not but rather that it doesn't address both cases. For
> example, having ignored header blocks be preserved would not allow me to
> deploy an optional hop-by-hop compression algorithm.
> 
> A nice thing about the "relay" role proposal is that I get both
> capabilities. This means that I can deploy an optional hop-by-hop
> "compression" header block which is removed if ignored AND a "trace"
> header block which is not removed if ignored.
> 
> Henrik

Received on Wednesday, 16 October 2002 14:31:36 UTC