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

>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 13:54:51 UTC