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


   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
   The list of Internet-Draft Shadow Directories can be accessed at

   A copy of this particular draft is also archived at


   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

   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

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


   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.

   "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

   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

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       |
   |          …––   (U+57DF)        |          …Éì    (U+540D)         |
   |          ‡þ©   (U+7CFB)        |          ‡´˜    (U+7D71)         |
   |0 0|     3     |       t       |       l       |       d       |
   |       0       |
   From the above example, we can see that the DNSII format is used for
   the first label "ns", as well as for the second label, which is in
   Chinese (the MIBenum for UCS-2 or ISO 10646 [Unicode] is 1000).  The
   third label "tld" however uses the current format.

   In any case, the count-label-count-label mechanism is largely
   preserved.  Especially in the case of extended characters where in
   other proposals, the "count" no longer represents the character
   count.  In the above example, the domain is still represented as 2ns4
   …––…Éì‡þ©‡´˜3t ld0, exactly in line with the original specifications.

   Note that the first label in any query could be represented in DNSII
   format to alert the destination server that it is DNSII aware.  This
   is not required but is specifically configured for the considerations
   with CNAME, A6, DNAME and PTR records.

   This approach is used to ensure that there is no confusion about the
   encoding format of the label.  ILET allows the capability of
   employing all existing encoding schemes (UTF-7, UTF-8, ISO 10646
   [UCS-2], ISO 10646 [UCS-4]).  ILET also allows the flexibility of
   employing future encoding schemes.

2.3 The Rationale for using ILET

   Besides being able to preserve the count-label-count-label structure,
   which in itself is actually a very important part because of the
   problematic non-uniform byte encoding schemes, the use of ILET aligns
   perfectly with previous IETF specifications as well as beneficial for
   tricky case folding and canonicalization issues.

   We know that all protocols MUST identify, for all character data,
   which charset is in use [RFC2277], therefore it is necessary to
   specify whatever encoding scheme, whether it be UTF-8, UTF-7, 16-bit
   UCS-2 or ISO 8859 that is being used.  In essence, we understand that

Chung & Leung                                                   [Page 5]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   it is paramount that a charset be clearly identified, especially in
   situation like the DNS where no direct communication is established.

   At times and in specific cases, language information may be required
   to achieve a particular level of quality for the purpose of
   displaying a text stream.  For example, UTF-8 encoded Han may require
   transmission of a language tag to select the specific glyphs to be
   displayed at a particular level of quality.

   Note that information other than language may be used to achieve the
   required level of quality in a display process.  In particular, a
   font tag is sufficient to produce identical results.  However, the
   association of a language with a specific block of text has
   usefulness far beyond its use in display.  In particular, as the
   amount of information available in multiple languages on the World
   Wide Web grows, it becomes critical to specify which language is in
   use in particular documents, to assist automatic indexing and
   retrieval of relevant documents._ [RFC2130]
   In effect, this means for different languages, it is beneficial to be
   able to identify the language in order to perform specific functions
   to the characters, including case folding.  With ILET, the local
   encoding scheme could be used and with them there are well defined
   folding methods.  Therefore, the use of ILET enables an optimized
   folding mechanism brought about by the preservation of local encoding
   schemes, which is otherwise very difficult or virtually impossible to
   do if only UTF-8 is used.

   For the DNS however, a language tag is less feasible because if a
   name is consisted of multiple languages, it would be very difficult
   for tagging to be performed.  The possibility of having multiple
   languages is very sound, and is used frequently as trademarks around
   the world.  For example the famous Toys"ϯ"Us name, uses a character
   from the Cyrillic language set.

2.4 Considerations for Specific Requests

   For certain requests, an ANSI only name could result in a
   multilingual domain as an answer.  These include PTR, CNAME, A6 and
   DNAME requests.  Special considerations are made within the DNSII
   protocol to make sure that non-DNSII aware servers will not be fed
   with a DNSII format packet.

