draft-ietf-idn-requirements-01.txt   draft-ietf-idn-requirements-02.txt 
IETF IDN Working Group James Seng IETF IDN Working Group Editors Zita Wenzel, James Seng
Internet Draft draft-ietf-idn-requirements-01.txt Internet Draft draft-ietf-idn-requirements-02.txt
Requirements of Internationalized Domain Names Requirements of Internationalized Domain Names
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
skipping to change at line 37 skipping to change at page 10, line ?
Abstract Abstract
This document describes the requirement for encoding international This document describes the requirement for encoding international
characters into DNS names and records. This document is guidance for characters into DNS names and records. This document is guidance for
developing protocols for internationalized domain names. developing protocols for internationalized domain names.
1. Introduction 1. Introduction
At present, the encoding of Internet domain names is restricted to a At present, the encoding of Internet domain names is restricted to a
subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
other text based items on the Internet have already been other text based items on the Internet have already been at least
internationalized. It is important for domain names to be similarly partially internationalized. It is important for domain names to be
internationalized. similarly internationalized or for an equivalent solution to be found.
This document assumes that the most effective solution involves putting
non-ASCII names inside some parts of the overall DNS system.
This document is being discussed on the "idn" mailing list. To join the This document is being discussed on the "idn" mailing list. To join the
list, send a message to <majordomo@ops.ietf.org> with the words list, send a message to <majordomo@ops.ietf.org> with the words
"subscribe idn" in the body of the message. Archives of the mailing "subscribe idn" in the body of the message. Archives of the mailing
list can also be found at ftp://ops.ietf.org/pub/lists/idn*. list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
1.1 Definitions and Conventions 1.1 Definitions and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
"IDN" is used in this document as an abbreviation for "internationalized Characters mentioned in this document are identified by their position
domain name". This is defined as a domain name that contains one or more
characters that are outside the set of characters specified as legal
Expires 10th of March 2000 [Page 1]
characters for domain names in [RFC1034] Section 3.5 and [RFC1123].
It is important to note the difference between domain name and host
name. Current domain names has no restriction on what is legal
character (8bit). The only restrictions are the total and label
lengths. Host name on the other hand are restricted to alphanumeric
and '-' case insensitive with "." only allowed between labels.
A master server for a zone holds the main copy of that zone. This copy Expires 12th of October 2000 [Page 1]
is sometimes stored in a zone file. A slave server for a zone holds a
complete copy of the records for that zone. A caching server holds
temporary copies of DNS records; it uses records to answer queries
about domain names. Further explanation of these terms can be found in
[RFC1034] and [RFC1996].
Characters mentioned in this document are identified by their position in the Unicode [UNICODE] character set. The notation U+12AB, for
in the Unicode character set. The notation U+12AB, for example, example, indicates the character at position 12AB (hexadecimal) in the
indicates the character at position 12AB (hexadecimal) in the Unicode Unicode character set. Note that the use of this notation is not an
character set. Note that the use of this notation is not an indication indication of a requirement to use Unicode.
of a requirement to use Unicode.
Examples quoted in this document should be considered as a method to Examples quoted in this document should be considered as a method to
further explain the meanings and principles adopted by the document. It further explain the meanings and principles adopted by the document. It
is not a requirement for the protocol to satisfy the examples. is not a requirement for the protocol to satisfy the examples.
A character is a member of a set of elements used for organization, A character is a member of a set of elements used for organization,
control, or representation of data. control, or representation of data.
A coded character is a character with its coded representation. A coded character is a character with its coded representation.
A coded character set ("CCS") is a set of unambiguous rules that A coded character set ("CCS") is a set of unambiguous rules that
establishes a character set and the relationship between the characters establishes a character set and the relationship between the characters
of the set and their coded representation. of the set and their coded representation.
A graphic character or glyph is a character, other than a control A graphic character or glyph is a character, other than a control
function, that has a visual representation normally handwritten, function, that has a visual representation normally handwritten,
printed, or displayed. printed, or displayed.
A character encoding scheme or "CES" is a mapping from one or more A character encoding scheme or "CES" is a mapping from one or more
coded character sets to a set of octets. Some CESs are associated with coded character sets to a set of octets. Some CESs are associated with
a single CCS; for example, UTF-8 applies only to ISO 10646. Other CESs, a single CCS; for example, UTF-8 [RFC2279] applies only to ISO 10646.
such as ISO 2022, are associated with many CCSs. Other CESs, such as ISO 2022, are associated with many CCSs.
A charset is a method of mapping a sequence of octets to a sequence of A charset is a method of mapping a sequence of octets to a sequence of
abstract characters. A charset is, in effect, a combination of one or abstract characters. A charset is, in effect, a combination of one or
more CCS with a CES. Charset names are registered by the IANA according more CCS with a CES. Charset names are registered by the IANA according
to procedures documented in RFC 2278. to procedures documented in RFC 2278.
A language is a way that humans interact. In written form, a language A language is a way that humans interact. In written form, a language
is expressed in characters. The same set of characters can often be is expressed in characters. The same set of characters can often be
used in many languages, and many languages can be expressed using used in many languages, and many languages can be expressed using
different scripts. A particular charset may have different glyphs different scripts. A particular charset may have different glyphs
(shapes) depending on the language being used. (shapes) depending on the language being used.
Expires 10th of March 2000 [Page 2] 1.2 Description of the Domain Name System
The Domain Name System is defined by [RFC1034] and [RFC1035], with
clarifications, extensions and modifications given in [RFC1123],
[RFC1996], [RFC2181] and others. Of special importance here is the
security extensions described in [RFC2535] and companions.
Over the years, many different words have been used to describe the
components of resource naming on the Internet [URI], [URN], ...; to make
certain that the set of terms used in this document are well-defined and
non-ambiguous, the definitions are given here.
A master server for a zone holds the main copy of that zone. This copy
is sometimes stored in a zone file. A slave server for a zone holds a
complete copy of the records for that zone. Slave servers may be either
authorized by the zone owner (secondary servers) or unauthorized
Expires 12th of October 2000 [Page 2]
(so-called "stealth secondaries"). Master and authorized slave servers
are listed in the NS records for the zone, and are termed
"authoritative" servers. In many contexts, outside this document the
term "primary" is used interchangeably with "master" and "secondary" is
used interchangeably with "slave".
A caching server holds temporary copies of DNS records; it uses records
to answer queries about domain names. Further explanation of these terms
can be found in [RFC1034] and [RFC1996].
DNS names can be represented in multiple forms, with different
properties for internationalization. The most important ones are:
- Domain name: The binary representation of a name used internally in
the DNS protocol. This consists of a series of components of 1-63
octets, with an overall length limited to 255 octets (including the
length fields).
- Master file format domain name: This is a representation of the name
as a sequence of characters in some character sets; the common
convention (derived from [RFC1035] section 5.1) is to represent the
octets of the name as ASCII characters where the octet is in the set
corresponding to the ASCII values for [a-zA-Z0-9-], using an escape
mechanism (\x or \NNN) where not, and separating the components of the
name by the dot character (".").
The form specified for most protocols using the DNS is a limited form of
the master file format domain name. This limited form is defined in
[RFC1034] Section 3.5 and [RFC1123]. In most implementations of
applications today, domain names in the Internet have been limited to
the much more restricted forms used, e.g., in email. Those names are
limited to the ASCII upper and lower-case characters (interpreted in a
case-independent fashion), the digits, and the hyphen, with the further
restrictions that a name may not consist entirely of digits and that a
hyphen cannot occur at the beginning or end of a component or following
another hyphen.
1.3 Definition of "hostname" and "Internationalized Domain Name"
In the DNS protocols, a name is referred to as a sequence of octets.
However, when discussing requirements for internationalized domain
names, what we are looking for is ways to represent characters,
something meaningful for humans.
In this document, this is referred to as a "hostname". While this term
has been used for many different purposes over the years, it is used
here in the sense of "sequence of characters (not octets) representing a
domain name conforming to the limited hostname syntax".
This document attempts to define the requirements for an
"Internationalized Domain Name" (IDN). This is defined as a sequence of
characters that can be used in the context of functions where a hostname
is used today, but contains one or more characters that are outside the
set of characters specified as legal characters for host names.
Expires 12th of October 2000 [Page 3]
1.4 A multilayer model of the DNS function
The DNS can be seen as a multilayer function:
- The bottom layer is where the packets passed across the Net in a DNS
query and a DNS response. At this level, what matters is the format
and meaning of bits and octets in a DNS packet.
- Above that is the "DNS service", created by an infrastructure of DNS
servers, NS records that point to those DNS servers, and is pointed to
by the root servers (listed in the "root cache file" on each DNS
server, often called "named.cache". It is at this level that the
statement "the DNS has a single root" [UNIROOT] makes sense, but
still, what are being transferred are octets, not characters.
- Interfacing to the user is a service layer, often called "the resolver
library", and often embedded in the operating system or system
libraries of the client machines. It is at the top of this layer that
the API calls commonly known as "gethostbyname" and "gethostbyaddress"
reside. These calls are modified to support IPv6 [RFC2553]. A
conceptually similar layer exists in authoritative DNS servers,
comprising the parts that generate "meaningful" strings in DNS files.
Due to the popularity of the "master file" format, this layer often
exists only in the administrative routines of the service maintainers.
- The user of this layer (resolver library) is the application programs
that use the DNS, such as mailers, mail servers, Web clients, Web
servers, Web caches, IRC clients, FTP clients, distributed file
systems, distributed databases, and almost all other applications on
TCP/IP. (preference not fact)
Graphically, one can illustrate it like this:
+---------------+ +---------------------+
| Application | | (Base data) |
+---------------+ +---------------------+
| Application service interface |
| For ex. GethostbyXXXX interface | (no standard)
+---------------+ +---------------------+
| Resolver | | Auth DNS server |
+---------------+ +---------------------+
| <----- DNS service interface -----> |
+------------------------------------------------------------------+
| DNS service |
| +-----------------------+ +--------------------+ |
| | Forwarding DNS server | | Caching DNS server | |
| +-----------------------+ +--------------------+ |
| |
| +-------------------------+ |
| | Parent-zone DNS servers | |
| +-------------------------+ |
| |
| +-------------------------+ |
| | Root DNS servers | |
| +-------------------------+ |
| |
+------------------------------------------------------------------+
Expires 12th of October 2000 [Page 4]
1.5 Service model of the DNS
The Domain Name Service is used for multiple purposes, each of which is
characterized by what it puts into the system (the query) and what it
expects as a result (the reply).
The most used ones in the current DNS are:
- Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get
back an IPv4 or IPv6 address.
Hostname-to-Mail server service (MX): As above, but the expected
return value is a hostname and a priority, for smtp servers.
- Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in
in-addr.arpa or ip6.int form respectively) and get back a hostname.
- Domain delegation service (NS). Enter a domain name and get back
nameserver records (designated hosts who provides authoritive
nameservice) for the domain.
New services are being defined, either as entirely new services (IPv6 to
hostname mapping using binary labels) or as embellishments to other
services (DNSSEC returning information about whether a given DNS service
is performed securely or not).
These services exist, conceptually, at the Application/Resolver
interface, NOT at the DNS-service interface. This document attempts to
set requirements for an equivalent of the "used services" given above,
where "hostname" is replaced by "Internationalized Domain Name". This
doesn't preclude the fact that IDN should work will any kind of DNS
queries. IDN is a new service, since existing protocols like SMTP or
HTTP use the old service. it is a matter of great concern how the new
and old services work together, and how other protocols can take
advantage of the new service.
2. General Requirements 2. General Requirements
These requirements address two concerns: The service offered to the
users (the application service), and the protocol extensions, if needed,
added to support this service.
In the requirements, we attempt to use the term "service" whenever a
requirement concerns the service, and "protocol" whenever a requirement
is believed to constrain the possible implementation.
2.1 Compatibility and Interoperability 2.1 Compatibility and Interoperability
The DNS is essential to the entire Internet. Therefore, the protocol [1] The DNS is essential to the entire Internet. Therefore, the service
must not damage present DNS protocol interoperability. It must make the must not damage present DNS protocol interoperability. It must make the
minimum number of changes to existing protocols on all layers of the minimum number of changes to existing protocols on all layers of the
stack. It must continue to allow any system anywhere to resolve any stack. It must continue to allow any system anywhere to resolve any
Internet internationalized domain name. internationalized domain name.
The protocol must preserve the basic concept and facilities of domain [2] The service must preserve the basic concept and facilities of domain
names as described in [RFC1034]. It must maintain a single, global, names as described in [RFC1034]. It must maintain a single, global,
universal, and consistent hierarchical namespace. universal and consistent hierarchical namespace.
The same name resolution request must generate the same response, [3] The same name resolution request must generate the same response,
regardless of the location or localization settings in the resolver, in regardless of the location or localization settings in the resolver, in
Expires 12th of October 2000 [Page 5]
the master server, and in any slave servers involved in the resolution the master server, and in any slave servers involved in the resolution
process. process.
If the protocol allows more than one charset, it should also allow [4] If the service allows more than one charset, the protocol should
creation of caching servers that do not understand the charset in which also allow creation of caching servers that do not understand the
a request or response is encoded. Such caching servers should work as charset in which a request or response is encoded. Such caching servers
well for IDNs as they do for current domain names. The caching server should work as well for IDNs as they do for current domain names. The
performs correctly if it gives the essentially the same answer (without caching server performs correctly if it gives essentially the same
the authoritative bit) as the master server would have if presented answer (without the authoritative bit) as the master server would have
with the same request. if presented with the same request.
A caching server must not return data in response to a query that would [5] A caching server must not return data in response to a query that
not have been returned if the same query had been presented to an would not have been returned if the same query had been presented to an
authoritative server. This applies fully for the cases when: authoritative server. This applies fully for the cases when:
- The caching server does not know about IDN - The caching server does not know about IDN
- The caching server implements the whole specification - The caching server implements the whole specification
- The caching server implements a legal subset of the specification - The caching server implements a valid subset of the specification
The protocol should be able to be upgraded at any time with new features [6] The service should be able to be upgraded at any time with new
and retain backwards compatibility with the current specification. features and retain backwards compatibility with the current
specification.
The protocol may modify the DNS protocol [RFC1035] and other related [7] The service may modify the DNS protocol [RFC1035] and other related
work undertaken by the DNSEXT WG. However, these changes should be as work undertaken by the DNSEXT WG. However, these changes should be as
small as possible and any changes must be approved by the DNSEXT WG. small as possible and any changes must be approved by the DNSEXT WG.
The protocol should be as simple as possible from the user's [8] The protocol supporting the service should be as simple as possible
perspective. Ideally, users should not realize that IDN was added on to from the user's perspective. Ideally, users should not realize that IDN
the existing DNS. was added on to the existing DNS.
A fall-back strategy or mechanism based upon ASCII may be needed during
a transition period during deployment and adoption of IDN. Therefore,
if an encoding is not mapped into ASCII, then there should be an ASCII-
only representation compatible with the current DNS and there should be
a way for a program to find the ASCII-only representation for IDN.
The best solution is one that maintains maximum feasible compatibility
with current DNS standards as long as it meets the other requirements
Expires 10th of March 2000 [Page 3] [9] A fall-back strategy or mechanism based upon ASCII may be needed
during a transition period during deployment and adoption of IDN.
Therefore, if an encoding is not mapped into ASCII, then there might be
an ASCII-only representation compatible with the current DNS and there
should be a way for a program to find the ASCII-only representation for
IDN. This is depending on how the protocol will handle exceptions.
in this document. [10] The best solution is one that maintains maximum feasible
compatibility with current DNS standards as long as it meets the other
requirements in this document.
2.2 Internationalization 2.2 Internationalization
Internationalized characters must be allowed to be represented and used [11] Internationalized characters must be allowed to be represented and
in DNS names and records. The protocol must specify what charset is used used in DNS names and records. The protocol must specify what charset is
when resolving domain names and how characters are encoded in DNS used when resolving domain names and how characters are encoded in DNS
records. records.
This document does not recommend any charset for I18N. If more than one [12] This document does not recommend any charset for IDN. If more than
charset is used in the protocol, then the protocol must specify all the one charset is used, or might be used in future, in the protocol, then
charsets being used and for what purpose. A CCS(s) chosen must at the protocol must specify all the charsets being used and for what
least cover the range of characters as currently defined (and as being purpose. It must also conform to [RFC1766] by tagging the charset. No
added) by ISO 10646/Unicode. implicit rules should be allowed for multiple charsets. A CCS(s) chosen
CES(s) chosen should not encode ASCII characters differently depending Expires 12th of October 2000 [Page 6]
on the other characters in the string. In other words, ASCII
character should remain as specified in [US-ASCII].
The protocol must not invent a new CCS for the purpose of IDN only must at least cover the range of characters as currently defined (and as
and should use existing CES. The charset(s) chosen should also be being added) by ISO 10646/Unicode.
[13] CES(s) chosen should not encode ASCII characters differently
depending on the other characters in the string. In other words, unless
IDN names are identified and coded differently from ASCII-only ones,
characters in the ASCII set should remain as specified in [US-ASCII].
[14] The protocol should not invent a new CCS for the purpose of IDN
only and should use existing CES. The charset(s) chosen should also be
non-ambiguous. non-ambiguous.
The protocol should not make any assumptions where in a domain name [15] The protocol should not make any assumptions about the location in
that internationalization might appear. In other words, it should not a domain name where internationalization might appear. In other words,
differentiate between any part of a domain name because this may impose it should not differentiate between any part of a domain name because
a restriction on future internationalization efforts. this may impose restrictions on future internationalization efforts.
The protocol should also not make any localized restrictions in the [16] The protocol should also not make any localized restrictions in the
protocol. For example, an IDN implementation which only allows domain protocol. For example, an IDN implementation which only allows domain
names to use a single local script would immediately restrict names to use a single local script would immediately restrict
multinational organization. multinational organization.
Because of the wide range of devices that use the DNS and the wide [17] Because of the wide range of devices that use the DNS and the wide
range of characteristics of international scripts, the protocol should range of characteristics of international scripts, the service might
allow more than one method of domain name input and display. However, need to allow more than one method of domain name input and display.
there has to be a single way of encoding an internationalized domain However, there must be a single way of encoding an internationalized
name within the core of the DNS. domain name within the core of the DNS.
2.3 Localization 2.3 Localization
The protocol must be able to handle localized requirement of different [18] The service should be able to handle localized requirements of
languages. For example, IDN must be able to handle bi-directional different languages. For example, IDN must be able to handle
writing for scripts such as Arabic. bi-directional writing for scripts such as Arabic.
Historically, "." has been the separator of labels in the host names. [19] Historically, "." has been the separator of labels in the host
The protocol should not use different separators for different names. The service should not use different separators for different
languages. languages.
Most localization can be handled by the user interface. It should not [20] Most of the localization work could be handled by the user
matter how the domain names are input or presented, such as in a interface. It should not matter how the domain names are input or
reverse order or bi-directional, or with the introduction of a new presented, such as in a reverse order or bi-directional, or with the
separator. However, the final wire format must be in canonical order. introduction of a new separator. However, the final wire format must be
in canonical order.
Expires 10th of March 2000 [Page 4]
2.4 Canonicalization 2.4 Canonicalization
Matching rules are a complicated process for IDN. Canonicalization of [21] Matching rules are a complicated process for IDN. Canonicalization
characters must follow precise and predictable rules to ensure of characters must follow precise and predictable rules to ensure
consistency. [CHARREQ] is a recommended as a guide on canonicalization. consistency. [CHARREQ] is a recommended as a guide on canonicalization.
The DNS has to match a host name in a request with a host name held [22] The DNS has to match a host name in a request with a host name held
in one or more zones. It also needs to sort names into order. It is in one or more zones. It also needs to sort names into order. It is
expected that some sort of canonicalization algorithm will be used as expected that some sort of canonicalization algorithm will be used as
the first step of this process. This section discusses some of the the first step of this process. This section discusses some of the
Expires 12th of October 2000 [Page 7]
properties which will be required of that algorithm. properties which will be required of that algorithm.
The canonicalization algorithm might specify operations for case, [23] The canonicalization algorithm might specify operations for case,
ligature, and punctuation folding. ligature, and punctuation folding.
In order to retain backwards compatibility with the current DNS, the [24] In order to retain backwards compatibility with the current DNS,
protocol must retain the case-insensitive comparison for US-ASCII as the service must retain the case-insensitive comparison for US-ASCII as
specified in [RFC1035]. For example, Latin capital letter A (U+0041) specified in [RFC1035]. For example, Latin capital letter A (U+0041)
must match Latin small letter A (U+0061). [UTR-21] describes some of must match Latin small letter a (U+0061). [UTR-21] describes some of
the issues with case mapping. the issues with case mapping. Case-insensitivity for non US-ASCII has to
be discussed in the protocol proposal.
Case folding must not be locale dependent. For example, Latin capital [25] Case folding must be locale independent. For example, Latin
letter I (U+0049) case folded to lower case in the Turkish context will capital letter I (U+0049) case folded to lower case in the Turkish
become Latin small letter dotless I (U+0131). But in the English context will become Latin small letter dotless i (U+0131). But in the
context, it will become Latin small letter I (U+0069). English context, it will become Latin small letter i (U+0069).
If other canonicalization is done, then it must be done before the [26] If other canonicalization is done, then it must be done before the
domain name is resolved. Further, the canonicalization must be easily domain name is resolved. Further, the canonicalization must be easily
upgrade able as new languages and writing systems are added. upgradable as new languages and writing systems are added.
Any conversion (case, ligature folding, punctuation folding, ...) from [27] Any conversion (case, ligature folding, punctuation folding, ...)
what the user enters into a client to what the client asks for from what the user enters into a client to what the client asks for
resolution must be done identically on all requests from any client. resolution must be done identically on any request from any client.
If the protocol specifies a canonicalization algorithm, a caching [28] If the protocol specifies a canonicalization algorithm, a caching
server should perform correctly regardless of how much (or how little) server should perform correctly regardless of how much (or how little)
of that algorithm it has implemented. [1 request to remove] of that algorithm it has implemented. [1 request to remove]
If the protocol requires a canonicalization algorithm, all requests [29] If the protocol requires a canonicalization algorithm, all requests
sent to a caching server must already be in the canonical form. sent to a caching server must already be in the canonical form.
If the charset can be normalized, then it should be normalized before [30] If the charset can be normalized, then it should be normalized
it is used in IDN. (conflict) before it is used in IDN. (conflict)
The protocol should avoid inventing a new normalization form provided [31] The protocol should avoid inventing a new normalization form
a technically sufficient one is available (such as in an ISO standard). provided a technically sufficient one is available (such as in an ISO
standard).
2.5 Operational Issues 2.5 Operational Issues
Zone files should remain easily editable. [32] Zone files should remain easily editable.
An IDN-capable resolver or server should not generate more traffic than [33] An IDN-capable resolver or server shall not generate more traffic
a non-IDN-capable resolver or server would when resolving an ASCII-only than a non-IDN-capable resolver or server would when resolving an
domain name. The amount of traffic generated when resolving an IDN ASCII-only domain name. The amount of traffic generated when resolving
an IDN shall be similar to that generated when resolving an ASCII-only
name.
Expires 10th of March 2000 [Page 5] [34] The service should not add new centralized administration for the
DNS. A domain administrator should be able to create internationalized
names as easily as adding current domain names.
should be similar to that generated when resolving an ASCII-only name. [35] Within a single zone, the zone manager must be able to define
The protocol should add no new centralized administration for the DNS. Expires 12th of October 2000 [Page 8]
A domain administrator should be able to create internationalized names
as easily as adding current domain names.
Within a single zone, the zone manager must be able to define
equivalence rules that suit the purpose of the zone, such as, but not equivalence rules that suit the purpose of the zone, such as, but not
limited to, and not necessarily, non-ASCII case folding, Unicode limited to, and not necessarily, non-ASCII case folding, Unicode
normalizations, Cyrillic/Latin folding, or traditional/simplified normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
Chinese equivalence. Such defined equivalences must not remove traditional/simplified Chinese equivalence. Such defined equivalences
equivalences that are assumed by (old or local-rule-ignorant) caches. must not remove equivalences that are assumed by (old or
local-rule-ignorant) caches.
The character set of a signed zone file should be capable of being the [36] The character set of a signed zone file should be the same as the
same as the character set of the unsigned zone file. The protocol must character set of the unsigned zone file. The protocol must allow offline
allow offline DNSSEC signing. It should be possible to look at the DNSSEC signing. It should be possible to look at the
signed file and see that it is the same as the unsigned one. signed file and see that it is the same as the unsigned one.
2.6 Others 2.6 Others
The protocol may provide the same DNS resources using internationalized [37] The service may provide the same DNS resources using
text as it currently provides using ASCII text. internationalized text as it currently provides using ASCII text.
To get full semantics for IDN, an upgrade of the DNS and related [38] To get full semantics for IDN, an upgrade of the DNS and related
software may be needed. software may be needed.
The protocol should consider new features of DNS such as DNSSEC and [39] The protocol should consider new features of DNS such as DNSSEC and
DNAME. For example, DNAME might be useful to simplify canonicalization DNAME. For example, DNAME might be useful to simplify canonicalization
for IDN. for IDN.
[40] The protocol must work for IPv4 and IPv6.
3. Technical Analysis 3. Technical Analysis
There are many standard protocols and RFCs which are depend on There are many standard protocols and RFCs which depend on
domain names and have make various assumptions about the characters domain names and have make various assumptions about the characters
in them always conforming to [RFC-1034]. We expect that the protocols in them always conforming to [RFC1034] and the other restriction
discussed above (see [IABIDN]). We expect that the protocols
listed below to be affected: listed below to be affected:
<...list the sets of RFCs which we would like to have an summary...> I RFC2813 Internet Relay Chat : Server Protocol
RFC821, RFC822, ... I RFC2805 Media Gateway Control Protocol Architecture and Requirements
S RFC2789 Mail Monitoring MIB
S RFC2782 A DNS RR for specifying the location of services (DNS SRV)
I RFC2775 Internet Transparency
I RFC2772 6Bone Backbone Routing Guidelines
I RFC2768 Network Policy and Services: A Report of a Workshop on
Middleware
I RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)
S RFC2766 Network Address Translation - Protocol Translation (NAT-PT)
S RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT)
I RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS
E RFC2756 Hyper Text Caching Protocol (HTCP/0.0)
S RFC2748 The COPS (Common Open Policy Service) Protocol
S RFC2744 Generic Security Service API Version 2 : C-bindings
S RFC2743 Generic Security Service Application Program Interface
I RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0
I RFC2694 DNS extensions to Network Address Translators (DNS_ALG)
E RFC2693 SPKI Certificate Theory
S RFC2673 Binary Labels in the Domain Name System
All idn protocol documents must fully detail the expected effects of Expires 12th of October 2000 [Page 9]
leaking of the specified encoding to protocols other than the DNS
resolution protocol. They must also contain a summary of the technical S RFC2672 Non-Terminal DNS Name Redirection
opinions of the IDN Working Group. S RFC2671 Extension Mechanisms for DNS (EDNS0)
I RFC2663 IP Network Address Translator (NAT) Terminology and
Considerations
S RFC2661 Layer Two Tunneling Protocol "L2TP"
E RFC2654 A Tagged Index Object for use in the Common Indexing Protocol
I RFC2637 Point-to-Point Tunneling Protocol (PPTP)
I RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP
S RFC2632 S/MIME Version 3 Certificate Handling
S RFC2622 Routing Policy Specification Language (RPSL)
S RFC1616 Hypertext Transfer Protocol -- HTTP/1.1
I RFC2614 An API for Service Location
S RFC2609 Service Templates and Service: Schemes
B RFC2606 Reserved Top Level DNS Names
I RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP
S RFC2600 Internet Official Protocol Standards
S RFC2595 Using TLS with IMAP, POP3 and ACAP
I RFC2553 Basic Socket Interface Extensions for IPv6
I RFC2546 6Bone Routing Practice
S RFC2543 SIP: Session Initiation Protocol
I RFC2541 DNS Security Operational Considerations
E RFC2540 Detached Domain Name System (DNS) Information
S RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
S RFC2538 Storing Certificates in the Domain Name System (DNS)
S RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
S RFC2546 DSA KEYs and SIGs in the Domain Name System (DNS)
S RFC2535 Domain Name System Security Extensions
I RFC2517 Building Directories from DNS: Experiences from WWWSeeker
S RFC2511 Internet X.509 Certificate Request Message Format
B RFC2505 Anti-Spam Recommendations for SMTP MTAs
S RFC2500 Internet Official Protocol Standards
S RFC2486 The Network Access Identifier
S RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL
Profile
S RFC2421 Voice Profile for Internet Mail - version 2
I RFC2412 The OAKLEY Key Determination Protocol
S RFC2408 Internet Security Association and Key Management Protocol
(ISAKMP)
S RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP
S RFC2401 Security Architecture for the Internet Protocol
S RFC2400 INTERNET OFFICIAL PROTOCOL STANDARDS
S RFC2396 Uniform Resource Identifiers (URI): Generic Syntax
I RFC2377 Naming Plan for Internet Directory-Enabled Applications
I RFC2367 "PF_KEY Key Management API, Version 2"
I RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed
Pages Document
E RFC2345 Domain Names and Company Name Retrieval
S RFC2326 Real Time Streaming Protocol (RTSP)
B RFC2317 Classless IN-ADDR.ARPA delegation
S RFC2308 Negative Caching of DNS Queries (DNS NCACHE)
S RFC2300 INTERNET OFFICIAL PROTOCOL STANDARDS
S RFC2298 An Extensible Message Format for Message Disposition
Notifications
S RFC2280 Routing Policy Specification Language (RPSL)
S RFC2249 Mail Monitoring MIB
S RFC2247 Using Domains in LDAP/X.500 Distinguished Names
I RFC2230 Key Exchange Delegation Record for the DNS
B RFC2219 Use of DNS Aliases for Network Services
S RFC2200 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC2187 "Application of Internet Cache Protocol (ICP), version 2"
B RFC2182 Selection and Operation of Secondary DNS Servers
S RFC2181 Clarifications to the DNS Specification
E RFC2168 Resolution of Uniform Resource Identifiers using the Domain
Name System
I RFC2167 Referral Whois (RWhois) Protocol V1.5
S RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global
Address Mapping (MCGAM)
S RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between
X.400 and RFC 822/MIME
I RFC2151 A Primer On Internet and TCP/IP Tools and Utilities
I RFC2146 U.S. Government Internet Domain Names
S RFC2142 MAILBOX NAMES FOR "COMMON SERVICES, ROLES AND FUNCTIONS"
S RFC2137 Secure Domain Name System Dynamic Update
S RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
I RFC2133 Basic Socket Interface Extensions for IPv6
S RFC2131 Dynamic Host Configuration Protocol
I RFC2130 The Report of the IAB Character Set Workshop
I RFC2101 IPv4 Address Behaviour Today
S RFC2078 "Generic Security Service Application Program Interface,
Version 2"
S RFC2074 Remote Network Monitoring MIB Protocol Identifiers
I RFC2072 Router Renumbering Guide
S RFC2068 Hypertext Transfer Protocol -- HTTP/1.1
S RFC2065 Domain Name System Security Extensions
E RFC2052 A DNS RR for specifying the location of services (DNS SRV)
S RFC2034 SMTP Service Extension for Returning Enhanced Error Codes
I RFC2010 Operational Criteria for Root Name Servers
E RFC2009 GPS-Based Addressing and Routing
S RFC2000 INTERNET OFFICIAL PROTOCOL STANDARDS
S RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)
S RFC1995 Incremental Zone Transfer in DNS
S RFC1985 SMTP Service Extension for Remote Message Queue Starting
I RFC1983 Internet Users' Glossary
S RFC1982 Serial Number Arithmetic
S RFC1964 The Kerberos Version 5 GSS-API Mechanism
I RFC1958 Architectural Principles of the Internet
I RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for
IPNG
S RFC1933 Transition Mechanisms for IPv6 Hosts and Routers
S RFC1920 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1919 Classical versus Transparent IP Proxies
I RFC1912 Common DNS Operational and Configuration Errors
I RFC1900 Renumbering Needs Work
S RFC1891 SMTP Service Extension for Delivery Status Notifications
I RFC1887 An Architecture for IPv6 Unicast Address Allocation
S RFC1886 DNS Extensions to support IP version 6
S RFC1880 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1877 PPP Internet Protocol Control Protocol Extensions for Name
Server Addresses
E RFC1876 A Means for Expressing Location Information in the Domain Name
System
E RFC1845 SMTP Service Extension for Checkpoint/Restart
I RFC1816 U.S. Government Internet Domain Names
S RFC1800 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1794 DNS Support for Load Balancing
E RFC1788 ICMP Domain Name Messages
S RFC1780 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1739 A Primer On Internet and TCP/IP Tools
S RFC1720 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1713 Tools for DNS debugging
E RFC1712 DNS Encoding of Geographical Location
I RFC1711 Classifications in E-mail Routing
I RFC1709 K-12 Internetworking Guidelines
I RFC1707 CATNIP: Common Architecture for the Internet
I RFC1706 DNS NSAP Resource Records
I RFC1705 Six Virtual Inches to the Left: The Problem with IPng
I RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio
Paging -- Technical Procedures
I RFC1671 IPng White Paper on Transition and Other Considerations
E RFC1664 Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables
E RFC1637 DNS NSAP Resource Records
I RFC1636 Report of IAB Workshop on Security in the Internet
Architecture "February 8-10, 1994"
I RFC1630 Universal Resource Identifiers in WWW
I RFC1621 Pip Near-term Architecture
I RFC1616 X.400(1988) for the Academic and Research Community in Europe
S RFC1612 DNS Resolver MIB Extensions
S RFC1611 DNS Server MIB Extensions
S RFC1610 INTERNET OFFICIAL PROTOCOL STANDARDS
E RFC1608 Representing IP Information in the X.500 Directory
S RFC1600 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1597 Address Allocation for Private Internets
I RFC1594 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
I RFC1591 Domain Name System Structure and Delegation
I RFC1588 WHITE PAGES MEETING REPORT
I RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio
Paging -- Technical Procedures
I RFC1546 Host Anycasting Service
S RFC1540 INTERNET OFFICIAL PROTOCOL STANDARDS
I RFC1537 Common DNS Data File Configuration Errors
I RFC1536 Common DNS Implementation Errors and Suggested Fixes
I RFC1535 A Security Problem and Proposed Correction With Widely
Deployed DNS Software
I RFC1530 Principles of Operation for the TPC.INT Subdomain: General
Principles and Policy
E RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote
Printing -- Technical Procedures
S RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment
and Aggregation Strategy
S RFC1500 INTERNET OFFICIAL PROTOCOL STANDARDS
- RFC1486 An Experiment in Remote Printing
- RFC1480 The US Domain
- RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices
- RFC1464 Using the Domain Name System To Store Arbitrary String
Attributes
- RFC1459 Internet Relay Chat Protocol
- RFC1454 Comparison of Proposals for Next Version of IP
- RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory
Service
- RFC1415 FTP-FTAM Gateway Specification
- RFC1410 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1401 Correspondence between the IAB and DISA on the use of DNS
throughout the Internet
- RFC1395 BOOTP Vendor Information Extensions
- RFC1392 Internet Users' Glossary
- RFC1386 The US Domain
- RFC1385 EIP: The Extended Internet Protocol A Framework for
Maintaining Backward Compatibility
- RFC1383 An Experiment in DNS Based IP Routing
- RFC1360 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1348 DNS NSAP RRs
- RFC1347 "TCP and UDP with Bigger Addresses (TUBA)," A Simple Proposal
for Internet Addressing and Routing
- RFC1335 A Two-Tier Address Structure for the Internet: A Solution to
the Problem of Address Space Exhaustion
- RFC1325 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
- RFC1309 Technical Overview of Directory Services Using the X.500
Protocol
- RFC1308 Executive Introduction to Directory Services Using the X.500
Protocol
- RFC1291 Mid-Level Networks Potential Technical Services
- RFC1280 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1279 X.500 and Domains
- RFC1274 The COSINE and Internet X.500 Schema
- RFC1250 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1207 FYI on Questions and Answers "Answers to Commonly asked
""Experienced Internet User"" Questions"
- RFC1206 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
- RFC1200 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1183 New DNS RR Definitions
- RFC1177 FYI on Questions and Answers "Answers to Commonly asked ""New
Internet User"" Questions"
- RFC1175 FYI on Where to Start - A Bibliography of Internetworking
Information
- RFC1174 IAB Recommended Policy on Distributing Internet Identifier
Assignment And "IAB Recommended Policy Change to Internet
""Connected"" Status"
- RFC1168 INTERMAIL AND COMMERCIAL MAIL RELAY SERVICES
- RFC1147 FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices
- RFC1123 Requirements for Internet Hosts -- Application and Support
- RFC1101 DNS Encoding of Network Names and Other Types
- RFC1100 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1085 ISO Presentation Services on top of TCP/IP-based internets
- RFC1083 IAB OFFICIAL PROTOCOL STANDARDS
- RFC1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
- RFC1034 DOMAIN NAMES - CONCEPTS AND FACILITIES
- RFC0830 A Distributed System for Internet Name Service
S - Standards Track I - Informational
E - Experimental B - Best Current Practice
All idn protocol proposal documents must fully detail the expected
effects of leaking of the specified encoding to protocols other than the
DNS resolution protocol.
4. Security Considerations 4. Security Considerations
Any solution that meets the requirements in this document must not Any solution that meets the requirements in this document must not
be less secure than the current DNS. Specifically, the mapping of be less secure than the current DNS. Specifically, the mapping of
internationalized host names to and from IP addresses must have the internationalized host names to and from IP addresses must have the
same characteristics as the mapping of today's host names. same characteristics as the mapping of today's host names.
Specifying requirements for internationalized domain names does not Specifying requirements for internationalized domain names does not
itself raise any new security issues. However, any change to the DNS itself raise any new security issues. However, any change to the DNS may
affect the security of any protocol that relies on the DNS or on
Expires 10th of March 2000 [Page 6]
may affect the security of any protocol that relies on the DNS or on
DNS names. A thorough evaluation of those protocols for security DNS names. A thorough evaluation of those protocols for security
concerns will be needed when they are developed. In particular, IDNs concerns will be needed when they are developed. In particular, IDNs
must be compatible with DNSSEC. must be compatible with DNSSEC and, if multiple charsets or
representation forms are permitted, the implications of this name-spoof
must be throughly understood.
5. References 5. References
[CHARREQ] "Requirements for string identity matching and String [CHARREQ] "Requirements for string identity matching and String
Indexing", http://www.w3.org/TR/WD-charreq, July 1998, Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
World Wide Web Consortium. World Wide Web Consortium.
[DNSEXT] "IETF DNS Extensions Working Group", [DNSEXT] "IETF DNS Extensions Working Group",
namedroppers@internic.net, Olafur Gudmundson, Randy Bush. namedroppers@internic.net, Olafur Gudmundson, Randy Bush.
[RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt, [RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt,
November 1987, P. Mockapetris. November 1987, P. Mockapetris.
[RFC1035] "Domain Names - Implementation and Specification", [RFC1035] "Domain Names - Implementation and Specification",
rfc1035.txt, November 1987, P. Mockapetris. rfc1035.txt, November 1987, P. Mockapetris.
[RFC1123] "Requirements for Internet Hosts -- Application and [RFC1123] "Requirements for Internet Hosts -- Application and
Support", rfc1123.txt, October 1989, R. Braden. Support", rfc1123.txt, October 1989, R. Braden.
[RFC1766] Tags for the Identification of Languages, rfc1766.txt,
March 1995, H. Alvestrand.
[RFC1996] "A Mechanism for Prompt Notification of Zone Changes [RFC1996] "A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie. (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", rfc2119.txt, March 1997, S. Bradner. Levels", rfc2119.txt, March 1997, S. Bradner.
[RFC2181] "Clarifications to the DNS Specification", rfc2181.txt,
July 1997, R. Elz, R. Bush.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2535] "Domain Name System Security Extensions", rfc2535.txt,
March 1999, D. Eastlake.
[RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt,
March 1999, R. Gilligan and al.
[UNIROOT] "IAB Technical Comment on the Unique DNS Root",
draft-iab-unique-dns-root-00.txt, iab@iab.org
[IABIDN] "A Tangled Web:issues of I18N domain names, and the
other Internet protocols", rfc2825.txt
iab@iab.org
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at 3.0", ISBN 0-201-61633-5. Described at
http://www.unicode.org/unicode/standard/versions/ http://www.unicode.org/unicode/standard/versions/
Unicode3.0.html Unicode3.0.html
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
[UTR15] "Unicode Normalization Forms", Unicode Technical Report [UTR15] "Unicode Normalization Forms", Unicode Technical Report
#15, http://www.unicode.org/unicode/reports/tr15/, #15, http://www.unicode.org/unicode/reports/tr15/,
Nov 1999, M. Davis & M. Duerst, Unicode Consortium. Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
[UTR21] "Case Mappings", Unicode Technical Report #21, [UTR21] "Case Mappings", Unicode Technical Report #21,
http://www.unicode.org/unicode/reports/tr21/, Dec 1999, http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
M. Davis, Unicode Consortium. M. Davis, Unicode Consortium.
Appendix A. Acknowledgements 6. Editors' Contact
Zita Wenzel
[ ... ]
James Seng
8 Temesek Boulevand
#24-02 Suntec Tower 3
Singapore 038988
Tel: +65 248-6208
Fax: +65 248-6198
Email: jseng@pobox.org.sg
7. Acknowledgements
The editor gratefully acknowledges the contributions of: The editor gratefully acknowledges the contributions of:
Harald Tveit Alvestrand <Harald@Alvestrand.no> Harald Tveit Alvestrand <Harald@Alvestrand.no>
Martin Duerst <duerst@w3.org> Martin Duerst <duerst@w3.org>
Patrik Faltstrom <paf@swip.net> Patrik Faltstrom <paf@swip.net>
Andrew Draper <ADRAPER@altera.com> Andrew Draper <ADRAPER@altera.com>
Bill Manning <bmanning@ISI.EDU> Bill Manning <bmanning@ISI.EDU>
Expires 10th of March 2000 [Page 7]
Paul Hoffman <phoffman@imc.org> Paul Hoffman <phoffman@imc.org>
James Seng <jseng@pobox.org.sg> James Seng <jseng@pobox.org.sg>
Randy Bush <randy@psg.com> Randy Bush <randy@psg.com>
Alan Barret <apb@cequrux.com> Alan Barret <apb@cequrux.com>
Olafur Gudmundsson <ogud@tislabs.com> Olafur Gudmundsson <ogud@tislabs.com>
Karlsson Kent <keka@im.se> Karlsson Kent <keka@im.se>
Dan Oscarsson <Dan.Oscarsson@trab.se> Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu> J. William Semich <bill@mail.nic.nu>
RJ Atkinson <request not to have email> RJ Atkinson <request not to have email>
Simon Josefsson <jas+idn@pdc.kth.se> Simon Josefsson <jas+idn@pdc.kth.se>
Ned Freed <ned.freed@innosoft.com> Ned Freed <ned.freed@innosoft.com>
Dongman Lee <dlee@icu.ac.kr> Dongman Lee <dlee@icu.ac.kr>
Mark Andrews <Mark.Andrews@nominum.com> Mark Andrews <Mark.Andrews@nominum.com>
John Klensin <klensin+idn@jck.com>
Expires 10th of March 2000 [Page 8] Tan Juay Kwang <tanjk@i-dns.net>
 End of changes. 70 change blocks. 
159 lines changed or deleted 609 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/