draft-ietf-idn-dnsii-mdnp-02.txt

bind-3.2.

IDN Working Group                             Edmon Chung & David Leung
Internet Draft                                              Neteka Inc.
<draft-ietf-idn-dnsii-mdnp-02.txt>                        February 2001
 
 
              The DNSII Multilingual Domain Name Protocol 
 
 
STATUS OF THIS MEMO 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts.  Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by other 
   documents at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."  
    
   The reader is cautioned not to depend on the values that appear in 
   examples to be current or complete, since their purpose is primarily 
   educational.  Distribution of this memo is unlimited. 
    
   The list of current Internet-Drafts can be accessed at  
   http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.  
    
   A copy of this particular draft is also archived at 
   http://www.dnsii.org. 
    
    
Abstract 
    
   The core thinking for DNSII is that multilingual DNS requests SHOULD 
   be signaled within a DNS label whether by way of a binary tag or an 
   alphanumeric prefix, and that compatibility to legacy client 
   applications SHOULD be taken into concern alongside legacy server 
   implementations. 
    
   Besides the original specifications, four alternatives including the 
   use of EDNS are included for discussion purposes in this document. 
    
   Historically, the DNS is capable of handling only names within the 
   basic English alphanumeric character set (plus the hyphen), yet the 
   standards were so elegantly and openly designed that the extension of 
   the DNS into a multilingual and symbols based system proves to be 
   possible with simple adjustments. 
    
   These adjustments will be made on both the client side and the server 
   side. However, DNSII works on the principal that it is preferable to 
   make the transition to multilingual domain names seamless and 
  
DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
 
   transparent to the end-user. Which means initially the server SHOULD 
   take the primary responsibility for the technical implementation of 
   the changes required for a multilingual Internet. 
    
   The DNSII protocol is designed to allow the preservation of 
   interoperability, consistency and simplicity of the original DNS, 
   while being expandable and flexible for the handling of any character 
   or symbol used for the naming of an Internet domain.  DNSII intends 
   to provide a platform for the implementation of multilingual domain 
   names.   
    
Table Of Contents 
    
   1. Introduction....................................................2 
   1.1 Terminology....................................................2 
   1.2 DNSII..........................................................3 
   2. DNSII Protocol..................................................3 
   2.1 InPacket DNSII Identifier......................................3 
   2.2 InPacket Label Encoding Type (ILET)............................4 
   2.3 The Rationale for using ILET...................................5 
   2.4 Considerations for Specific Requests...........................6 
   2.4.1 PTR Records..................................................6 
   3. Alternate Implementations.......................................7 
   3.1 Restricted ILET Values.........................................7 
   3.2 Reduced ILET Bit Allocation....................................8 
   3.3 DNSII over EDNS................................................9 
   3.3.1 DNSII Identifier using EDNS..................................9 
   3.3.2 ILET using EDNS OPT RRs.....................................10 
   4. Implementation & Deployment Strategies.........................11 
   5. IDN Requirements Considerations................................12 
   6. DNSSEC, EDNS and IPv6 Considerations...........................12 
   7. Intellectual Property Considerations...........................13 
   8. References.....................................................13 
    
    
1. Introduction 
    
   This Internet-draft describes details of the DNSII Multilingual 
   Domain Name protocol. The Internet-Draft assumes that the reader is 
   familiar with the concepts discussed in the widely distributed RFCs 
   "Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names 
   Implementation and Specification" [RFC 1035]. 
    
    
1.1 Terminology 
    
   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 
   and "MAY" in this document are to be interpreted as described in RFC 
   2119 [RFC2119]. 
    
   A number of multilingual characters are used in this document for 
   examples.  Please select your view encoding type to UTF-8 for it to 
   be displayed properly. 
  
DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
 
    
1.2 DNSII 
    
   The DNSII specifications takes a radically different approach: it 
   successfully identifies the difference between original DNS and DNSII 
   packets within the labels and at the same time allows the use of 
   multiple charsets to be easily incorporated in a standardized manner.  
   It causes no harm to the current DNS because it embraces the original 
   format for DNS laid out in RFC1035, complemented with the ideas 
   incorporated in EDNS [RFC2671].  
    
    
