Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-00.txt

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Jan 2012 15:10:38 -0500

Hi all,

Doing some catch-up.  Sorry for coming in late.

On Wed, Dec 21, 2011 at 10:10:52PM -0800, Francisco Obispo wrote:

> Looking at the IDN implementation guidelines, item #5 states:
> 
> 5.All code points in a single label will be taken from the same
>   script as determined by the Unicode Standard Annex #24: Script
>   Names <http://www.unicode.org/reports/tr24>. Exceptions to this
>   guideline are permissible for languages with established 
>   orthographies and conventions that require the commingled use of
>   multiple scripts.

i.e. "every language in the world".  It turns out that there is a
major problem with this guideline in general use, even if it turns out
to work for some languages for TLDs: most languages need some things
from Common or Inherited.  That is true even of LDH labels. 

You might get around this by hand-waving Common and Inherited, but
then you have a different problem.  For instance, suppose you wanted
to permit the traditional digits 0-9; they're Common.  But if you said
that Latin implicitly included everything in Common, you'd implicitly
include 0660..0669, which are ARABIC-INDIC DIGIT ZERO..ARABIC-INDIC
DIGIT NINE.  Which is presumably not what you wanted.

Worse,

> So it would not be possible to have multiple languages associated to a label.

you're conflating "language" and "script" here, since the restriction
above is about scripts and not languages.  

> XML Schema "language" type[1]:
> 
> [Definition:]   language represents natural language identifiers as defined by by [RFC 3066][2] . The ·value space· of language is the set of all strings that

I guess this reference ought to be changed to 4646?

Anyway, that doesn't wholly help you, becuase just because you have an
identifier doesn't mean you have a reasonable repertoire of
characters.

More broadly, I'd like it a lot if people went and looked at the
discussion of zone repertoires and the label generation rules in the
recent ICANN Variant Issues Project (announcement here:
http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm).
I came to believe over the last six or so months that neither
"language" nor "script" is what we want here, and I think it would be
extremely helpful to have some other eyes on the discussion of this
issue in that report.  While the report is actually aimed only at the
top level, I think this part of the report is broadly applicable to
any zone that has to serve a linguistically diverse population
(i.e. pretty much every gTLD and some ccTLDs too).

Best regards,

A

-- 
Andrew Sullivan
<[email-masked]>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Jan 2012 15:25:14 -0500

On Thu, Dec 22, 2011 at 05:53:31PM +0000, Keith Gaughan wrote:
> Instead, 'writing system'[1] would be better: so long as the writing system
> contains no homographs[2], there's no issue.

Alas, most alphabetic languages are full of homographs.  But I bet
that isn't what you mean, anyway; homograph turns out to have an
established meaning in linguistics, and it isn't "two letters that
look the same".  In the ICANN VIP discussions we settled on
"homoglyph" as a possibly useful alternative.  Cary Karp has extensive
opinions about this.

> [1] By which I mean, all the languages that use the Latin alphabet could be
>     said to share a common script and writing system, which are both the same
>     thing. It's not an ideal term, I know.

Indeed, it's wrong, as a consideration of the fall-back handling of
o-with-diaeresis in Swedish and German illustrates.  German considers
ö to be an o with an accent on it.  In Swedish, it's a separate
letter.  That's why German orthography can fall back to "oe" but
Swedish doesn't.

> [3] I can't recall whether Traditional and Simplified Han characters occupy
>     different code points in general, or the same ones.

They're different code points, and different Abstract Characters in
Unicode terms; but there are usually pairs (with some nasty corner
cases) of the same Conceptual Characters in TC and SC.  Also, since
they're all part of Unihan, they're all "the same script". 

Slightly worse, Japanese uses the same code points, and they have a
_different_ pair of Old Form/New Form changes that were undertaken,
but they don't exactly regard them as the same Conceptual Characters.
This is because, I'm told by our friends at JPRS, they consider domain
names to be proper nouns and therefore always to be spelled exactly
one way.

Best regards,

A

-- 
Andrew Sullivan
<[email-masked]>

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 4 Jan 2012 12:35:48 -0800

> Doing some catch-up.  Sorry for coming in late.

Hi Andrew, thanks for your comments,

> identifier doesn't mean you have a reasonable repertoire of

