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

From: Francisco Obispo <[email-masked]>
Date: Wed, 21 Dec 2011 16:32:27 -0800

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]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 22 Dec 2011 06:49:28 +0100

1. What if the domain name is mapped to more languages than one?
2. What values are acceptable for the field?

   Patrik

On 22 dec 2011, at 01:32, Francisco Obispo wrote:

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

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 21 Dec 2011 22:10:52 -0800

> 1. What if the domain name is mapped to more languages than one?

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. Even in the case of this exception, visually 
  confusable characters from different scripts will not be allowed 
  to co-exist in a single set of permissible code points unless a 
  corresponding policy and character table is clearly defined.

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

> 2. What values are acceptable for the field?

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 are valid language identifiers as defined [RFC 3066] . The ·lexical space· of language is the set of all strings that conform to the pattern [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})* . The ·base type· of language is token.

3.3.3.1 Constraining facets

language has the following ·constraining facets·:

	• length
	• minLength
	• maxLength
	• pattern
	• enumeration
	• whiteSpace

[1] http://www.w3.org/TR/xmlschema-2/#language
[2] http://www.ietf.org/rfc/rfc3066.txt

Francisco

Francisco Obispo 
email: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 22 Dec 2011 08:11:04 +0100

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

Then let me ask a meta question: Why is this defined _only_ for the _current_ "IDN Implementation *guidelines*"? I thought IETF was a bit better than that when looking at what is the best *protocol*. And one of the reasons I asked was because I wanted to know in what direction you felt normative references should be referring between ICANN and IETF documents.

FWIW: I think it is a very bad idea if there are normative references regarding cases like these from IETF to ICANN documents. This because normative references so far is in the other direction.

And the I-D does not make this clear.

> [2] http://www.ietf.org/rfc/rfc3066.txt

So, what is the normative reference?

The W3C definition?

Or only what is registered with IANA in the Language Tags registry?

This is still unclear to me, and I encourage you to make that clear in the next version of the document.

And another question: How is equivalence between language tags to be calculated? Someone use "en" and someone else en-UK and a third party en-US or en-US-UK?

   Patrik

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Dec 2011 15:49:21 +0000

> Draft for EPP-IDN extension has been submitted.

I'd like to bring up an earlier I-D Afilias submitted to the IETF six years
ago:

    http://tools.ietf.org/html/draft-sienkiewicz-epp-idn-00

This draft was flawed in that it required the script be specified with the
<check> command, but it did have one nice feature.

During creation, rather than what you propose:

  <idn:language xmlns:idn="urn:iana:xml:ns:idn-1.0">de</idn:language>

You'd do this:

  <idn:create xmlns:idn="urn:iana:xml:ns:idn-1.0">
    <idn:script>de</idn:script>
  </idn:create>

This has the (potential, though unrealised) advantage of allowing multiple
languages to be specified, although the choice of <script> rather than
<language> as an element was suspect.

I'd propose that the draft be amended to have a <create> element as shown
above for IDN creation and and <infData> element for responses. Thus, the
an IDN extension for creating a domain valid in both Norwegian and Danish
would look like this:

  <idn:create xmlns:idn="urn:iana:xml:ns:idn-1.0">
    <idn:language>da</idn:language>
    <idn:language>no</idn:language>
  </idn:create>

Other than that, I'm quite positive about this I-D.

K.

-- 
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: Thu, 22 Dec 2011 16:09:05 +0000

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

No, it would be possible. Some languages are similar enough that they share
many words in common (the various Scandinavian languages, Czech and Slovak,
the various Balkan languages formerly known as Serbocroatian, Scottish Gaelic
and Irish Gaelic, &c.), right down to having the same spelling[1].

[1] Although compatibility between Scottish Gaelic and Irish Gaelic was
    eliminated due to differing accent choice when both were standardised.
    The example still stands, mind.

It's reasonable that in such cases, a registrant may wish that both languages
be associated with the same domain as it's equally valid in the character
tables for *both* languages.

Essentially, what Patrik (and I) are asking is, if an IDN fits into a common
subset of the character tables of multiple languages, should it not be
possible to allow all those languages to be specified when registering the
IDN?

K.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Dec 2011 16:21:37 +0000

>     <idn:language>no</idn:language>

Just a note on why I chose these two: Danish and Norwegian share a common
alphabet, which is the standard Latin alphabet with the addition of æ, ø, and
å. Both sometimes uses additional diacritics for disambiguation, though these
diacritics are not part of the official spelling. That makes these two a
useful example of why one may want to attach multiple language tags to an
IDN.

---

From: Jim Reid <[email-masked]>
Date: Thu, 22 Dec 2011 16:38:24 +0000

> possible to allow all those languages to be specified when  

It might not be that simple. Should it be "all languages" or "all  
scripts"? I'm thinking of Japanese where there could be as many as  
four different alphabets (scripts) used for representing one word. I'm  
also having flashbacks to the confusion between scripts and languages  
when ICANN was discussing IDN TLDs 2-3 years ago. ISTR there are  
differences between the Chinese characters used in Taiwan and those in  
the People's Republic.

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 22 Dec 2011 08:41:01 -0800

