- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 14 Mar 2008 21:46:52 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Martin Duerst <duerst@it.aoyama.ac.jp>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
On 14/03/2008, at 9:26 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> Personally, I am *very* -1 on doing this. >> Changing the allowable characters in a protocol element is a *big* >> change, and there is not an interoperability gain to doing so. >> There is also not a functionality gain; it is possible (if not >> pretty) to serialise other characters into HTTP headers. > > I think the key question here: is that implemented in practice? (In > particular, which encoding?) If yes, fine (and maybe let's document > what works). But if not...? > >> Furthermore, HTTP headers for the most part don't carry user- >> visible data, and when they do, it's often an IRI, for which there >> is a well-understood serialisation into header-safe characters. > > None of the usages in RFC2616 is a IRI (by definition :-). > > And, as Brian observed, IRI->URI mapping is not sufficient if you > need to *exactly* reconstruct the original IRI (such as when the IRI > is used as a name, e.g. an Atom link relation). I think Larry was making much the same point at the app area arch ws, IIRC. My gut feeling on issue 74 is that if any encoding (e.g., IRI->URI, RFC2047) is usable in a header, it should be specified on a header-by- header basis explicitly, not inherited as a general rule like this. That allows the flexibility to use the right mechanism for the job, and keeps the overhead low. Are there any other headers (besides URI-based headers) that we need to consider, beyond these? * WWW-Authenticate, Proxy-Authenticate, Authorization, Proxy- Authorization * Content-Disposition * From * Warning * PICS-Label -- Mark Nottingham http://www.mnot.net/
Received on Friday, 14 March 2008 10:47:35 UTC