W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: IRIs, IDNAbis, and HTTP [i74]

From: Brian Smith <brian@briansmith.org>
Date: Fri, 14 Mar 2008 09:29:20 -0700
To: <ietf-http-wg@w3.org>
Message-ID: <008201c885f0$8fbbbd70$4001a8c0@T60>

Frank Ellermann wrote:
> Brian Smith wrote:
> As explained you don't need a <quoted-string> as soon as you 
> have RFC 2047 encoded words.  Just remove the quotes and 
> 2047-encode what was within to get an "ordinary" unquoted 
> word =?...?.?...?=
> Your premise is apparently wrong.   Looking in RFC 2068
> I find:
> | link-extension = token [ "=" ( token | quoted-string ) ]
> Four cases for the right hand side (value):  A simple 
> <token>, or a (Latin-1) <quoted-string>, or a 2047 encoded 
> word in any charset, or for longer strings the magic 
> specified in RFC 2231.

You cannot derive "token | quoted-string | encoded-word" from "token |
quoted-string". RFC 2616 doesn't say that encoded-word may be
substituted for token or quoted-string; it only says encoded-word may be
substituted for *TEXT. RFC 2047 only talks about how to use
encoded-string in RFC 2045 messages with RFC 822 headers, not RFC 2616
messages or RFC 2616 headers. Finally, none of them reference RFC 2231,
and neither does Mark's newest Link header draft, so RFC 2231 is

> > Atom and HTML 5 (will) allow internationalized link relation names, 
> > and IRIs as link relation names.
> RFC 2068 clearly says URI, and all IRIs have equivalent URIs.
> If that is not good enough for Atom, then Atom is in need of 
> a new protocol to transport it, that is not the fault of HTTP.

RFC 2068 uses sgml-name, not URI. Mark added new functionality to
support URI references in his new draft. Atom allows IRIs or IRI
segments, HTML allows anything that doesn't embed spaces. 

- Brian
Received on Friday, 14 March 2008 16:29:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC