Browser IDN display policy: opinions sought

[J-F C. Morfin]

At 11:42 19/12/2011, Gervase Markham wrote:
>Hi Raed,
>Thank you for your input.
>
>I would say that the vendor you quote is using sloppy language and it's
>not actually about 'prioritizing English', but your point about
>first-class citizenship is a good one.

No one is prioritizing English. English IS, by mutual convenience, 
the Internet language (cf. RFC 3935).

This is why the IETF solution is "internationalization" and not 
"multilingualization". Internationalization is a component of 
"globalization" together with "localization" and "langtags" and is 
embodied in CLDR tools. Internationlization is to make the medium 
(here the Internet) language neutral. For that it uses an 
International English and ASCII programming to quote Unicoded strings 
independently from the actual language these strings correspond to 
(identfied by the langtag), including English. These quotes are of 
two forms: the real text, i.e. a batch of code points, or an URL that 
permit an option indirect access. For good consustency (RFC 1958) the 
quotes should use the same script displaying context (UTF-8).

IDNA2008 has organized this to properly work through:

- an Internet technology core,
- and a subsidiary support of languages at the periphery.

In this architecture it happens that the Internet architectural core 
happens to currently work in ASCII, but it could work the same in any 
other charset, including binary.(what may be the evolution of the 
Internet 2.0 architecture).

IDNA2008 however has left two unaddressed issues.

1. to be broadly explained as being an example of the way the end to 
end Internet architecture actually (RFC 1958) supports diversity, any 
diversity. This support is at the intelligent fringe to fringe layer 
set which includes the presentation layer.

The difficulty is that OSI was wrong: the OSI model in uncomplete and 
the layer pile must dissociate Network and Subsidiary Network Use 
layers. I appealed against the lack of a IAB/IESG disclaimer which 
would have prevented the current debate. The response I obtained 
clearly indicated that this issue did not belong to the IETF scope, 
but that IETF wanted to detail its own needs in this area. This is 
why I delayed as much as I could the description of the fringe to 
fringe IUI framework. However, the technically illegitimate ICANN 
opening to gTLD registration calls for it to be published before January 10.

2. fringe to fringe calls for metadata exchanges: IDNA2008 has not 
considered the need to support orthotypography (i.e. script use 
variations depending on the meaning). Basically what you say about 
second-zone languages also applies to real life English which 
actually needs more than the ASCII charset, and obviously to French 
as I reported it to the IESG. The management of the fringe to fringe 
metadata intercommunications is more complex than the data 
intercommunications. It calls for a dedicated channel that has to be 
transparent to the existing core technology and common usage. What 
Gervase asks for is to be told how this is to work.

>If all registries were are responsible as yours, there would hardly be a
>need for browser restrictions on IDN display at all (perhaps just a
>blacklist of homographs for "." and "/", and that should have been
>achieved by IDNA2008 anyway).

This "registries being responsible" is an wrong interference where we 
technicians are judging use, instead of supporting it properly.  The 
principle of the Internet is that technology is to best support the 
user needs and the IETF is to influence those who design, use and 
manage the Internet for it to work better. The problem are (1) that 
no one ever explained what working "better" means and (2) that some 
of us want to unilaterally constrain uses along with their own 
understanding of that "better" means, moreover in areas where things 
have not been fully defined.

> > IDNs should not be treated as second-class citizens on the Internet.
>
>I entirely agree. This is why we went for option B - once a registry has
>a responsible policy, their IDNs are treated as first-class citizens
>everywhere (at least, in Firefox). No additional configuration required.

This means that you decide who is a second-zone Registry and treat 
their registrants as third-zone netizens. Then the question 
unfortunately comes: "Who made you king to decide this?"

>Unfortunately, IDNs are still not treated as first-class citizens. So
>the question is: how do we get from where we are now to a situation
>where they are treated that way?

This is easy as far as you are concerned.

- you treat them as your user application layer is to treat them: as 
unique-class Internet Domain Name citizens.
- you demand those who are to take care of the difficulties you 
identify to address them properly. They are the IAB and the emerging 
IUTF (on the iucg at ietf.org) where this mailing thread belongs since 
the WG/IDNAbis is closed, its RFC set is published, and the remaining 
points are on the IDNA2008 use side.

Cheers.

jfc