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

bind-3.2.

IDN Working Group                             Edmon Chung & David Leung
Internet Draft                                              Neteka Inc.
<draft-ietf-idn-dnsii-mdnr-01.txt>                        February 2001
 
 
                                     
               DNSII Multilingual Domain Name Resolution 
 
 
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 
    
   This document outlines a resolution process that forms a framework 
   for the resolution of multilingual domain names.  Additionally, a 
   tunneling mechanism utilizing additional RRs is introduced for the 
   transition to a fully multilingual capable name space. 
    
   The Internet-Draft for DNSII-MDNP was focused purely on discussing 
   the ultimate packet protocol that is being sent around the Internet 
   for multilingual domain names.  This paper complements the previous 
   paper by outlining the contemplated resolution process with the DNSII 
   protocol throughout the DNS name resolution process. 
    
   Whether the DNSII protocol is implemented exactly as specified in 
   DNSII-MDNP is less relevant, rather it is the idea of having a 
   multilingual packet identifier and the fall back process that 
   matters.  The DNSII-MDNR successfully addresses the transitional 
   issues at each node of the DNS resolution process providing a clear 
   migration path and strategy for the deployment of a multilingual 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   enabled DNS system.  It also outlines the conformance levels required 
   for basic or complete implementations for applications, resolvers and 
   name servers. 
    
    
Table of Contents 
    
   1. Introduction....................................................2 
   1.1 Terminology....................................................2 
   1.2 Multilingual Domain Name Resolution............................3 
   1.2 DNSII-MDNR.....................................................3 
   2. DNSII Proposal with respect to the DNS Layers...................3 
   3. The Resolution Process..........................................5 
   3.1 Steady State Resolution........................................5 
   3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6 
   3.2.1 Tunneling MDNP through DNSII RR..............................6 
   3.2.2 Tunneling ILET RRs...........................................8 
   3.3 Resolvers & Server-End Transitional Fallback Strategy..........9 
   3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9 
   3.3.2 Reinsertion of ILET and DNSII Identifier....................10 
   4. DNSII Conformance Levels.......................................10 
   4.1 Application Conformance Levels................................11 
   4.2 Resolver Conformance Levels...................................11 
   4.3 Authoritative Server Conformance Levels.......................11 
   5. Transition Schedule & Strategy.................................12 
   6. Summary of Discussion..........................................12 
   6.1 Client/Application Resolution Strategy........................13 
   6.2 Resolver Resolution Strategy..................................13 
   6.3 Authoritative Name Server Resolution Strategy.................13 
   7. Security Considerations........................................14 
   8. Intellectual Property Considerations...........................14 
   9. References.....................................................14 
    
    
1. Introduction 
    
   This Internet-Draft describes details of the contemplated resolution 
   process after the deployment of DNSII-MDNP, or other multilingual 
   domain name efforts containing a bit flag multilingual packet 
   identifier or otherwise InPacket identifications for that matter. 
    
   The reader is assumed to be familiar with the concepts discussed in 
   the DNSII-MDNP Internet-Draft <draft-ietf-idn-dnsii-mdnp.txt>. 
    
    
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]. 
    


  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   A number of multilingual characters are used in this document for 
   examples.  Please select your view encoding type to Big-5 
   (Traditional Chinese) for them to be displayed properly. 
    
    
    
    
1.2 Multilingual Domain Name Resolution 
    
   The original specifications for the DNS were designed to be open 
   enough for simple implementation of a multilingual naming system with 
   slight adjustments as laid out in DNSII-MDNP.  The transition and 
   especially its resolution process during migration is however a 
   tricky problem.  Several things that MUST be kept in mind is that 
   there is a initial phase, an intermediate phase and an ultimate 
   steady state phase.  DNSII-MDNP only described the ideal protocol at 
   steady state, with incorporated flexibility for transition from the 
   present to multilingual as well as again towards future unknown 
   grounds. 
    
   It is important to remember that the ultimate form SHOULD be 
   determined and then the transition scheme laid out.  While an ASCII 
   translation system might seem favorable in the short-run, it 
   effectively creates an alternative universe which is counter to the 
   spirit of the DNS.  However an ASCII translation is implemented, it 
   immediately creates a "human-multilingual" universe and a "machine-
   ASCII" universe.  This document introduces a tunneling mechanism to 
   transition the DNS from today's monolingual system, through an 8-bit 
   or 7-bit migration scheme towards a truly sustainable multilingual 
   name space, arriving at a DNSII type system. 
     
    
1.2 DNSII-MDNR 
    
   While DNSII-MDNP describes the framework for the ultimate protocol 
   format of a multilingual DNS, DNSII-MDNR will discuss how the packet 
   SHOULD be transported and interpreted throughout the DNS.  The 
   document will describe both the intended resolution process as well 
   as part of the transition strategy from the existing DNS to a DNSII 
   enabled system. 
    
    