I wasn't implying that, the appropriate repertoire of characters associated with a particular value, will be given by the registry.. Most registries publish their supported registration characters in IANA [1]

What might be needed (for additional flexibility), is to remove the "language" type in the XML Schema, for a simple "String" so that it can be defined by the registry on will.. Basically it will work as a 'selector' of a specific registry policy to be applied to the registration.

> (i.e. pretty much every gTLD and some ccTLDs too).

+1

> Best regards,

Thanks!

> A
> 
> -- 
> Andrew Sullivan
> <[email-masked]>
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

[1] http://www.iana.org/domains/idn-tables

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE

---

From: "Gould, James" <[email-masked]>
Date: Wed, 4 Jan 2012 21:40:28 +0000

Francisco,

This draft looks very similar to our custom "IDN Language Tag" extension
available at the URL
http://www.verisigninc.com/assets/idn-language-tag.pdf.  In our custom
extension only the create is extended; although I believe including it in
the info response is an enhancement driven by the login extension
services.  We only require the extension for punycode encoded IDN domain
names, so my question is if the extension is not included, is the default
assumed to be language "en"?  I'm assuming that this extension would only
be required for IDN registrations based on its name, but it's not clear.
Our custom extension includes the text "A valid language tag is a required
field for ALL IDN registrations".  We require puny code encoded domain
name values for the IDN registrations, which is the key to determine if
the extension is required.  Some verbiage in the draft around when the
extension is required and what is the expected behavior for registrations
when it's not provided (e.g. default of "en") would be helpful.  Use of
the XML schema language type is flexible from a protocol perspective, but
the registries would need to publish the supported language tag values
most likely out-of-band.  Hopefully we could define a consistent
scheme for the possible language tag values.

As far as the thread around adding the extension to the check, I don't see
a driver for adding the extension to the check since the check command
typically only does a simple availability check and doesn't implement all
of the business logic validation that is done in the create.  The check
needs to be fast and it supports multiple domain names that could have
different language tags, thus requiring the registrant to execute multiple
checks or adding additional complexity to the idn language tag extension.

-- 

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

On 12/21/11 7:32 PM, "Francisco Obispo" <[email-masked]> wrote:

>Draft for EPP-IDN extension has been submitted.
>
>
>
>Begin forwarded message:
>
>> From: [email-masked]
>> Subject: New Version Notification for draft-obispo-epp-idn-00.txt
>> Date: December 21, 2011 4:22:34 PM PST
>> To: [email-masked]
>> Cc: [email-masked], [email-masked], [email-masked]
>> 
>> A new version of I-D, draft-obispo-epp-idn-00.txt has been successfully
>>submitted by Paul Selkirk and posted to the IETF repository.
>> 
>> Filename:	 draft-obispo-epp-idn
>> Revision:	 00
>> Title:		 Internationalized Domain Name Mapping Extension for the
>>Extensible Provisioning Protocol (EPP)
>> Creation date:	 2011-12-21
>> WG ID:		 Individual Submission
>> Number of pages: 8
>> 
>> Abstract:
>>   This document describes an Extensible Provisioning Protocol (EPP)
>>   extension mapping for the provisioning of Internationalized Domain
>>   Names (IDN) stored in a shared central repository.  This mapping
>>   extends the EPP domain name mapping to provide additional features
>>   required to implement registrations of domain names in characters
>>   sets other than ASCII.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>
>Francisco Obispo 
>email: [email-masked]

---

From: Keith Gaughan <[email-masked]>
Date: Fri, 06 Jan 2012 13:35:52 +0000

On 22/12/11 20:25, Michael Young wrote:

> First of all Janusz, who submitted that Afilias IDN I-D was working for me
> at the time, I thought it seemed like a good idea at the time to encourage
> standardization.

It was, very much so.

> We were thinking primarily languages versus scripts due guidance we had from
> John Klensin  at the time.
> 
>> Though more specifically, the point of even asking for the language in the
> first place is to prevent homograph attacks. The use of languages rather
> than scripts leads to slightly odd situations where a person wouldn't be
> able to register a domain >like æçöÿ.info (a silly example, I know, but
> valid), as though there's no language that uses all those characters in
> their alphabet, it's in no way a vector for homograph attacks.

> So specifically we thought about the above case and decided that a language
> was a construct of sorts, usually indicated by a group or community
> declaring and codifying its uniqueness.

