The following document is KRNIC position paper to be presented at Adelaide meeting. I hope that this paper can be copied and distributed to the people attending the Adelaide meeting and also included in the CD. Thanks. -------------------- idn\adl-pos1 Suggestions regarding IDN requirements (ver. 2000.03.18) Source: KRNIC-Hangul Name WG Date: 2000.03.18 Status: KRNIC position E-mail: gimgs@hangeul.cs.pusan.ac.kr 1. code: We suggest that the code for IDN be ISO/IEC 10646 (=Unicode), possibly with encoding/transformation. 2. encoding ---------------------------------- | user interface program [code1] | ---------------------------------- | code12 ---------------------------------- | resolver (client) [code2] | ---------------------------------- | code23 ---------------------------------- | name server [code3] | ---------------------------------- 2.1 Code1 could be either a local code or some other code. 2.2 If encoding is to be applied, then we should consider where this encoding should be done. We can think of three possibilities: a) always at client; b) always at name server; c) either at client or at name server In case of c), we should check whether an ambiguity occurs. If ambiguity should occur, then case c) cannot be adopted. 2.3 We need to consider point 2.2 in case of caching server too. 2.4 If normalization and/or canonicalization is to be applied, we should also consider where (i.e., at client, at server, or at server or client) they should be done. 3. Process to finalize IDN requirement docuent We propose that we refine the requirement document by taking the following stpes: a) itemize and number each requirement in the requirement document; b) evaluate each implementation proposal againt the itemized requirements (evaluation can be done by those who made up the proposals or other people); c) check whether each requirement is necessary, desirable, or practical; d) if necessary, modify requirements and go to step a); otherwise stop. 4. whether to adopt short- or mid-range solution for IDN? We can think of three different solutions: a) short-range solution: 7-bit with some encoding; b) mid-range solution: e.g., 8-bit/UTF-8 c) long-range solution: UCS without any transofrmation 4.1 We should consider whether we will adopt short-range solution, mid-range solution, or both short- and mid-range solutions. 4.2 We should carefully evaluate the side effects of using 8-bit. 5. We should consider whether or not to create new TLDs. For example, we could probably put all internationalized domain names under ccTLDs. 6. We should investigate the possibility of using CNAME and/or DNAME to support internationalized domain names. 7. root server management structure: Tree or Forest? Due to technical reasons, we will inevitably have to adopt a tree and set up a root server for IDN. However, it does not necessarily mean that administration and registration of IDNs will be centrally governed by the agent running the root server. Administaration and registration could be distributed to NIC in each country. 8. Comments about IDN requirement document. 8.1 In the following portion, since the title of subsec. 3.5 is "preferred name syntax", we propose that the statement be rewritten without the word "legal". : "IDN" is used in this document as an abbreviation for "internationalized : domain name". This is defined as a domain name that contains one or more : characters that are outside the set of characters specified as legal : characters for domain names in [RFC1034] Section 3.5. 8.2 The document says that UTF-8 and ISO-2022 are CES and that a charset is a combination of one or more CCS with a CES. However, UTF-8, EUC-KR, ISO-2022-KR are registered MIME charset names. Then UTF-8 is charset and also CES, causing confusion. We propose that this portion be improved. 8.3 We suggest that we check whether the following requirements are necessary and/or reasonable. : A caching server must not return data in response to a query that would : not have been returned if the same query had been presented to an : authoritative server. This applies fully for the cases when: : - The caching server does not know about IDN : - The caching server implements the whole specification : - The caching server implements a legal subset of the specification 8.4 We suggest that we rewrite the folliwng portion to clarify whether we need to support two representations - encoded and ASCII-only - during a transition period. : A fall-back strategy or mechanism based upon ASCII may be needed during : a transition period during deployment and adoption of IDN. Therefore, : if an encoding is not mapped into ASCII, then there should be an ASCII- : only representation compatible with the current DNS and there should be : a way for a program to find the ASCII-only representation for IDN. 8.5 The statements before and after "In other words" do not seem to imply the same meaning. CES could map ASCII characters to some strange values, which do not depend on the other characters in the string. : CES(s) chosen should not encode ASCII characters differently depending : on the other characters in the string. In other words, ASCII : character should remain as specified in [US-ASCII]. We could rewrite as follows: After applying CES(s), ASCII character should remain as specified in [US-ASCII]. 8.6 In the following statement, the criteria for "existing CES" does not seem to be clear. We propose that we clarify this statement. : The protocol must not invent a new CCS for the purpose of IDN only : and should use existing CES. 8.7 The following portion could be improved. It does not seem clear whether we should fold U+0049 to U+0049, U+0131, or U+0049/U+0131. : Case folding must not be locale dependent. For example, Latin capital : letter I (U+0049) case folded to lower case in the Turkish context will : become Latin small letter dotless I (U+0131). But in the English : context, it will become Latin small letter I (U+0069). 8.8 We suggest that, in the following portion, the first statement be deleted. : If the protocol specifies a canonicalization algorithm, a caching : server should perform correctly regardless of how much (or how little) : of that algorithm it has implemented. [1 request to remove] : If the protocol requires a canonicalization algorithm, all requests : sent to a caching server must already be in the canonical form. 8.9 In the following portion, "centralized administration" does not seem clear. If we are to create new TLDs, somebody must take care of centralized administration of these new TLDs. We suggest that we clarify this poriton. : The protocol should add no new centralized administration for the DNS. : A domain administrator should be able to create internationalized names : as easily as adding current domain names. 8.10 We suggest that we explain the basic difference between canonicalization and normalization. 8.11 We suggest that we include some reference about signed/unsigned zone files and DNSSEC signing. 8.12 In the following poriton, the terms internationalized host name and internationalzed domain name are used without being defined. We could add their definitions. : Specifically, the mapping of : internationalized host names to and from IP addresses must have the : same characteristics as the mapping of today's host names. : Specifying requirements for internationalized domain names does not : itself raise any new security issues.