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: Nilo Mitra (EUS) <Nilo.Mitra@am1.ericsson.se>
Date: Wed, 16 Oct 2002 12:02:55 -0500
Message-ID: <C358DED30DFED41192E100508BB3922704102D35@eamrcnt716.exu.ericsson.se>
To: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>
Cc: xml-dist-app@w3.org, noah_mendelsohn@us.ibm.com
Thanks for your explanation. Why do we want 2) below? One of my original questions was: what *was* the rationale for removing unprocessed (ignored) header blocks (particularly those addressed to "next") in a forwarded message? Thanks
Nilo

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: Wednesday, October 16, 2002 12:53 PM
> To: Nilo Mitra (EUS); noah_mendelsohn@us.ibm.com
> Cc: xml-dist-app@w3.org
> Subject: RE: Proposal for new last call issue: Some 
> unprocessed headers
> should stay
> 
> 
> 
> 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 13:02:59 GMT

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