2. DNSII Protocol 
    
   The DNSII Protocol consists mainly of two parts: the InPacket DNSII 
   Identifier and the InPacket Label Encoding Type.  In addition, there 
   are several special considerations for specific record types. 
    
    
2.1 InPacket DNSII Identifier 
    
   In the DNSII specifications, an InPacket DNSII Identifier MUST be 
   inserted before a label to signify that it contains extended 
   characters that are not supported by the current DNS. 
    
   This DNSII flag, which is the first two bits of a label, effectively 
   distinguishes a DNSII compliant request from the existing format, 
   without having to conduct a guess from a name check whether the 
   incoming packet is multilingual aware.  This is a substantial 
   improvement over character encoding schemes and multilingual 
   implementations in which it is almost impossible to determine the 
   language of an incoming request. The DNSII flag makes the process 
   clear and simple.     
    
   Currently: 
   "00"   regular label [RFC1035] 
   "11"   a redirection for DNS compression [RFC1035] 
   "01"   indicates the use of EDNS for multiple UDP packets [RFC2671] 
    
   DNSII calls for the use of the bit sequence "10" to identify that the 
   querying node is DNSII aware.  This will mean that all the possible 
   variations at top two label bits will be used.  Therefore, in 
   consideration, following two bits MUST be reserved for future 
   flagging use.  The 2 bits SHOULD be arbitrarily set to "00".  This 
   effectively opens up 3 more possible implementations for future 
   enhancements. 
    
   The motivation for this approach is the belief there should be no 
   ambiguity in name resolution.  Any name that the client wishes to 
   resolve, should resolve, regardless of the client side-encoding 
   scheme. 
    
    
  
DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
 
2.2 InPacket Label Encoding Type (ILET) 
    
   Immediately following the 2 assigned DNSII flag and the 2 reserved 
   bits are 12 bits assigned to determine the InPacket Label Encoding 
   Type (ILET). 
    
   The ILET is a 12-bit number that is used to determine the encoding 
   scheme used by the characters of the label.  The MIBenum numbers 
   [RFC1700] SHOULD be used in this field.  The allocation of 12 bits 
   aligns perfectly with the MIBenum specification, of which the value 
   goes up to over 2200.  With 12 bits, the total possible values would 
   be 4096 (with 11 bits, the largest value that can be represented is 
   only 2047, slightly short of the specification).  The reason for the 
   adoption of MIBenum is to make use of the existing list of encoding 
   numbering schemes rather than re-inventing the wheel. 
    
   The value in the ILET field SHOULD only be allowed for the valid 
   encoding schemes defined in the MIBenum list.  After identifying the 
   encoding type, the regular count-label scheme of the DNS resumes.  
   The resulting label should look like this: 
    
                        1 1 1 1 1 1   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
   +---+---+-------+---------------+ 
   |1 0| z |         ILET          | 
   +---------------+---------------+ 
   |     COUNT     | characters... | 
   +---------------+---------------+ 
    
   To minimize the size of a DNS packet, if the entire label is 
   constituted in characters only from the ANSI table, the DNS label 
   will appear identical to current implementations.  The first two bits 
   will remain "00". 
   For example, using the DNSII format the label for "dns" MAY be 
   represented as: 
    
     0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+  
   | 1  0| 0  0| 0  0  0  0  0  0  0  0  0  0  1  1|  MIBenum 3 = ANSI 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
   |           3           |     6           4     |  "d"=64 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
   |     6           E     |     7           3     |  "n"=6E  "s"=73 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
    
   Or, the same domain label "dns" MAY also be represented as: 
    
     0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
   |           3           |           d           | 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
   |           n           |           s           | 
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
  
Chung & Leung		                                        [Page 4]
DNSII-MDNP        Multilingual Domain Name Protocol         August 2000  
 
   With a multilingual domain name ns.厲枀伸圑﹪礃.tld as an example: 
    
                        1 1 1 1 1 1                     1 1 1 1 1 1   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
   +---------------------------------------------------------------+ 
   |1 0| z |        ANSI=3         |       2       |       n       | 
   +---------------------------------------------------------------+ 
   |       s       |1 0|0 0|       UCS-2=1000      |       4       | 
   +---------------------------------------------------------------+ 
   |          厲