[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Internet Draft DNSII Protocol
We apologize for the URL's that are not working. We sent out the e-mail
before we setup our DNS and Webserver so some of you may have negative
caching at your DNS. We are extremely sorry for this mistake. I have
included our draft in this e-mail.
Sorry for the inconvenience.
Ketan
----- Original Message -----
From: Paul Hoffman / IMC <phoffman@imc.org>
To: Ketan Patel <ketan@neteka.com>
Cc: George Rethy <rethy@neteka.com>; Ken Lee <ken@neteka.com>; David Leung
(Neteka Inc.) <david@neteka.com>; Edmon <edmon@neteka.com>;
<larry.jackson@editorialedge.com>; Marc Blanchet
<Marc.Blanchet@viagenie.qc.ca>; James Seng <jseng@pobox.org.sg>
Sent: Thursday, July 27, 2000 4:53 PM
Subject: Re: [idn] Internet Draft DNSII Protocol
> At 3:59 PM -0400 7/27/00, Ketan Patel wrote:
> >You can download our draft from the following URLs:
> >http://www.dnsii.org/DNSII-MDNP.txt or
http://www.dnsii.com/DNSII-MDNP.txt
>
> Neither of these URLs work. dnsii.org is not even registered in the
> .org. www.dnsii.com does not resolve.
>
> --Paul Hoffman, Director
> --Internet Mail Consortiu
Internet-Draft David Leung & Edmon Chung
DNSII-MDNP Neteka Inc.
July 26, 2000
Expires in 6 months
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.
Abstract
Historically, the DNS is capable of handling only names within the
basic English alphanumeric character set (plus the hyphen), yet the
standards were such elegantly and openly designed that the extension of
the DNS into a multilingual and symbols based system proves to be
possible with simple adjustments.
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.
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].
1.2 DNSII
Many of the current proposals for a multilingual domain name system
involve working around the current ANSI based DNS. So doing either
affects the integrity of the original spirit of the DNS or does not
well address the encoding conflict issues apparent in different
character encoding systems.
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 allow 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. The
conflicting character encoding schemes plus the other existing
multilingual implementations makes it almost impossible to
determine what language an incoming request is actually in. With
the DNSII flag however, the process is 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.
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 value of 0 in the ILET field SHOULD not be allowed.
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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办╰参3tld0, exactly in line with the original specifications.
Note that the first label in any query SHOULD be represented in
DNSII format to alert the destination server that it is DNSII
aware. This is specifically configured for the considerations
with CNAME, A6, DNAME and PTR records.
2.3 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.3.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 given:
a. The implementer of DNSII MAY chose to reject the request;
or
b. An ACE format domain with a "for.ref.only" suffix MAY be
returned;
or
c. A DNSII compliant server MAY return a 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.3.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.
3. 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 valuable.
Although the DNSII protocol could be implemented at any level of the
DNS, the following phased rollout is contemplated.
(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 kind
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 DNSs will begin to
migrate. This will include both the browser DNS as well as the ISP
DNSs.
(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.
4. IDN Requirements Checklist
The DNSII protocol specification is in line with most if not all of the
requirements identified by the IDN work group.
5. DNSSEC, EDNS and IPv6 Considerations
The DNSII implementation should not require any adjustments with the
DNSSEC, EDNS or IPv6 concerns.
6. 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.
7. References
[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
[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999, RFC 2671.
Authors:
Edmon Chung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
edmon@neteka.com
David Leung
Neteka Inc.
2462 Yonge St. Toronto,
Ontario, Canada M4P 2H5
david@neteka.com