> possible to allow all those languages to be specified when registering the

Does it make a difference from the registration point of view?,

The main purpose of this field, is so that the registry can apply a specific registration policy, in this case, the validation of unicode codepoints from a *published* language table towards the label (not a script).

So basically the client (registrar), will select which language, from the registry published list to use, and then the registry will validate the request using that specific table.

I guess we could make the extension flexible enough to allow for multiple "languages", but then make that an *optional* feature for the registry to allow it.

Best regards,

Francisco Obispo 
email: [email-masked]

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 22 Dec 2011 08:42:10 -0800

On Dec 22, 2011, at 8:38 AM, Jim Reid wrote:
> It might not be that simple. Should it be "all languages" or "all scripts"? I'm thinking of Japanese where there could be as many as four different alphabets (scripts) used for representing one word. I'm also having flashbacks to the confusion between scripts and languages when ICANN was discussing IDN TLDs 2-3 years ago. ISTR there are differences between the Chinese characters used in Taiwan and those in the People's Republic.

This is why I think it's sane to attach the request to a language and not to a script. (in my opinion).

Francisco Obispo 
email: [email-masked]

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Dec 2011 17:11:00 +0000

On 22/12/11 16:41, Francisco Obispo wrote:

> Does it make a difference from the registration point of view?

Maybe not, but then why ask for the language at all? One could do what EURid
does and have a set of character tables per supported script (Latin, Greek and
Cyrillic), and so long as all the characters in an IDN are within the same
script, the registration is accepted.

It seems to me that given significant edge cases like the Danish/Norwegian
one I raised, if a language must be specified, one ought to be able to specify
multiple ones.

> The main purpose of this field, is so that the registry can apply a specific
> registration policy, in this case, the validation of unicode codepoints from
> a *published* language table towards the label (not a script).

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.

> I guess we could make the extension flexible enough to allow for multiple
> "languages", but then make that an *optional* feature for the registry to
> allow it.

That I'll have to think about. I'm not sure it's exactly a massive
encumbrance upon an implementing registry to store all the associated
language codes, but then again, it may be acceptable for a registrar to
allow one and only one to be specified per IDN[1].

K.

[1] I raised the idea a while back about having a way for registries to
    be able to publish their policies in a machine-readable form a while
    back. This sort of thing would fit quite comfortably into it.

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 22 Dec 2011 17:53:31 +0000

Apologies in advance for all the footnotes.

On 22/12/11 16:38, Jim Reid wrote:

> It might not be that simple. Should it be "all languages" or "all scripts"?
> I'm thinking of Japanese where there could be as many as four different
> alphabets (scripts) used for representing one word.

The point is primarily not to allow homograph attacks. 'Script' mightn't be
the best way to think of things, especially with the likes of Japanese.
Instead, 'writing system'[1] would be better: so long as the writing system
contains no homographs[2], there's no issue.

> I'm also having flashbacks
> to the confusion between scripts and languages when ICANN was discussing IDN
> TLDs 2-3 years ago. ISTR there are differences between the Chinese characters
> used in Taiwan and those in the People's Republic.

Well, that goes back to the whole headache of Han unification in Unicode, and
it doesn't just apply to Simplified vs Traditional Hanzi, but also Kanji
(Japanese) and Hanja (Korean). All may be rendered differently, even if they
share codepoints[3], which I'm sure made plenty of headaches for the people
behind .asia. RFC 3743 sorted that mess out for the most part, didn't it?

K.

[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. Japanese and Chinese could be said
    to have separate writing systems even if they both have variants of a
    common script as part of them. Japanese has a writing system that
    consists of four--six if you count Hentaigana and Man'yōgana--different
    scripts.

[2] And between Hiragana, Katakana, Romaji, and Kanji, there are none that I
    know of, though variant Han characters are problematic, which is a
    known problem that's been dealt with by the various registries already.
    Sometimes I wonder why the Japanese haven't gone down the same road as the
    Koreans are going down (gradually abandoning Hanja for exclusive use of
    Hangeul) and Vietnamese (which no longer uses Han characters at all),
    especially when it has two excellent syllabaries.

[3] I can't recall whether Traditional and Simplified Han characters occupy
    different code points in general, or the same ones. It's years since I
    last looked that up, so I'd ask leniency about any inaccurate remarks I
    may have made on that issue.

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 22 Dec 2011 19:48:19 +0100

> it's in no way a vector for homograph attacks.

Hi,

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.

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? I don't know whether such a domain name make 
sense regarding usability, but from a registry viewpoint it shouldn't matter.

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?

Regards,

Klaus

---

From: "Michael Young" <[email-masked]>
Date: Thu, 22 Dec 2011 15:25:03 -0500

So a couple of things,

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.

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. 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. 

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.  Hence why we went with "language" versus script. 

Also, we voluntarily filed our language table with IANA back then when we
introduced German in .Info.  That was an attempt to encourage all the
registries to adopt at least the same tag nomenclature.  

Best Regards,

Michael Young
M:+1-647-289-1220