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 09:52:34 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D093740CA@red-msg-07.redmond.corp.microsoft.com>
To: "Nilo Mitra (EUS)" <Nilo.Mitra@am1.ericsson.se>, <noah_mendelsohn@us.ibm.com>
Cc: <xml-dist-app@w3.org>


Nilo,

The reason is that we have two cases to cover:

1) Preserve unprocessed (ignored) header blocks in a forwarded message

2) Remove unprocessed (ignored) header block in a forwarded message

The proposal on the table is that we want to cover both. Flipping the
default would merely tip the scale in the other direction but not
address both cases.

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

-----Original Message-----
From: Nilo Mitra (EUS) [mailto:Nilo.Mitra@am1.ericsson.se] 
Sent: Wednesday, October 16, 2002 08:55
To: 'noah_mendelsohn@us.ibm.com'
Cc: xml-dist-app@w3.org
Subject: RE: Proposal for new last call issue: Some unprocessed headers
should stay


Noah et al: 
In a part of your proposal, you wrote: 
<snip> 
> Another possibility that has been raised would be to change the 
> default behavior to be: "leave in place any header entries that are 
> not processed".  
I wonder what the opposition is to this solution. It seems to be the
simplest. 
Could you, or someone else, provide some rationale on why this might not
fit the bill? 
> Optionally, we could additionally define a 
> relayIfProcessed override if the group felt it to be worth the 
> trouble.  My impression is that some who have considered changing the 
> default rules like the idea, but some feel that it doesn't meet a need

> to have headers that do indeed disappear when unprocessed. 
What was the rationale for unprocessed headers (targeted at "next") to
disappear? 
  
> For the 
> record, I quite like the idea, but (a) am not ready to take 
> the lead in 
> pushing it in the face of any significant opposition and (b) would not

> want to go back to last call if this were deemed a serious change-- 
> I'm not sure it is. 
Is there indeed significant opposition to it? 
I can't see how changing the default handling for non-MU headers
targeted 
at next can be seen as a go-back-to-last-call issue. 
Thanks 
Nilo 




> 
> Noah Mendelsohn                              Voice: 1-617-693-4036 
> IBM Corporation                                Fax: 1-617-693-8676 
> One Rogers Street 
> Cambridge, MA 02142 
> ------------------------------------------------------------------ 
> 
Received on Wednesday, 16 October 2002 12:53:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT