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: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Wed, 16 Oct 2002 17:56:15 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D093740FB@red-msg-07.redmond.corp.microsoft.com>
To: <noah_mendelsohn@us.ibm.com>, "Martin Gudgin" <mgudgin@microsoft.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>, "XMLP Dist App" <xml-dist-app@w3.org>

I'm glad we agree on the spirit of the table! The main purpose of
generating it was to ensure that we did cover a useful set of cases. I
also agree that it does not address the issue of whether flipping the
default provides added benefits or not. I think that can be considered

If my analysis in [1] is correct then I think the "which default"
question boils down to the issue of whether we want to enable optional
header blocks to be deployed in a hop-by-hop manner. My preference is
that we do, both because it seems like a useful thing and because it
seems to introduce less changes to the spec.

>I still am unconvinced by Henrik's use case for putting in a 
>header that 
>must be dropped by the next node (or next node with the chosen 
>role) if 
>not processed.  Furthermore, I believe that if necessary that could be 
>implemented by an mU header addressed to the same role that 
>means "you may 
>not have to understand the other headers addressed to this 
>role, but you 
>do have to understand this one:  it tells you to drop the 
>other headers if 
>you don't process."
>So, I still have some inclination to support those who would like to 
>change the default.  It's always seemed too tricky to me to 
>have to rely 
>on dropping then reinserting in the case that you do process.  In any 
>case, I think the spirit of the table below is correct:  it 
>just doesn't 
>convince me that changing the default is a mistake.


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0067.html
Received on Wednesday, 16 October 2002 20:56:46 UTC

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