ICANN JET Meeting Notes

NOTES OF JET MEETING OCTOBER 30 2002

1300-1800

IDN Charter: http://www.ietf.org/html.charters/idn-charter.html

draft-ietf-idn-dnsii-trace-01.txt

draft-ietf-idn-idna-14.txt

draft-ietf-idn-nameprep-11.txt

draft-ietf-idn-punycode-03.txt

draft-ietf-idn-uri-02.txt

• derived work of Japanese Domain Name (JDN) technical rules
• published as I-D
• draft-ietf-idn-jpchar-0[01].txt

http://www.wwtld.org/~shanghai/IDN-Case%20Study-on-chinese-character-table.pp

Why develop table?

• Traditional Chinese and Simplified Chinese domain name equivalents
• protect user's profit
• variants cause serious domain name conflict
• cybersquatting
• sample of characters sets and unicodings - e.g. eight variant

CDNC Drafts

• range covering issue

Problems

• requirements of CDNC not accepted by IETF drafts, so variants still issue. Resolution and Disputes issue

IDN Administration Guidelines have rough consensus - see IETF website

List of recommended modifications to Guidelines?

Hiragama and Katakana are variants of Kanji. Derived from Kanji - cursive and part - not radical.

Has about 50 ?.

?..

Administration Guidelines

Domain Name Committee - no demand for variants as work done before and 18 months experience shows DRP sorts any issues out.

Other

Where should register table - IANA or ICANN?

(draft-jseng-idn-administration-01.txt)

- IDNA - Nameprep - punycode

• ISO/IEC 10646 unifies the Han ideograph, which is used by C, J, K. 71K Chinese characters; over 100K by next year; 50K still to be submitted.
• Unicode fine for code point, but the property of the characters not the same in each languageuage. This is internationalisation not localisation

Variants

• character (code) variants refer to characters, e.g., A and a; is languageuage dependent
• orthographic variants - word for word substitution
• Lexemic variants: e.g., taxicab, taxi and cab - same meaning, depending on location/usage. Code can't deal with
• Contextual variants - e.g. plane. Code can't deal with
• Therefore, character variance is the only one dealing with now

Tables: Japanese finished and published, Chinese finished but not published

Unidirectional - user enters characters which is looked up and resolved. If collision - picks preferred or gives no response. Can't start with the variants and go backwards to get only one answer - not fixable at this stage.

From the standpoint of users - can only reach a name which is registered. If are two similar names can reach unexpected place.

• tables attempt to resolve the confusion
• reserve name-variant bound to a registrant - can't be looked up, so OK; BUT means the preferred name MUST be the one registered.

REMINDER: don't expect the DNS to do the impossible. All this does is to attempt to deal with the catastrophes? http://www.wwtld.org/~shanghai/ICANN-IDN-JET-2002Oct.ppt

Every languageuage and every script has the internationalisation issues. English has 100 characters, Chinese 68,000, so currently the system copes with the issues in realtime.

Since protocols won't provide protection, some alternatives:

• registry restrictions: per-zone or global on what can be registered
• an extension of letter, digit, character restrictions
• script homogeneity per zone or global
• letting the market sort it out. Problem here may damage others as well as self. See Chen's presentation - can't handle 20% collision

Re James' presentation:

• most of the work done by JET - not finished. Solutions are separate issues: Registry, registrar, user expectations
• main focus on C-J-K
• difficult because of language overlay - therefore long tables
• add reform of Chinese (all languages have this at some stage); usually means "improvement" to spelling etc - not backwards compatible
• Chinese 1 script language; Korean 2 script; Japanese 3 scripts
• add overseas Chinese communities which likely use 18^th C Chinese
• all languages have the ambiguities - even English
• New question - who has the ability and "nerve" to enforce rules
• re tables - other languages will be easier that C-J-K, but principals the same
• enforcement of registry restrictions will be primarily responsibility of ccTLDs; also have to make decision about how many and which languages included. These are hard decisions, but are the kind governments make all the time. gTLDs can't make those as easily (if at all)
• multilingual TLDs:
• TLDs with names other than Roman derived ISO 3166-1 codes (i.e. also write tld in own char set)
• can't just put everything in DNS and make it work. If just for own ccTLD need to add another 200+; if want to type all TLDs in your script - 200+ squared.
• original thought was just to put all them into root and would do it. Wrong.
• decision to put it on client side means huge pressure on client side
• motivation unclear:
• own language
• get a new TLD without the usual process

• remember how the DNS works: very hard to accurately administer parallel structures. The tools aren't there - hence no CNAMES at TLD.
• no "see also" construction
• TLDs are special - must be administered heterogeneously; 2LDs are not

• stop worrying, just make new TLDs
• not supported by IDN and ICANN
• administration problems huge
• allocation issues
• how many official languages in country
• alternative: translation

Have data on this

• Presentation: users don't care what's in database - just what they type in and see.
• Localisation: for limited namespace users can see whatever the application writer wants. Already tackled with ACE
• localised TLD wanted - good user software can hide some of this, but major thought gap?.
• probably a table somewhere that maps TLDs back and forth

• Is the DNS the right place to solve this?
• we need search machinery now, and will need search with IDN
• other
• seeing change of use - return to DNS as it's meant to be - centralised administration
• users don't like long URLs
• Simplistic solutions are not going to work, so need to look at alternatives

• respond to overall community and LIC
• ccTLDs ICANN can't compel, but education likely to work
• ICANN can take breakers out of root

• IETF didn't write 1591 or DNS.

• IETF is about constraints and how to get things in and out of DNS. Will not be making this happen. Really up to the Administrations. Some hard work to have IDNs and stability and intregity

- localisation does not require ICANN approval. Needs sorting locally.

• this affects stability so ICANN needs to act
• timing: may be as short as 30 days

JPDNA - trying to educate users

• almost 500K Japanese character string .jp names

Activities:

• info exchange
• standardisation of usage
• development of toolkit
• support of development and testing
• plugin is i-nav (Verisign) - simple download from .jp websites and major software download sites
• has a few installed URLs for jchar sites

• IDN Guideline provisioning process:
• IDN Administration Mechanism
• Table Registry Maintenance Agency? (suggesting IANA??)
• Tables

Meeting then adjourned and moved into a JET members meeting.

Sue Leader

©2001 InternetNZ
Last updated 7 November 2002