Even that's not entirely correct, as the linguist Max Weinreich wrote about
the social plight of Yiddish, "a shprakh iz a dialekt mit an armey un flot".
That's why EURid went down the route of specifying codepoint tables for
scripts rather than languages: it's *relatively* easy to deliminate scripts
and thus avoid homograph attacks within scripts[1] than it is to decide what
language ought to be allowed, especially when that means that going the
language route can end up inadvertently discriminating against minority
languages for no good reason.

> We figured any policy in
> registration should be made against a language table that was in turn
> defined by a recognized language authority.  Now "language authority" is a
> wide range, but so are the number of defined languages. 

Not all recognised languages have language academies though, especially
minority languages, and in some parts of the world (India, for example),
there's a common folk belief that to be a real language without having its
own distinct script, even if those languages with the common script are
members of totally different language families, like Indo-Aryan and Dravidian.
IIRC, the Grantha script was an historical example of this. And then there's
the interesting situation in Chinese that bungs 'dialects' as different as
Welsh and Greek are from one another under a single banner as 'Chinese'.

> We decided against defining the policies (at that time in 2004, I am not
> speaking to anyone's current practise/policy) by script because we didn’t
> see a graceful way to address different spoken languages that shared the
> same script.

The graceful way to do this is to have multiple tables per script to check
labels against. If all the characters in the label are whitelisted in any
one of those tables, then it's valid. That solves the homograph problem
without discriminating against minority languages (and Europe still has a lot
of them), and copes just fine with situations like Serbian, which uses both
the Latin and Cyrillic scripts. All that's saved by requiring a language code
is CPU cycles.

K.

[1] Odd cases like s-comma in Romanian versus s-cedilla in Turkish aside,
    though that's an example of a near-homograph rather than a true homograph.
    This kind of thing is the best argument for going down the language rather
    than the script.

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Keith Gaughan <[email-masked]>
Date: Fri, 06 Jan 2012 15:28:59 +0000

> "homoglyph" as a possibly useful alternative.  Cary Karp has extensive

I prefer 'homoglyph' myself, but nearly every time I've seen mention of the
attack, the word 'homograph' rather than 'homoglyph' is used.

> letter.  That's why German orthography can fall back to "oe" but

Although an interesting historical note is that Swedish 'ö' started out as
'oe'.

> they're all part of Unihan, they're all "the same script". 

Thought that, but couldn't remember.

K.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Jan 2012 10:41:27 -0500

This email is a little long.  I'm not picking on Keith Gaughan; his
email was just a convenient hook for this.  If you don't want to read
all this, skip to the [Conclusion] at the end.

> the Latin and Cyrillic scripts. All that's saved by requiring a language code

I already asked this once, but I do so again: there's considerable
discussion of what's called "label generation rules" and "zone
repertoires" in the recent ICANN VIP draft report.  The report is open
for public comment right now:
http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm.
I'd really like some additional eyes on those sections: I wrote a
substantial amount of that text, and I'm not completely sure it's all
right.  But I think it's a possibly-useful direction.  The section that discusses this at length is section 4, starting on page 39.

In any case, I think the script/language distinction is invidious for
our purposes: both are important considerations.  So I want to expand
a little on what's in the VIP draft and try to explain in more detail
the sort of approach I think will work in the long term.  

There are, in addition, several problems with this discussion of
"tables", the most obvious of which is that we don't have a standard
for such tables that actually works for everyone.  What that really
means is that, for zones that span widely divergent languages and
writing systems, we are already in trouble.

RFC 3743 was an extremely important and clever answer to the peculiar
problems of one sort of writing system.  It was also seminal, however,
and that's a little unfortunate because the CJK systems are extremely
bad analogies for everything else.  (Indeed, Korean is almost unique
in the history of human writing, and Chinese is completely unusual in
the world today.)  One issue with RFC 3743 and all of the work that
has followed from it (including RFC4290) is that the basic "table"
idea conflates a number of functions that just happen to be aligned in
the cases for which the JET guidelines were designed.  One of these is
to specify the code points the registry (i.e. zone operator --
remember that a registry isn't necessarily an operator of TLDs, but
just a repository of information for some administrative area, in this
case DNS zones) will accept in U-labels for the zone.  Another is to
associate an identifier with the subset of code points constrained by
some rules.  Another is to specify alternative labels that may or must
be delegated along with some "fundamental" label (e.g. the one that
was submitted to the registry).  Another is to specify alternative
labels that may not be registered in the presence of that fundamental
label.  And another is to specify alternative labels that must not be
active in the zone when that fundamental label is in the zone.  (All
these "alternative label" bits are one of the kinds of things people
call "variants", and what RFC 3743 meant by "variant".)

Not all of these purposes are actually achieved in any of the table
formats registered with IANA (there is more than one format, alas).
For instance, the specification of the first purpose (what code points
are permitted, which we can call the "zone repertoire") is actually
derivable only from the union of all the tables a registry uses.
Similarly, it works out, the alternatives and their associated
permissions with respect to activation also need to be derived using
all the defined tables.  Some table formats can't distinguish between
"normally activated" and "must be activated", nor between "not
normally activated but may be at applicant's choice" and "must not be
activated".  None to my knowledge can distinguish between "must be
delegated if activated" and "must be aliased if activated".

People are actually using the tables for different purposes.
Verisign, for instance, has recently submitted a very large number of
tables to IANA that effectively permits every Unicode code point that
works for IDNA (and I haven't even validated the second part of this),
but specifies no alternative forms at all; their submissions include
one for the Arabic script.  SaudiNIC, on the other hand, registered a
table for Arabic language (not script) that includes complicated rules
for alternative handling according to the position of a code point in
a candidate label; the "table" also has a number of rules written into
it.

Even if we were to recognise implicitly the different roles outlined
above, while maintaining the somewhat-underdefined notion of a
"table", I think there are certain basic truths about the functioning
of IDN labels at or near the top levels that we're going to need to
keep in mind.  The first is that, with an extremely large well of
potential code points, the DNS registration community is going to have
to converge on conventions for most of these code points relatively
quickly.  If a code point has vastly different behaviour in different
zones, either that code points just won't get used at all, or else the
code point will come to be a source of a lot of confusion, phishing
opportunities, and frustration.  (Or else the outlier behaviours will
get lost, but that's just a variation of "not used".)  The second is
that we are never going to be able to cram every user expectation
about a given code point's behaviour into the global DNS: there are
too many funny ways an identifier system like the DNS can trip people
up.  Paradoxically, the third is that people will use DNS names based
on their preconceptions of how their letters work, and we had better
be prepared for those expectations or we will subject people to very
nasty surprises.  

An effect of points (2) and (3) above is that we actually ought to be
reluctant, rather than eager, to add additional code points whenever
they are not absolutely required.  For instance, there are a lot of
optional marks in Arabic; I think nobody should ever permit them in
high-level zones, because they're just going to cause confusion.
There are words in some languages (Farsi and Nepali both come to mind)
that can't be written without the ZWNJ; but I think nobody should
permit labels of such kinds in multi-language high-level zones _even
though it would be useful_, because the danger of interaction with
other linguistic rules is just too great.  Apostropoids like U+02BC
are more or less impossible to get along without in some languages
(Ukranian comes to mind), but I think adding such a code point to a
high-level multi-language zone is asking for serious trouble
(particularly in the case of Ukranian, where most standard keyboards
don't even have a keycode that usually generates that code point).

Moreover, the way that the zone repertoire gets established is
politically fraught.  Some cases are simple, even for languages
without an academy to establish their rules (English is an excellent
example here).  But one should consider very carefully the political
situation in parts of Eastern Europe and Western Asia before being
glib about the problems of who gets to decide whether a language is
written in Latin, Cyrillic, or Arabic scripts (and, after that, which
subset of each).  This is why I like an approach something like the
sample "approach 3" from section 4.2 of the VIP report: it doesn't
leave us stuck with the Unicode script properties, it doesn't require
us to come up with rules for all the code points we don't understand,
and it still encourages widespread engagement with relevant language
and script users.

[Conclusion]

Because of all of the above, I'd like to step back a bit from the
language-vs-script and table-based way of framing this discussion and
focus more on how one selects which set of code points one wants to
use and, if there are rules governing the behaviour of those code
points, how one expresses one's options under those rules.  This will
make for a more complicated EPP extension, but it will also make for
one that actually matches the different registry policies already in
place today.  By creating an extension that can accommodate the many
different policies in place, we might be able to reduce the number of
extensions that actually get deployed.

Best,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 06 Jan 2012 11:36:27 -0500

> extensions that actually get deployed.

Concur. An ASCII (hex) code point repertoire of {(41,61), (45,65),
(49,69), (4f,6f), (55,75), (59,79)} (English vowels) is just as
reasonable a repertoire {30 ... 39} (digits) and just as reasonable a
repertoire as {30, 32, ... (5a,7a)} (even valued points within LDH) as
the ASCII LDH set of code points. None are sufficiently characterized
as "language" or "script", but are sufficiently characterized as
enumerations or rules for the construction of repertoires of code points.

For a less mathematician-centric or
bottom-half-of-the-tty-driver-centric example, consider the "proper
word" requirement of the circa-2006 Arabic Script group. A "is in a
dictionary and is not on a reserved list" rule is neither "Arabic"
(the language") nor "Arabic Script" (the Unicadette created thingie an
earlier instance of the IDN WG, steered by non-contributors, elected
to commit _some_ DNS text resource records to). The dictionaries of
two "Arabic Language" supporting and "Arabic Script" using registries
may differ, as may their reserved lists.

Verisign's take on Arabic makes me grin. I hope they'll be just as
creative when it comes to Chinese.

My two beads worth,
Eric

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 6 Jan 2012 09:12:56 -0800

Andrew,

How about if we change the <idn:language> tag for <idn:table> and its value will be the "name" of the IDN table as published/offered by the registry?

That way we can remove the discussion of language vs. script from the extension itself, and it would be broad enough to let each registry define their own set.

Francisco

Francisco Obispo 
email: [email-masked]

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 06 Jan 2012 12:32:40 -0500

> How about if we change the <idn:language> tag for <idn:table> and its value will be the "name" of the IDN table as published/offered by the registry?

This allows the possibility of per-registry versioning of "name", and
of non-unique names (or registry scoped name uniqueness, see
"versioning" above).

Abstractly, this is a database write access token, and the (ICANN)
policy issue of equal access / registry-registrar collusion is
non-solved, absent out of band compliance review, so accepting an
arbitrary access token may be good generic
any-level-in-any-DNS-hierarchy engineering, accepting only an ICANN
identified access token for ICANN generic namespaces may be a better
IETF protocol parameter choice.

YMMV.

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Jan 2012 14:06:46 -0500

> How about if we change the <idn:language> tag for <idn:table> and its value will be the "name" of the IDN table as published/offered by the registry?

There will be people annoyed by "table" because they think that's a
particular implementation.  I'm indifferent.  I think it's better than
language or script, though.  I've just been calling it a repertiore
identifier, so what about repID?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 6 Jan 2012 19:35:29 +0000

Eric,

Verisign has posted tables of allowed codepoints with IANA.
(http://www.iana.org/domains/idn-tables)  I wonder if you might be
referring to the Arabic table for the COM namespace.
(http://www.iana.org/domains/idn-tables/tables/com_arab_1.0.html)  This
table reflects codepoints allowed in a COM domain by the Verisign
Registry.  The codepoints are based on the Unicode Standard, version 6.0.
And specifically the scripts.txt file.
(http://www.unicode.org/Public/UNIDATA/Scripts.txt)

Verisign's goal is to leverage appropriate standards wherever possible,
and that's what we tried to do with the Arabic table, and with other
tables posted to the IANA site.  But we're certainly open to ideas you
might have about this or other tables.  Constructive feedback is very
welcome.

-- 

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

---

From: Keith Gaughan <[email-masked]>
Date: Mon, 09 Jan 2012 16:32:27 +0000

> identifier, so what about repID?

I'm fine with any of them. 'whitelist' would also be ok.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 09 Jan 2012 11:58:23 -0500

> I'm fine with any of them. 'whitelist' would also be ok.

I suggest that repID is almost sufficient.

Again, using the LDH set, we have a rule about the H, not the initial
or terminal, and not repeated.

So repID + rulesetID.

e.g.,

{a,b} = rep, repID = 0

rule0 = initial {a}
rule1 = terminal {a}
rule2 = no repeated code points

{rule0, rule1, rule2} is a ruleset, the rulesetID = 0

Eric

---

From: Keith Gaughan <[email-masked]>
Date: Mon, 09 Jan 2012 18:50:17 +0000

On 22/12/11 18:48, Klaus Malorny wrote:

> I agree to you, but the language tag(s) could be helpful in the coice of
> possible IDN variants. Take the letter "ö". In German, it is legal to write
> "oe" instead of "ö", so "götter" and "goetter" are considered equal and thus a
> registry could reserve the other variant for the registrant of the first. For
> a different language (maybe Swedish?), the "ö" may exist as well, but there is
> no such rule, the two words are considered different and there is no reason to
> block the other. I am in no way a language expert, but I guess there is a
> similar game with accents and esp. with ideographs in other languages.

That's actually a good point, but how exactly they're treated very much
depends on registry policy. For instance, does the registry implicitly
register ASCII variants (as the .cat registry does) or treat them as totally
separate entities (which is EURid's policy), and if you follow a .cat-like
policy, and say (queue silly example) 'foo', 'föö' and 'fóó' are considered
considered distinct words in the language but the convention is to simply
omit the accents, should registering one of them block the others?

That's a pretty complex question.

> Regarding multiple tags: I personally think it should be legal to mix
> languages and scripts under certain (narrow) conditions.

> Why should a domain
> like "café-mосква.ru" not be possible?
        ^^   ^^^  ^
Because it's open to homograph attacks, as demonstrated above. To avoid that,
you'd have to specify some way of deliminating words within the label (as you
did with the hyphen), but that complicates things an awful lot for very little
gain, and you'd have people complaining that they can't register
"cafémосква.ru", which in their eyes might be equally legitimate.

[Aside: To save myself, I'm going to use the abbreviation 'CGL' to refer to
Latin, Cyrillic, and Greek together.]

Now, script mixing isn't necessarily bad. For instance Latin and Hangeul
codepoints in an IDN is safe because there's no chance of homographs. Mixing
CGL, OTOH, is dangerous because all three contain an awful lot of identical
characters. The problem with the CGL scripts is that they are, in essence,
variations on the very same script. Majuscule Latin characters are
practically the same as the Euboean variant of the ancient Greek alphabet.
Cyrillic started out as a variant on the Greek alphabet that borrowed a
number of extra symbols from its predecessor, Glagolitic, to represent sounds
that didn't exist in Greek but did exist in Old Church Slavonic (Old
Bulgarian). This left us with a situation where three now-distinct scripts
ended up with a lot of identical or at least very similar glyphs.

> I don't know whether such a domain name
> make sense regarding usability, but from a registry viewpoint it shouldn't
> matter.

A registry without any form of codepoint whitelisting wouldn't care, but if
we want to avoid abuse of homographs, the choice is either to require the
CGL scripts not be mixed in the one IDN or have rules for how a label should
be partitioned up. Not mixing these three scripts together is, without a
shadow of a doubt, the least troublesome option.

> At the end the basic question is what needs the extension shall cover. As far
> as I can see, the existing and future gTLDs seem to be mostly bound to the
> visions of ICANN (and this is the "one language" approach), whereas existing
> ccTLDs seem to be rather free in their IDN implementations. So the latter
> could have the need of a different approach, but are they interested in such
> an extension at all?

In my experience so far, ccTLDs in countries that use one or more of the CGL
scripts chose the ghostbusters option: don't cross the streams. The Serbian
registry would be an example of this as they have two national scripts. They
allow IDNs in one or the other, but mixing is not allowed. They do not, to my
knowledge, use any extensions for determining which script is used. I'm open
to correction on this though.

K.

---

From: Klaus Malorny <[email-masked]>
Date: Tue, 17 Jan 2012 19:28:57 +0100

> That's a pretty complex question.

Indeed. But even if two differently accented words have different meanings, it 
could make sense to allow only one of them to avoid confusion (at least to 
someone who also thinks that no second tablet computer with rounded corners and 
a centered display may exist ;-))

> "cafémосква.ru", which in their eyes might be equally legitimate.

This is what I meant with "narrow": e.g. that the words must be separated by a 
hyphen and that each word must not entirely consist of letters for which 
homographs exist in the other script.

I admit that such rules may be complex, likely too complex. The benefit of 
having such domains might be outweighed by programming logic and the task to 
explain this to registrars and registrants.

Regards,

Klaus