Re: IRIs, IDNAbis, and HTTP

Brian Smith wrote:
>> 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.
> 
> Right, but I understand it to mean that a new protocol that supports
> URIs must support UTF-8 in URIs, and the only (proposed) standard for
> UTF-8 in URIs is RFC 3987.

Well, no. URIs are all ASCII. There's is no such thing as "Unicode 
support in URIs". These are called "IRIs".

> Also, instead of paraphrasing 2277, let's just directly quote the parts
> that apply to HTTPbis:
> 
> "Lack of an ability to use UTF-8 is a violation of this policy; such a
> violation would need a variance procedure ([BCP9] section 9) with clear
> and solid justification in the protocol specification document before
> being entered into or advanced upon the standards track."
> 
> "For existing protocols or protocols that move data from existing
> datastores, support of other charsets, or even using a default other
> than UTF-8, may be a requirement. This is acceptable, but UTF-8 support
> MUST be possible."
> 
> "In documents that deal with internationalization issues at all, a
> synopsis of the approaches chosen for internationalization SHOULD be
> collected into a section called 'Internationalization considerations',
> and placed next to the Security Considerations section."

All nice in theory, but it hasn't been done in RFC2616.

>> 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.
> 
> RFC 2277 applies to any updates to an existing protocol, as far as I can
> tell.

I don't see how it could apply to that.

> ...
>> 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 ?  
> 
>> 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 am not suggesting that HTTP 1.1 should switch from Latin-1 to UTF-8.
> But, I do think that HTTPbis should explain how IRIs are to be used
> correctly in HTTP (via URI-IRI conversion, IDNA, etc.). And, I think

HTTP uses URIs, not IRIs.

That being said, it may be necessary to state a few things about HTTP 
IRIs, but that would be in a separate document. Remember our charter?

> that HTTPbis should explain how to encode UTF-8 text in newly registered
> header fields. The de-facto mechanism for this, used by Atom and WebDAV,
> is percent-encoded UTF-8.

Note: one instance in WebDAV Delta-V, one in AtomPub.

Are you saying httpbis should recommend that for new headers? I'm not 
against it, but it sounds like something for an update to the HTTP 
header registry.

>>> 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.
> 
> You seem to know a lot more about IETF policy than me, but I don't see
> how it is possible to defer the internationalization considerations of
> HTTP any further, while keeping HTTP on the standards track.

I fear it's the other way around. If we want to keep it on the standards 
track, we can't make any incompatible changes.

BR, Julian

Received on Thursday, 13 March 2008 14:15:29 UTC