2. DNSII Proposal with respect to the DNS Layers 
    
   The following diagram illustrates the use of DNSII-MDNP at a steady 
   state.  Section 3 will discuss the fallback strategies while Section 
   4 will talk about issues on conformance levels. 
    





  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   +---------------+ 
   |               | NamePrep: 
   |  Application  | Canonicalize in Form C/KC 
   |               | Insert DNSII Identifier    +---------------------+ 
   |               | Insert appropriate ILET    |    (Base data)      | 
   +---------------+                            +---------------------+ 
           |                                            | 
           |  DNS Packet with DNSII                     | (no standard) 
           |  Identifier & ILET                         |  RECOMMENDS 
           |                                            |  UCS-2/4 
   +---------------+                                    | 
   |   Resolver    | Canonicalize, Case Fold    +---------------------+ 
   |               | (for cache lookup) or      | Auth DNS server     | 
   +---------------+ leave as is & Resolve      | (Canonicalize,      | 
           |                                    | Case Fold & Lookup) | 
           |  Pass Along without                +---------------------+ 
           |  Altering Case or Canonicalization         | 
           |                                            | 
           |   <-----   DNS service interface  ----->   | 
   +------------------------------------------------------------------+ 
   |  DNS service                                                     | 
   |  +-----------------------+         +--------------------+        | 
   |  | Forwarding DNS server |         | Caching DNS server |        | 
   |  +-----------------------+         +--------------------+        | 
   |                                                                  | 
   |                 +-------------------------+                      | 
   |                 | Parent-zone DNS servers |                      | 
   |                 +-------------------------+                      | 
   |                                                                  | 
   |                 +-------------------------+                      | 
   |                 | Root DNS servers        |                      | 
   |                 +-------------------------+                      | 
   |                                                                  | 
   +------------------------------------------------------------------+ 
    
   Please note that at each level, the domain name is being 
   canonicalized.  This is to ensure that at the end, characters that 
   can be represented by a single code point will not be otherwise 
   compared resulting in inconsistent reply to a humanly identical name.  
   It is RECOMMENDED that applications SHOULD conduct canonicalization 
   while servers MUST.  Duplicating the process is fine because if a 
   character is already composed, it will not compose again with another 
   character. 
    
   This arrangement is very similar to the ASCII case folding 
   experienced in the DNS today.  In the original specifications, it was 
   RECOMMENDED that query sent be left as they are and case folding done 
   only at the server end.  Some application implementations however do 
   perform the case folding at the user end.  As the query arrives at 
   the server, it is still case folded. 
    


  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   Case folding for multilingual domain names should follow the existing 
   implementations for ASCII names, where the application SHOULD and the 
   server MUST. 
    
 
3. The Resolution Process 
    
   It is inevitable that at the end of the day, the entire DNS chain 
   SHOULD be updated in order for multilingual domain names to be as 
   efficiently resolved as names under the current DNS.  DNSII strives 
   to provide a schema that ultimately brings the system to a desirable 
   steady state while carefully giving considerations to all the 
   transition issues.  These include the considerations that at the 
   application end, there is already a preference and an installed base 
   of character encoding that may or may not conform to the desires of 
   the server end operations.  The use of ILET is therefore highly 
   desirable and essential. 
    
    
3.1 Steady State Resolution 
    
   At steady state, the resolution process of multilingual domain names 
   SHOULD be identical to the existing system.  Additional steps of 
   going through alphanumeric translation are unnecessary and 
   undesirable. 
    
   With DNSII, the contemplated steady state process resembles the well-
   known DNS model laid out in RFC1035. 
    
    
                   Local Host                          |    Foreign 
                                                       | 
    +---------+                   +----------+         |  +---------+ 
    |         | user queries      |          |queries  |  |         | 
    |         |(DNSII identifier  |          |         |  |         | 
    |         | ILET=UCS without  |          |         |  |         | 
    |  User   | Transformation)   |          |         |  | Foreign | 
    | Program |------------------>| Resolver |---------|->| Name    | 
    |         |                   |          |         |  | Server  | 
    |         |<------------------|          |<--------|--|         | 
    |         | user responses    |          |responses|  |         | 
    |         |                   |          |         |  |         | 
    +---------+                   +----------+         |  +---------+ 
                                    |     ^            | 
                    cache additions |     | references | 
                                    v     |            | 
                                  +----------+         | 
                                  |  cache   |         | 
                                  +----------+         | 
    
    
   Eventually, an ISO 10646 UCS without transformation is desired as the 
   common format.  The benefits of having a uniform byte length encoding 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000