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

RE: IRIs, IDNAbis, and HTTP

From: Brian Smith <brian@briansmith.org>
Date: Fri, 14 Mar 2008 07:22:39 -0700
To: "'Frank Ellermann'" <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, <ietf-http-wg@w3.org>
Message-ID: <006601c885de$dca76150$4001a8c0@T60>

Frank Ellermann wrote:
> Brian Smith wrote:
> > RFC 2047 is basically unimplementable.
> It is a draft standard, there must be at least two 
> interoperable implementations.  Come on, it is no rocket 
> science, the Internet uses MIME for ages, RFC 1341 was 
> published in 1992.

I followed that with "At least, you cannot be sure that any two
implementations are implementing it the same way because there are
ambiguities." Look at the various interpretations of where it is allowed
or should be allowed in this discussion alone. Mail/News applications
might have figured it out, but HTTP applications haven't. 

The only reason we are discussing RFC 2047 right now is because of the
Link header, which uses quoted-string to contain language-sensitive
text. If RFC 2047 cannot be used in quoted-string, then there is no way
to internationalize the Link header as it is defined in RFC 2068 or in
the latest draft that Mark just linked to. A new mechanism would need to
be created to allow internationalization of the Link header. If a new
mechanism is necessary, we might as well standardize it so that it can
be used in other (new) headers with similar requirements.

Also, Atom and HTML 5 (will) allow internationalized link relation
names, and IRIs as link relation names. If HTTP Link relations names
cannot be internationalized, then HTTP Links will only be useable for a
subset of the relations usable in HTML and Atom. That restriction is

> > RFC 2047 is so terrible that nobody wants to use it anyway
> Parts of RFC 2231 are seriously odd, but "nobody wants it" 
> does not cut it if the alternatives are HTTP/1.2 UTF-8 or a 
> HTTP/1.1 limited to Latin-1.  
> If you are sure that 2047 is either unsupported or doesn't 
> work as specified it could justify to pull it, but then 
> nobody will forget what you said RFC 2277, and we can save 
> steps by saying that HTTP/1.1 is hopleless.

That is why I suggested that a new mechanism for encoding Unicode text
in header subfields should be created, and that the Link header should
use the new mechanism. Or, put another way, whatever mechanism is used
to make the Link header RFC 2277 compliant should be standardized so
that it can be used by other (new) headers.

The easiest way to internationalize the Link header is to drop the title
subfield completely, and specify that link relations are to be compared
to each other in their IRI (segment) form.

- Brian
Received on Friday, 14 March 2008 14:23:11 UTC

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