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

bind-3.2.

    
    
4.1 Application Conformance Levels 
    
   The BASIC compliancy for applications would be to remove validity 
   checks for domain names.  The resolution process will determine a 
   non-existing domain name, so there really is no need to prevent a DNS 
   packet with multilingual labels to be sent through the wires. 
    
   The INTERMEDIATE compliancy for applications involves the insertion 
   of the DNSII identifier as well as the ILET according to the local 
   inputting and screen scheme.  If a user is using a JIS format scheme, 
   it should set the ILET to reflect it being used.  At the same time, 
   the tunneling mechanism discussed in Section 3.2 MUST also be in 
   place. 
    
   FULLY compliant applications will send all DNS packets with the DNSII 
   identifier and the ILET set to UCS-2/4. The fallback scheme discussed 
   in Section 3.2 MUST also be in place.  InZone DNSII mechanisms SHOULD 
   also be available to deal with local encoding exceptions. 
    
    
4.2 Resolver Conformance Levels 
    
   The BASIC compliancy for resolvers would be to allow an 8-bit clean 
   approach to name resolution.  Also, it should be made sure that the 
   additional DNSII RR (TXT) will not be truncated during resolution. 
    
   The INTERMEDIATE compliant resolvers MUST understand how to process 
   the DNSII identifier as well as not reject the ILET.  Interpretation 
   of the name is not required so it is NOT necessary for the resolvers 
   to be able to map all or any of the ILET values (with the alternative 
   approach in DNSII-MDNP, the ILET value corresponds to the byte length 
   of the characters contained in the label, which makes the count 
   workable even if the ILET value is not known by the resolver).  In 
   this scenario caching will be for exact comparison only (label to 
   label with ILET intact).  The important criteria is for the resolver 
   to be able to pass along the DNS query to the corresponding 
   authoritative server and obtain a correct response. 
    
   FULLY compliant resolvers will be able to process the DNSII identifer 
   and know all the ILET values for full function name mapping.  Cache 
   name lookup will be fully enabled and inquiry fallback mechanism 
   discussed in Section 3.2.2 SHOULD be performed in the event of 
   encountering a non-compliant server. 
    
    
4.3 Authoritative Server Conformance Levels 
    
   Authoritative servers MUST be fully compliant before attempting to 
   serve multilingual sub-domains under its authoritative zone.  They 
   should however prepare for the transition towards a multilingual name 
   space even if they do not intend to deploy it right away. 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
    
   The BASIC compliancy for authoritative name servers is to allow an 8-
   bit clean approach towards sub-domains that are not directly under 
   its authority (i.e. sub-sub-domains). 
    
   The INTERMEDIATE compliant name server will be able to process the 
   DNSII identifier and ILET without rejecting the query.  The 
   authoritative zone as well as its direct sub-domains however SHOULD 
   not include the use of the DNSII flags because ILET values are not 
   understood at this compliancy level. 
    
   FULLY compliant name servers will be able to handle DNSII compliant 
   label formats at its sub-domain levels.  That is, fully compliant 
   root servers will be able to serve multilingual TLDs, fully compliant 
   TLD servers will be able to serve multilingual SLDs, etc. 
    
    
5. Transition Schedule & Strategy 
    
   DNSII is designed to allow a gradual adoption of multilingual domain 
   names on the Internet.  The transition strategy is therefore geared 
   to be demand-pull instead of a technology-push incentive.  However, 
   to provide a platform for a demand-pull approach, it is required for 
   operators to first safeguard their system.  The simple approach as 
   laid out in Section 4 is to propose that servers take a 8-bit clean 
   approach on name resolution. 
    
   As discussed in DNSII-MDNP, it is reasonable for the deployment of 
   DNSII-MDNP at the registry level first to draw demand for the service 
   and let the host level DNSs with multilingual names to begin 
   migration first.  DNS operators around the world should however 
   prepare for the transition and begin the deployment of DNSII 
   depending on their interest in serving multilingual domain names, 
   according to the conformance levels laid out in Section 4, beginning 
   from BASIC compliancy for operators that are least interested to a 
   FULLY compliant server for operators who wishes to provide 
   multilingual capabilities for their users. 
    
   The root servers could easily be adjusted to be a BASIC compliant 
   authoritative name server.  Once the demand is proven and the 
   stability of the system tested, they too could transition to fully 
   compliant authoritative servers so that multilingual TLDs could be 
   rolled out. 
    
    
