Re: IDNA, IRI, HTML5 coordination

>> While having documents in conflict with widely
>> deployed implementations is a general pain
>> which we should work to correct,
>
> Yes, trying to bring things together so that people don't have to check a
> lot of different specs, trying to document existing widely-deployed
> implementations, and making sure the quirks of these implementations are not
> seen as creating a whole class of new identifiers, but only as "accepting
> slightly more than necessary" are in my view the main goals.

We must document not only what the consumers accept, but also what
they do with that input, i.e. how the input is transformed into the
output, and whether the output is normal or an error. It is important
to document the current behavior of the implementations and to
highlight the differences. Hopefully, some implementers will align
their implementations with others. Where the implementations don't
align, the documented differences serve as warnings to producers.
(E.g. escaped UTF-8 host names are treated so differently by the
browsers that producers would be wise to avoid them for now.)

Of course, there are chicken and egg problems here. MSIE will display
IDNs under .com in their Unicode form, but Firefox refuses to do so.
As long as this major difference persists, registrants will probably
refrain from registering and using IDNs under .com. If the registrants
would use them more, MSIE, Firefox and Verisign might try to work
towards a resolution. But registrants may not want to use IDNs under
.com until MSIE, Firefox and Verisign have ironed out their
differences.

To put it differently, one of the goals is human-to-human
communication, not mere machine-to-machine communication. If an IDN is
not displayed legibly, we have not met that goal. If the IETF does not
want to deal with UI, humans, display, etc, we must address this
elsewhere, e.g. W3C.

Erik

Received on Friday, 18 September 2009 15:44:02 UTC