2.4.1 PTR Records

   For all PTR requests, the first label of the query MUST use DNSII
   format to alert the destination server.  Upon which, a DNSII packet
   will be replied should the name contain extended characters.

   If the DNSII format is not used, and the PTR record stumbles upon a
   multilingual domain name, one of the following responses SHOULD be

Chung & Leung                                                   [Page 6]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   a. The implementer of DNSII MAY chose to reject the request;


   b. An ACE format domain with a "for.ref.only" suffix MAY be returned;


   c. A DNSII compliant server MAY return an 8-bit format of the
   requested domain.

   Since the PTR record is usually used for display purposes only, the
   rejection (the IP address will then be used) or ACE format is
   acceptable.  If the response is however used for further resolution,
   an ACE format MUST not be used.

2.4.2 CNAME, A6 & DNAME

   For queries concerning the record types CNAME, A6 or DNAME, a DNSII
   aware server should first check to see if the incoming request is
   DNSII compliant (flagged by the "10" bits in the first label):

   If so, and the domain to be returned includes extended characters,
   the response SHOULD be in DNSII format.

   If not, any multilingual domains returned should be in an 8 bit form.

   For the above record types it is strongly RECOMMENDED not to
   associate an alphanumeric label to a multilingual label as the
   RDATA.  However, it is permissible to associate a multilingual label
   with an alphanumeric label as the RDATA.

3. Alternate Implementations

   The DNSII-MDNP is intended to be a framework for the implementation
   of multilingual domain names.  While the core concepts and the design
   principles remain consistent, it is possible to contemplate
   alternative implementations.  The four alternatives introduced here
   include the arbitrary restriction of ILET values, the reduction of
   ILET bit allocation for reflecting ISO 10646 transformations only,
   and finally two implementations using DNSII over EDNS.

3.1 Restricted ILET Values

   One possible implementation guideline is for the ILET to be
   restricted to values only representing ISO 10646 transformations
   including UCS-2, UCS-4, UTF-7, UTF-8, UTF-16 and other as they become
   available and included as a standard MIBenum.

Chung & Leung                                                   [Page 7]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   Although this takes away some of the benefits of keeping the local
   encoding scheme which includes the issues of case folding,
   canonicalization and other related concerns, it creates a system that
   on one hand contains only encoding schemes from ISO 10646, but on the
   other hand still provides the flexibility of deploying new encoding
   schemes that stem from ISO 10646, such as the 32-bit format that is
   due to be used soon.

   We understand it is specified that in protocols, which up to now have
   used US-ASCII only, UTF-8 forms a simple upgrade path; however, its
   use should be negotiated either by negotiating a protocol version or
   by negotiating charset usage, and a fallback to UTF-7 MUST be
   available. [RFC2130]  With DNSII, the required fallback to UTF-7
   could easily be done by setting the ILET value to reflect UTF-7.

3.2 Reduced ILET Bit Allocation

   Furthering the restriction of the ILET to ISO 10646 transformations
   only, the ILET bit allocations could also be reduced from 12 bit to 5
   bit.  This successfully creates a total of 32 possible values.  The
   reserved bits are also reduced to one.

                        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... |

   For example, the label "…––…Éì‡þ©‡´˜" will now be reflected in DNS packets
   in the following form:

                        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| ILET=1  |       4       |          …––   (U+57DF)        |
   |          …Éì   (U+540D)         |         ‡þ©    (U+7CFB)         |
   |          ‡´˜   (U+7D71)         |

   To start off with, the ILET values MAY be determined as follows:

   0 = reserved for ANSI               1 = UTF-7
   2 = UCS-2                           3 = UTF-8
   4 = UCS-4                           5 = UTF-16
   6 = 6 octets per character          7 = 7 octets per character
   8 = UCS-8 (8 octets per character)  9 = UTF-31