6. Summary of Discussion 
    
   This document introduces the contemplated transition and steady state 
   resolution process for multilingual domain names with a DNSII 
   compliant format.  Two tunneling mechanisms using the TXT RR was 
   introduced for the preservation of information during transitional 
   resolution. 
    
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
6.1 Client/Application Resolution Strategy 
    
   Send Query in DNSII format 
   IF RCODE = Format Error 
        THEN send query in UTF-8/Local Encoding AND append DNSII RR 
        IF RCODE = Format Error 
             THEN send Query in ASCII with _-for-tunneling-only-_ label 
             AND append DNSII RR 
             AND check for DNSII ANS RR in response 
        ELSE proceed and check for DNSII ANS RR in response 
   ELSE proceed as usual 
    
    
6.2 Resolver Resolution Strategy 
    
   (*)IF incoming request is in pure DNSII format 
        THEN resolve according to ILET in cache and by recursive lookup 
        IF encounter RCODE = Format Error 
             THEN send query in UTF-8 AND append DNSII RR 
             IF RCODE = Format Error 
                  THEN send query in ASCII with _-for-tunneling-only-_  
                       label 
                  AND append DNSII RR 
                  AND check for DNSII ANS RR in response 
             ELSE proceed and check for DNSII ANS RR in response 
        ELSE proceed as usual with pure DNSII Format (*) 
        AND respond in pure DNSII format 
   ELSE IF incoming request has tunneled MDNP information 
        THEN resolve using the information in the appended DNSII RR 
             Reset Query using DNSII Format and go through (*) 
        AND convert back to tunneling format before responding to query 
             With DNSII ANS RR appended to response 
        AND set TTL for regular RRs in the Answer field to be = 0 
   ElSE IF incoming request is in the original "00" label format 
        AND no tunneled information is included 
        AND the label contains characters beyond A-z, 0-9 or "-" 
        THEN force convert all labels to UTF-8 
        AND query using DNSII Format and go through (*) 
   ELSE proceed as usual (existing ASCII based names) 
    
    
6.3 Authoritative Name Server Resolution Strategy 
    
   IF incoming request is in pure DNSII format 
        THEN resolve according to ILET 
        AND respond in pure DNSII format 
   ELSE IF incoming request has tunneled MDNP information 
        THEN resolve using the information in the appended DNSII RR 
        AND convert back to tunneling format before responding to query 
             With DNSII ANS RR appended to response 
        AND set TTL for regular RRs in the Answer field to be = 0 
   ELSE use InZone DNSII mechanisms AND use 8-bit clean approach 
    
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
7. Security Considerations 
    
   DNSII RRs will be secured through transaction authentication, while 
   DNSII ANS RRs could have their own SIG RRs.  In general, the DNSII-
   MDNR should not constitute any extra burden on DNS security. 
    
    
8. Intellectual Property Considerations 
    
   It is the intention of Neteka to submit the DNSII protocol and other 
   elements of the multilingual domain name server software to IETF for 
   review, comment or standardization. 
    
   Neteka Inc. has applied for one or more patents on the technology 
   related to multilingual domain name server software and multilingual 
   email server software suite.  If a standard is adopted by IETF and 
   any patents are issued to Neteka with claims that are necessary for 
   practicing the standard, any party will be able to obtain the right 
   to implement, use and distribute the technology or works when 
   implementing, using or distributing technology based upon the 
   specific specifications under fair, reasonable and non-discriminatory 
   terms. 
    
   Other DNSII related documents and discussions could be found at 
   http://www.dnsii.org. 
    
9. References 
 
   [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name 
              Protocol", August 2000 
    
   [RFC1700]   J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 
              1700, October 1994. 
     
   [ISO10646] ISO/IEC 10646-1:2000. International Standard -- 
              Information technology -- Universal Multiple-Octet Coded 
              Character Set (UCS) 
    
   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and  
              Facilities," STD 13, RFC 1034, USC/ISI, November 1987 
       
   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and  
              Specification," STD 13, RFC 1035, USC/ISI, November  
              1987 
    
   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate  
              Requirement Levels," RFC 2119, March 1997 
    
    
    
    
    
    
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   Authors: 
    
   Edmon Chung 
   Neteka Inc. 
   2462 Yonge St. Toronto, 
   Ontario, Canada M4P 2H5 
   [e-mail] 
    
   David Leung 
   Neteka Inc. 
   2462 Yonge St. Toronto, 
   Ontario, Canada M4P 2H5 
   [e-mail]