- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 14 Mar 2008 11:26:59 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: Martin Duerst <duerst@it.aoyama.ac.jp>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
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). > ... BR, Julian
Received on Friday, 14 March 2008 10:27:57 UTC