IRIs, IDNAbis, and HTTP (was: Reviving HTTP Header Linking: Some code and use-cases)

Brian Smith wrote:
 
>> Sounds like a good reason for not allowing link relations 
>> that aren't URIs (or URI references).
 
> That is against IETF policy. New standards have to allow
> the use of IRIs wherever URIs are allowed. At least, that
> is what I was told on the Atom mailing list.

Then this was IMO more than one error in a simple statement.  

New protocols are supposed to support minimally UTF-8 as per
RFC 2277.  That is not the same as "support IRIs", IRIs can
be in any charset, not only UTF-8.  You'd need to transform
IRIs to UTF-8 first if you want to figure out an equivalent
URI, and you'd need to transform an IDN <ihost> in an IRI
to an ordinary STD 66 <host> with A-labels in the URI, but
that is no "IETF policy", it is simply what RFC 3987 says.

HTTP is no "new" protocol, like mail or news:  2821bis and
2822upd and FWIW RFC.usefor-usefor don't "violate" any IETF
policy.  But atom and xmpp were new, a different situation.

HTTP at the moment allows Latin-1, do you really want to
support the proper subset of all IRIs limited to Latin-1,
for the purpose of HTTP Link: header fields ?  

Please note that RFC 3987 is a proposed standard, HTTP is a
draft standard.  You'd get a downref, and forcing servers
and clients worldwide to do the Unicode 3.2 punycode stunt
(until IDNAbis fixes it) is an interoperability nightmare.

When "keeping Latin-1" is a showstopper, then introducing
IRIs in 2616bis would be a clear "1F" scenario.  You need
a new HTTP version number for this, a restart at PS, and a
new WG Charter.

> I personally believe it is wrong to create new standards
> where things may be named in European languages but not
> in non-European languages.

Strong ACK, let's drop the Latin-1 cruft, and limit 2616bis
to US-ASCII and URIs for now.  HTTP/1.2 is free to tackle
UTF-8, and RFC 3987 offers a strict STD 66 URI for any IRI.

 Frank

Received on Thursday, 13 March 2008 08:51:37 UTC