Chung & Leung                                                   [Page 8]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   The ILET number will be the number of octets that should be read each
   time, with exceptions at 0,3,5,9 or any number that is just after a
   full UCS.  ILET=3 corresponds to UTF8 because ILET=2 = UCS2 and UTF-8
   is a compatibility transformation for UCS-2 (in 16bit) in 8bit.  A
   possible future expansion to UCS-8 is also included to make the
   schema truly future prove.

   This arrangement opens up opportunity and versatility of the use of
   private schemes that make use of odd byte length characters or
   symbols such as 6, 7 or even 18octet representations without the need
   for the DNS to update or adjust to, while maintaining the integrity
   and unique nature of domain names.

3.3 DNSII over EDNS

   While DNSII and EDNS could coexist, it is possible to implement the
   DNSII concept onto an EDNS based platform.  It is however preferable
   to use both EDNS and the DNSII scheme together as described in
   Section 6, because EDNS(0) compliant servers may have trouble when
   the label count exceeds the value of 63 (and smaller than 127)
   because then, the EDNS mechanism MAY be reiterated.

   Nevertheless, it is possible to utilize EDNS to act as a DNSII
   Identifier.  The short-comings and pit-falls are however further laid
   in another draft DNSII-EDNS.

3.3.1 DNSII Identifier using EDNS

   EDNS could simply be used in place of the DNSII Identifier.  Assuming
   that the reduced ILET values introduced in Section 3.2 is used, the
   ILET will fit nicely into one octet immediately following the ELT
   portion.  The resulting representation for the domain "host.…––…Éì‡þ©‡´˜
   .tld" would be as follows:

                          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
   20|0 0|      4    |       h       |       o       |       s       |
     |       t       |0 1|0 0 0 0 1 0| ILET=UCS-2=2  |       4       |
     |          …––   (U+57DF)        |          …Éì    (U+540D)         |
     |          ‡þ©   (U+7CFB)        |          ‡´˜    (U+7D71)         |
     |0 0|     3     |       t       |       l       |       d       |
     |       0       |

Chung & Leung                                                   [Page 9]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   The OPT RR could be used not only for version control but also as a
   notification for the destination server on the level of conformance
   of the inquirer.  This is especially beneficial when considering the
   issues raised in Section 2.4 where ANSI only requests my result in a
   multilingual response.

   Proposed identifications within the OPT RR (used in this document for
   discussion purposes):
   ELT = 0b000010
   OPTION-DATA = conformance level (defined in DNSII-MDNR Section 4)
                 Plus other information if required

   The conformance level SHOULD be included in the first octet of the
   OPTION-DATA field and reflect the value corresponding to:

   BASIC conformance = 1
   INTERMEDIATE conformance = 2
   FULL conformance = 3

   A resulting DNSII OPT RR from a fully compliant inquirer SHOULD be in
   the form:

                          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
     |    NAME=0     |       TYPE = OPT = 41         | Sender's UDP  |
     | Payload Size  |EXTENDED-RCODE=0|EDNS-VERSION=2|       z       |
     |       z       |         RDLENGTH = 5          | OPTION-CODE = |
     |    IDN = 1    |      OPTION-LENGTH = 1        | Conformance=3 |

3.3.2 ILET using EDNS OPT RRs

   Instead of using the OPT RR only as a notification of DNSII
   awareness, it utilized to indicate the type of encoding that is being
   used in the labels.  In other words, the ILET value could be included
   in the OPT RR instead of within the label.

   The ILET value will be included right after the conformance level
   octet in the OPTION-DATA field within the OPT RR RDATA.

