Re: [eppext] Fwd: New Version Notification for draft-wilcox-cira-idn-eppext-00.txt

[Patrick Mevzek <[e-mail]>]

Stuart Olmstead-Wilcox <[e-mail]> 2015-06-11 20:11
> Regarding your comment on IDN table vs repertoire - can you point me at some of the documents you are referencing?   Draft's such as draft-obispo-epp-idn-04 use IDN table but I am not aware of other references.   

I believe that this use case comes from the fact that in the IDNA2003
protocol you had a lot of tables to decide if a character is allowed
or not and various translations rules (see nameprep),
where the newer version of IDNA
switched to a procedure/algorithm-based working way.

Some documents speaking about "IDN tables", in no particular order:

* "The IDN Variant Issues Project A Study of Issues Related to the Management of IDN Variant TLDs (Integrated Issues Report)"
https://www.icann.org/en/system/files/files/idn-vip-integrated-issues-final-clean-20feb12-en.pdf

* "Guidelines for the Implementation of Internationalized Domain Names | Version 3.0"
https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en
=> "unless a corresponding policy and character table is clearly defined."

* IANA repository
http://www.iana.org/domains/idn-tables
=> IANA maintains a collection of “IDN tables”,

and
"Repository of IDN Practices — Procedures"
http://www.iana.org/help/idn-repository-procedure
=> The IANA Repository of TLD IDN Practices, also known as the ”IDN Language Table Registry“, was created to support the development of the IDN technology.

In the same way see Kim Davies draft:
http://datatracker.ietf.org/doc/draft-davies-idntables/
and specifically:
   Administrators of the zones for top-level domain registries have
   historically published their LGRs using ASCII text or HTML.  The
   formatting of these documents has been loosely based on the format
   used for the Language Variant Table described in [RFC3743].
   [RFC4290] also provides a "model table format" that describes a
   similar set of functionality.  Common to these formats is that the
   algorithms used to evaluate the data therein are implicit or
   specified elsewhere.

(of course, if this goes further, semantically those objects would not
be flat tables anymore as they encode various algorightms and rules,
but this another debate).

* Joint Engineering Team (JET) Guidelines for
         Internationalized Domain Names (IDN) Registration and
            Administration for Chinese, Japanese, and Korean
(more than 10 years ago)
http://tools.ietf.org/html/rfc3743
=> The Language Variant
   Table mechanisms described here allow JET to enforce language-based
   character variant preferences, and they set an example for those
who
   might want to use variant tables for their own policy enforcement.

and http://tools.ietf.org/html/rfc4290
=> Each registry is expected to construct (or obtain) a table for each
   language it considers relevant and appropriate.  These tables list,
   for the particular zone, the characters permitted for that
language.
   If a character does not appear as a base character (called a "valid
   code point" in the JET document) in that table, then a name
   containing it cannot be registered.  If multiple languages are
listed
   for the registration, then the character must appear in the tables
   for each of those languages.




* https://www.rfc-editor.org/rfc/rfc5992.txt
"Internationalized Domain Names Registration and Administration
            Guidelines for European Languages Using Cyrillic"
=> The registration strategy described in this document uses a table
   that lists all characters allowed for input and any variants of
those
   characters.  Note that the table lists all characters allowed, not
   only the ones that have variants.



* http://www.rfc-editor.org/rfc/rfc5894.txt
"Internationalized Domain Names for Applications (IDNA):
                 Background, Explanation, and Rationale"

=> The character rules in IDNA2008 are based on the realization that
   there is no single magic bullet for any of the security,
   confusability, or other issues associated with IDNs.  Instead, the
   specifications define a variety of approaches.  The character
tables
   are the first mechanism, protocol rules about how those characters
   are applied or restricted in context are the second, and those two
in
   combination constitute the limits of what can be done in the
   protocol.  As discussed in the previous section (Section 3.2),
   registries are expected to restrict what they permit to be
   registered, devising and using rules that are designed to optimize
   the balance between confusion and risk on the one hand and maximum
   expressiveness in mnemonics on the other.
[…]
   Under this model, registry tables will need to be updated (both the
   Unicode-associated tables and the tables of permitted IDN
characters)
   to enable a new script or other set of new characters.



HTH,



-- 
Patrick Mevzek