RE: IRIs, IDNAbis, and HTTP [i74]

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 19.6.2.4
> 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
irrelevant.

> > 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