draft-ietf-idn-idna-00.txt   draft-ietf-idn-idna-01.txt 
Internet Draft Paul Hoffman Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-00.txt IMC & VPNC draft-ietf-idn-idna-01.txt Cisco
September 12, 2000 Patrik Faltstrom Paul Hoffman
Expires in six months Cisco Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA) Internationalizing Host Names In Applications (IDNA)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at line 50 skipping to change at line 50
In the discussion of IDN solutions, a great deal of discussion has In the discussion of IDN solutions, a great deal of discussion has
focused on transition issues and how IDN will work in a world where not focused on transition issues and how IDN will work in a world where not
all of the components have been updated. Earlier proposed solutions all of the components have been updated. Earlier proposed solutions
require that user applications, resolvers, and DNS servers to be updated require that user applications, resolvers, and DNS servers to be updated
in order for a user to use an internationalized host name. Instead of in order for a user to use an internationalized host name. Instead of
this requirement for widespread updating of all components, the current this requirement for widespread updating of all components, the current
proposal is that only user applications be updated; no changes are proposal is that only user applications be updated; no changes are
needed to the DNS protocol or any DNS servers or the resolvers on user's needed to the DNS protocol or any DNS servers or the resolvers on user's
computers. computers.
This document is being discussed on the ietf-idna@mail.apps.ietf.org
mailing list. To subscribe, send a message to
ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in
the body of the message.
1.1 Design philosophy 1.1 Design philosophy
To date, the proposals for IDN protocols have required that DNS servers To date, the proposals for IDN protocols have required that DNS servers
be updated to handle internationalized host names. Because of this, the be updated to handle internationalized host names. Because of this, the
person who wanted to use an internationalized host name had to be sure person who wanted to use an internationalized host name had to be sure
that their request went to a DNS server that was updated for IDN. that their request went to a DNS server that was updated for IDN.
Further, that server could only send queries to other servers that had Further, that server could only send queries to other servers that had
been updated for IDN because the queries contain new protocol elements been updated for IDN because the queries contain new protocol elements
to differentiate IDN name parts from current host parts. In addition, to differentiate IDN name parts from current host parts. In addition,
these proposals require that resolvers must be updated to use the new these proposals require that resolvers must be updated to use the new
protocols, and in most cases the applications would need to be updated protocols, and in most cases the applications would need to be updated
as well. as well.
Updating all (or even a significant percentage) of the DNS servers in Updating all (or even a significant percentage) of the DNS servers in
the world will be difficult, to say the least. Because of this, we have the world will be difficult, to say the least. Because of this, we have
designed a protocol that requires no updating of any name servers. IDNA designed a protocol that requires no updating of any name servers. IDNA
still requires the updating of applications, but once a still requires the updating of applications, but once a user has updated
user has updated these, she or he could immediately start using these, she or he could immediately start using internationalized host
internationalized host names. The cost of implementing IDN would thus be names. The cost of implementing IDN would thus be much lower, and the
much lower, and the speed of implementation will be much higher. speed of implementation will be much higher.
1.2 Terminology 1.2 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119 "MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
1.3 IDN summary
Using the terminology in [IDNCOMP], this protocol specifies an IDN
architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
and the method for distinguishing ACE name parts from current name parts
is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
changes needed to the DNS, the transition strategy is trans-1 (always do
current plus new architecture).
2. Structural Overview 2. Structural Overview
In IDNA, users' applications are updated to perform the processing In IDNA, users' applications are updated to perform the processing
needed to input internationalized host names from users, display needed to input internationalized host names from users, display
internationalized host names that are returned from the DNS to users, internationalized host names that are returned from the DNS to users,
and process the inputs and outputs from the DNS. and process the inputs and outputs from the DNS.
2.1 Interfaces between DNS components in IDNA 2.1 Interfaces between DNS components in IDNA
The interfaces in IDNA can be represented pictorially as: The interfaces in IDNA can be represented pictorially as:
skipping to change at line 108 skipping to change at line 104
| User | | User |
+------+ +------+
^ ^
| Input and display: local interface methods | Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...) | (pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+ +--------------- v -------------------------------+
| +-------------+ | | +-------------+ |
| | Application | | End system | | Application | | End system
| +-------------+ | +-------------+
| ^ | ^
| | API call and return: nameprepped RACE | | API call and return: nameprepped ACE
| v | v
| +----------+ | +----------+
| | Resolver | | | Resolver |
| +----------+ | | +----------+ |
+----------------^--------------------------------+ +----------------^--------------------------------+
| DNS query and response: nameprepped RACE | DNS query and response: nameprepped ACE
v v
+-------------+ +-------------+
| DNS servers | | DNS servers |
+-------------+ +-------------+
This document uses the generic term "ACE" for an ASCII-compatible
encoding. After the IDN Working Group has chosen a specific ACE, this
document will be updated to refer to just that single ACE. Until that
time, an implementor creating experimental software must choose an ACE
to use, such as RACE or LACE or DUDE.
2.1.1 Users and applications 2.1.1 Users and applications
Applications can accept host names using any character set or sets Applications can accept host names using any character set or sets
desired by the application developer, and can display host names in any desired by the application developer, and can display host names in any
charset. That is, this protocol does not affect the interface between charset. That is, this protocol does not affect the interface between
users and applications. users and applications.
An IDNA-aware application can accept and display internationalized host An IDNA-aware application can accept and display internationalized host
names in two formats: the internationalized character set(s) supported names in two formats: the internationalized character set(s) supported
by the application, and in RACE [RACE] ASCII-compatible encoding. by the application, and in an ACE. Applications MAY allow ACE input and
Applications MAY allow RACE input and output, but are not encouraged to output, but are not encouraged to do so except as an interface for
do so except as an interface for advanced users, possibly for debugging. advanced users, possibly for debugging. ACE encoding is opaque and ugly,
RACE encoding is opaque and ugly, and should thus only be exposed to and should thus only be exposed to users who absolutely need it. The
users who absolutely need it. The optional use, especially during a optional use, especially during a transition period, of ACE encodings in
transition period, of RACE encodings in the user interface is described the user interface is described in section 3. Since ACE can be rendered
in section 3. Since RACE can be rendered either as the encoded ASCII either as the encoded ASCII glyphs or the proper decoded character
glyphs or the proper decoded character glyphs, the rendering engine for glyphs, the rendering engine for an application SHOULD have an option
an application SHOULD have an option for the user to select the for the user to select the preferred display; if it does, rendering the
preferred display; if it does, rendering the RACE SHOULD NOT be the ACE SHOULD NOT be the default.
default.
2.1.2 Applications and resolvers 2.1.2 Applications and resolvers
Applications communicate with resolver libraries through a programming Applications communicate with resolver libraries through a programming
interface (API). Typically, the IETF does not standardize APIs, although interface (API). Typically, the IETF does not standardize APIs, although
it has for IPv6. This protocol does not specify a specific API, but there are non-standard APIs specified for IPv6. This protocol does not
instead specifies only the input and output formats of the host names to specify a specific API, but instead specifies only the input and output
the resolver library. formats of the host names to the resolver library.
Before converting the name parts into RACE, the application MUST prepare Before converting the name parts into ACE, the application MUST prepare
each name part as specified in [NAMEPREP]. The application MUST use RACE each name part as specified in [NAMEPREP]. The application MUST use ACE
ASCII-compatible encoding for the name parts that are sent to the for the name parts that are sent to the resolver, and will always get
resolver, and will always get name parts encoded in RACE from the name parts encoded in ACE from the resolver.
resolver.
IDNA-aware applications MUST be able to work with both IDNA-aware applications MUST be able to work with both
non-internationalized host name parts (those that conform to RFC 1035 non-internationalized host name parts (those that conform to [STD13] and
[STD13]) and internationalized host name parts. An IDNA-aware [STD3]) and internationalized host name parts. An IDNA-aware application
application that is resolving a non-internationalized host name parts that is resolving a non-internationalized host name parts MUST NOT do
MUST NOT do any preparation or conversion to RACE on any any preparation or conversion to ACE on any non-internationalized name
non-internationalized name part. part.
2.1.3 Resolvers and DNS servers 2.1.3 Resolvers and DNS servers
An operating system might have a set of libraries for converting host An operating system might have a set of libraries for converting host
names to nameprepped RACE. The input to such a library might be in one names to nameprepped ACE. The input to such a library might be in one or
or more charsets that are used in applications (UTF-8 and UTF-16 are more charsets that are used in applications (UTF-8 and UTF-16 are likely
likely candidates for almost any operating system, and script-specific candidates for almost any operating system, and script-specific charsets
charsets are likely for localized operating systems). The output would are likely for localized operating systems). The output would be either
be either the unchanged name part (if the input already conforms to [STD the unchanged name part (if the input already conforms to [STD13] and
13]), or the nameprepped, RACE-encoded name part. Such a library would [STD3]), or the nameprepped, ACE-encoded name part.
help keep applications smaller.
DNS servers MUST use the RACE format for internationalized host name DNS servers MUST use the ACE format for internationalized host name
parts. parts.
If a signalling system which makes negotiation possible between old and If a signalling system which makes negotiation possible between old and
new DNS clients and servers is standardized in the future, the encoding new DNS clients and servers is standardized in the future, the encoding
of the query in the DNS protocol itself can be changed from RACE to of the query in the DNS protocol itself can be changed from ACE to
something else, such as UTF-8. The question whether or not this should something else, such as UTF-8. The question whether or not this should
be used is, however, a separate problem and is not discussed in this be used is, however, a separate problem and is not discussed in this
memo. memo.
2.1.4 Avoiding exposing users to the raw ACE encoding 2.1.4 Avoiding exposing users to the raw ACE encoding
All applications that might show the user a host name that was received All applications that might show the user a host name that was received
from a gethostbyaddr or other such lookup SHOULD update as soon as from a gethostbyaddr or other such lookup SHOULD update as soon as
possible in order to prevent users from seeing the ACE. However, this is possible in order to prevent users from seeing the ACE. However, this is
not considered a big problem because so few applications show this type not considered a big problem because so few applications show this type
of resolution to users. of resolution to users.
3. Name Server Considerations 3. Name Server Considerations
It is imperative that there be only one encoding for a particular host It is imperative that there be only one encoding for a particular host
name. RACE is an encoding for host name parts that use characters name. ACE is an encoding for host name parts that use characters outside
outside those allowed for host names [STD 13]. Thus, a primary master those allowed for host names [STD13]. Thus, a primary master name server
name server MUST NOT contain an RACE-encoded name that decodes to a host MUST NOT contain an ACE-encoded name that decodes to a host name that is
name that is allowed in [STD 13]. allowed in [STD13] and [STD3].
Name servers MUST NOT have any records with host names that contain Name servers MUST NOT have any records with host names that contain
internationalized name parts unless those name parts have be prepared internationalized name parts unless those name parts have be prepared
according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are
passed to an application, it will result in an error being passed to the passed to an application, it will result in an error being passed to the
application with no error being reported to the name server. Further, no application with no error being reported to the name server. Further, no
application will ever ask for a name that is not legal in [NAMEPREP] application will ever ask for a name that is not legal in [NAMEPREP]
because requests always go through [NAMEPREP] before getting to the DNS. because requests always go through [NAMEPREP] before getting to the DNS.
The host name data in zone files (as specified by section 5 of RFC 1035) The host name data in zone files (as specified by section 5 of RFC 1035)
MUST be both nameprepped and RACE encoded. MUST be both nameprepped and ACE encoded.
4. Root Server Considerations 4. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the root servers. protocol has no effect on the root servers.
5. Security Considerations 5. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any change Much of the security of the Internet relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of the to the characteristics of the DNS can change the security of much of the
skipping to change at line 231 skipping to change at line 230
Host names are used by users to connect to Internet servers. The Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers single internationalized name could be connected to different servers
based on different interpretations of the internationalized host name. based on different interpretations of the internationalized host name.
Because this document normatively refers to [NAMEPREP], it includes the Because this document normatively refers to [NAMEPREP], it includes the
security considerations from that document as well. security considerations from that document as well.
6. References 6. References
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare.
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep. Internationalized Host Names", draft-ietf-idn-nameprep.
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-ietf-idn-race.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119. Requirement Levels", March 1997, RFC 2119.
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
10646", January 1998, RFC 2279. 10646", January 1998, RFC 2279.
[STD13] Paul Mockapetris, "Domain names - implementation and [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
specification", November 1987, STD 13 (RFC 1035). Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989.
A. Authors' Addresses [STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
1034) and "Domain names - implementation and specification" (RFC 1035,
STD 13, November 1987.
B. Changes from the -00 draft
Throughout: Changed "RACE" to "ACE" and removed RACE-specific wording.
1: Added pointer to the mailing list.
1.3: Removed the [IDNCOMP] comparison section.
2.1: Added the last paragraph discussing ACEs.
2.1.2: Changed the discussion of IPv6 APIs to say they are not
standards. Added reference to [STD3].
2.1.3: Added reference to [STD3]. Removed the sentence about making
things smaller.
3: Added reference to [STD3].
6: Added [STD3], and updated the reference info for [STD13].
Removed [IDNCOMP].
C. Authors' Addresses
Patrik Faltstrom
Cisco Systems
Arstaangsvagen 31 J
S-117 43 Stockholm
Sweden
paf@cisco.com
Paul Hoffman Paul Hoffman
Internet Mail Consortium and VPN Consortium Internet Mail Consortium and VPN Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 USA Santa Cruz, CA 95060 USA
phoffman@imc.org phoffman@imc.org
Patrik Faltstrom --
Cisco Systems Patrik F„ltstr÷m <paf@cisco.com> Cisco Systems
170 West Tasman Drive SJ-13/2 Consulting Engineer Office of the CSO
San Jose, CA 95134 USA Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-8509
paf@cisco.com PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC
 End of changes. 21 change blocks. 
66 lines changed or deleted 92 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/