Chung & Leung                                                  [Page 10]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   The resulting QNAME labels and OPT RR for the domain "www.…––…Éì‡þ©‡´˜
   .tld" from a fully compliant inquirer sending the name in UCS-2
   would become:

                          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
     |0 0|     3     |       w       |       w       |       w       |
     |0 1|0 0 0 0 1 0|       4       |          …––   (U+57DF)        |
     |          …Éì   (U+540D)        |          ‡þ©    (U+7CFB)        |
     |          ‡´˜   (U+7D71)        |0 0|     3     |       t       |
     |       l       |       d       |       0       |

   (OPT RR containing ILET information)
     :                                                               :
     /                                                               /
     |    NAME=0     |       TYPE = OPT = 41         | Sender's UDP  |
     | Payload Size  |EXTENDED RCODE=0|EDNS-VERSION=2|       z       |
     |       z       |         RDLENGTH = 9          | OPTION-CODE = |
     |    IDN = 1    |      OPTION-LENGTH = 4        | Conformance=3 |
     |       1       |       0       |       0       |       0       |

   Note that instead of allocating only 12 bits for the ILET, the
   MIBenum value is expressed over 4 octets with each octet carrying a
   numeric value.  Since UCS-2 is used and the MIBenum value for UCS-2 =
   1000, the 4 octets corresponds to the values 1, 0, 0, 0 respectively.

   If the reduced ILET values are used, only 1 octet is required to
   reflect the encoding scheme being used.

4. Implementation & Deployment Strategies

   The first step in any multilingual domain name implementation should
   be to encourage an 8-bit clean approach to DNS.  However, even when
   the system is 8-bit clean the problem with conflicting characters
   still exists.  This is where the DNSII protocol becomes most

   Although the DNSII protocol could be implemented at any level of the
   DNS, the following phased rollout is contemplated.

Chung & Leung                                                  [Page 11]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   (1) Registry Level - The most meaningful starting point for
   deployment would be at the registry level since this creates the
   demand from the end users to use multilingual and extended character
   domain names for Second Level Domains.

   (2) Host Level - At the same time, registrants of the new extended
   domain names could start to implement DNSII to host these special
   kinds of domain names.  All other hosts that do not wish to use
   extended characters do not have to migrate to the DNSII.

   (3) Client Level - Once the multilingual aspect and the DNSII
   specifications become mainstream, the user level resolvers will begin
   to migrate.  This will include both the client resolver as well as
   the ISP's DNS.

   (4) Root Level - Eventually, as the DNSII is proven to be stable and
   beneficial for the Internet at large, it could be used in the Root
   Level so that new multilingual TLDs could be created.

5. IDN Requirements Considerations

   The DNSII protocol specification is in line with most if not all of
   the requirements identified by the IDN work group.

6. DNSSEC, EDNS and IPv6 Considerations

   The use of DNSII should not require any adjustments with the
   implementation of DNSSEC, EDNS or IPv6.  EDNS as well as compression
   in fact will be done exactly the same as the existing system.
   For example, the domain host.dns.…––…Éì‡þ©‡´˜.tld running with EDNS as
   well as compression after host will look as follows:

                          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
   20|0 1|    ELT    |0 0|     3     |       d       |       n       |
     |       s       |1 0|0 0|       UCS-2=1000      |       4       |
     |          …––   (U+57DF)        |          …Éì    (U+540D)         |
     |          ‡þ©   (U+7CFB)        |          ‡´˜    (U+7D71)         |
     |0 0|     3     |       t       |       l       |       d       |
     |       0       |

Chung & Leung                                                  [Page 12]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

     :                                                               :
     /                                                               /
     |0 0|     4     |       h       |       o       |       s       |
     |       t       |1 1|           21              |

7. 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

   Other DNSII related documents and discussions could be found at

8. References

   [DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name
              Resolution_, 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

   [RFC2130]  C. Weider, et al. _The Report of the IAB Character Set
              Workshop held 29 February - 1 March, 1996_ RFC 2130,
              April 1997

Chung & Leung                                                  [Page 13]

DNSII-MDNP        Multilingual Domain Name Protocol         August 2000

   [RFC2277]  H. Alvestrand, _IETF Policy on Character Sets and
              Languages_ RFC 2277, January 1998

   [RFC2671]  Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
              August 1999, RFC 2671.


   Edmon Chung
   Neteka Inc.
   2462 Yonge St. Toronto,
   Ontario, Canada M4P 2H5

   David Leung
   Neteka Inc.
   2462 Yonge St. Toronto,
   Ontario, Canada M4P 2H5

Chung & Leung                                                  [Page 14]