W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2002

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

From: Jacek Kopecky <jacek@systinet.com>
Date: 16 Oct 2002 20:31:34 +0200
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Cc: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, XMLP Dist App <xml-dist-app@w3.org>
Message-Id: <1034793094.3074.65.camel@krava>


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

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

Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:21 UTC