Re: [ietf-provreg] Re: EPP Extensions for IDN

[Andrew Sullivan <andrew@ca.afilias.info>]

On Sat, Apr 07, 2007 at 10:18:16PM +0200, Stephane Bortzmeyer wrote:

> IDN deals with scripts, not with languages. 

My reading of the RFCs is that IDNA specifically deals with neither.
It rather deals with Unicode code points, and how they can be encoded
in ASCII.  The problem all arises above the level of IDNA (and support
for IDNA-as-implemented-by-registries is the EPP extension we're
designing, I think).

One might argue that general IDN considerations need to be taken into
account because those working on IDNA 200x and such like are worried
about _localization_ and not about _internationalization_ (or at
least, think that an emphasis on localization is needed).

That said, the policy from ICANN is ambiguous with respect to whether
the issue is "script" or "language".  (I appreciate that it is not the
policy under which everyone labours -- but given that some of us do,
any extension that is to be usable will need to accommodate the
possibility that language is the relevant category.) 

In any case,

> Asking what is the
> language of an IDN domain name is often irrelevant and sometimes
> meaningless (many corporate trademarks are not words in any human
> language, for instance).

is an oversimplification, because it's also true that asking what
script a label is in might be meaningless, for similar reasons.  I can
imagine that "αthenstravel" (in case that doesn't come through,
that's "[GREEK SMALL LETTER ALPHA]thens") could be a cool name for a
travel agency, for instance.  So, which script is
"αthenstravel.example" in?  The answer for this might turn out to be
dependent on some registry policy involving a table of allowable code
points.  (As far as I know, no registry running current Afilias code
would allow the example.)  Alas, just because we've decided to sweep
all the problems under the rug by saying "table of allowable
code-points in this script defined by the convention name
'Greek/Greece'" instead of "which language is this" doesn't mean that
we've actually solved the problem[1].

So at the very least, any extension is going to need support for both
"languages" and "scripts".  Besides, there are languages that can be
expressed in more than one script, and in those cases, you probably
need both pieces of meta-data to decide whether the desired label
meets the policy rules that are to be applied.  My guess is that there
is going to need to be some sort of indication about variants desired
or actually registered or something, as well.

A

[1] And I'm just ignoring the fact that we have apparently given up on
the idea that domain name labels are not words, and shouldn't be
understood to be words.  I reluctantly concluded some time ago that
the horse was out of the barn.

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
jabber: ajsaf@jabber.org                 +1 416 646 3304 x4110