draft-ietf-idn-idna-04.txt   draft-ietf-idn-idna-05.txt 
Internet Draft Patrik Faltstrom Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-04.txt Cisco draft-ietf-idn-idna-05.txt Cisco
November 8, 2001 Paul Hoffman November 19, 2001 Paul Hoffman
Expires in six months IMC & VPNC Expires in six months IMC & VPNC
Adam M. Costello Adam M. Costello
UC Berkeley UC Berkeley
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.
skipping to change at line 247 skipping to change at line 247
6. Apply ToASCII. 6. Apply ToASCII.
7. Verify that the sequence matches the saved copy from step 3, using 7. Verify that the sequence matches the saved copy from step 3, using
a case-insensitive ASCII comparison. a case-insensitive ASCII comparison.
8. Return the saved copy from step 5. 8. Return the saved copy from step 5.
5. ACE prefix 5. ACE prefix
The ACE prefix, used in the conversion operations (section 4), will The ACE prefix, used in the conversion operations (section 4), will be
be specified in a future revision of this document. It will be two specified in a future revision of this document. It will be two
alphanumeric ASCII characters followed by two hyphen-minuses. It MUST alphanumeric ASCII characters followed by two hyphen-minuses. The
be recognized in a case-insensitive manner. ToASCII and ToUnicode operations MUST recognize the ACE prefix in a
case-insensitive manner.
For example, the eventual ACE prefix might be the string "jk--". In this For example, the eventual ACE prefix might be the string "jk--". In this
case, an ACE label might be "jk--r3c2a-qc902xs", where "r3c2a-qc902xs" case, an ACE label might be "jk--r3c2a-qc902xs", where "r3c2a-qc902xs"
is the part of the ACE label that is generated by the encoding steps in is the part of the ACE label that is generated by the encoding steps in
[AMC-ACE-Z]. [AMC-ACE-Z].
6. Implications for typical applications using DNS 6. Implications for typical applications using DNS
In IDNA, applications perform the processing needed to input In IDNA, applications perform the processing needed to input
internationalized host names from users, display internationalized internationalized host names from users, display internationalized
skipping to change at line 342 skipping to change at line 343
document format allows transmission of the characters in IDN host name document format allows transmission of the characters in IDN host name
labels, IDN host name labels SHOULD be transmitted using whatever labels, IDN host name labels SHOULD be transmitted using whatever
character encoding and escape mechanism that the protocol or document character encoding and escape mechanism that the protocol or document
format uses at that place. format uses at that place.
All protocols that have generic host name slots already have the All protocols that have generic host name slots already have the
capacity for handling host names in the ASCII charset. Thus, IDN host capacity for handling host names in the ASCII charset. Thus, IDN host
name labels that have been processed with the ToASCII operation can name labels that have been processed with the ToASCII operation can
inherently be handled by those protocols. inherently be handled by those protocols.
6.2 Applications and resolvers 6.2 Applications and resolver libraries
Applications communicate with resolver libraries through a programming Applications normally use functions in the operating system when they
interface (API). Typically, the IETF does not standardize APIs, although resolv DNS queries. Those functions in the operating system are often
there are non-standard APIs specified for IPv6. This protocol does not called "the resolver library", and the applications communicate with the
specify a specific API, but instead specifies the operations that must resolver libraries through a programming interface (API).
be used for input to and output from the resolver library.
An application MUST prepapre name parts that are sent in the DNS Because these resolver libraries today expect only hostnames in ASCII,
protocol using the ToASCII operation. Internationalized labels received applications MUST prepare name parts that are passed to the resolver
from the resolver will always be in ACE form. IDNA-aware applications library using the ToASCII operation. Internationalized labels receiver
MUST be able to work with both non-internationalized host name labels from the resolver library will always be in ACE form.
(those that conform to [STD13] and [STD3]) and internationalized host
name labels.
6.3 Resolvers and DNS servers IDNA-aware applications MUST be able to work with both
non-internationalized host name labels (those that conform to [STD13]
and [STD3]) and internationalized host name labels.
It is expected that new versions of the resolver libraries in the future
will be able to accept domain names in other formats than ASCII, and
application developers might one day pass not only domain names in
Unicode, but also in local script to a new API for the resolver
libraries in the operating system.
6.3 DNS servers
An operating system might have a set of libraries for performing the An operating system might have a set of libraries for performing the
ToASCII operation. The input to such a library might be in one or more ToASCII operation. The input to such a library might be in one or more
charsets that are used in applications (UTF-8 and UTF-16 are likely charsets that are used in applications (UTF-8 and UTF-16 are likely
candidates for almost any operating system, and script-specific charsets candidates for almost any operating system, and script-specific charsets
are likely for localized operating systems). are likely for localized operating systems).
DNS servers MUST use the ACE format for internationalized host labels. DNS servers MUST use the ACE format for internationalized host labels.
All internationalized names stored in DNS servers must be valid names All internationalized names stored in DNS servers MUST be valid names
that have been processed with the ToASCII operation. that have been processed with the ToASCII operation.
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 ACE 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.
6.4 Avoiding exposing users to the raw ACE encoding 6.4 Avoiding exposing users to the raw ACE encoding
skipping to change at line 416 skipping to change at line 424
The display of host names that contain bidirectional text is not covered The display of host names that contain bidirectional text is not covered
in this document. It may be covered in a future version of this in this document. It may be covered in a future version of this
document, or may be covered in a different document. document, or may be covered in a different document.
For developers interested in displaying host names that have For developers interested in displaying host names that have
bidirectional text, the Unicode standard has an extensive discussion of bidirectional text, the Unicode standard has an extensive discussion of
how to deal with reorder glyphs for display when dealing with how to deal with reorder glyphs for display when dealing with
bidirectional text such as Arabic or Hebrew. See [UAX9] for more bidirectional text such as Arabic or Hebrew. See [UAX9] for more
information. In particular, all Unicode text is stored in logical order. information. In particular, all Unicode text is stored in logical order.
6.6 DNSSEC authentication of IDNA hostnames
DNS Security [DNSSEC] is a method for supplying cryptographic
verification information along with DNS messages. Public Key
Cryptography is used in conjunction with digital signatures to provide a
means for a requester of domain information to authenticate the source
of the data. This ensures that it can be traced back to a trusted
source, either directly, or via a chain of trust linking the source of
the information to the top of the DNS hierarchy.
IDNA specifies that all internationalized host names stored in DNS
servers must be valid names processed with the ToASCII operation. This
processing must be complete prior to a zone being signed by the private
key for that zone. Because of this ordering, it is important to
recognize that DNSSEC authenticates the ACE-encoded resource, not the
internationalized hostname or the mapping between that hostname and its
ACE-encoding form. The canonical name, in other words, is the output of
ToASCII. In the presence of DNSSEC, this is the name that MUST be signed
in the zone and MUST be validated against. It also SHOULD be used for
other name comparisons, such as when a browser wants to indicate that a
URL has been previously visited.
One consequence of this for sites deploying IDNA in the presence of
DNSSEC is that any special purpose proxies or forwarders used to
transform user input into IDNA hostnames must be earlier in the
resolution flow than DNSSEC authenticating nameservers for DNSSEC to
work.
7. Name Server Considerations 7. Name Server Considerations
Internationalized host name data in zone files (as specified by section Internationalized host name data in zone files (as specified by section
5 of RFC 1035) MUST be processed with ToASCII before it is entered in 5 of RFC 1035) MUST be processed with ToASCII before it is entered in
the zone files. the zone files.
It is imperative that there be only one ASCII encoding for a particular It is imperative that there be only one ASCII encoding for a particular
host name. ACE is an encoding for host name labels that use non-ASCII host name. ACE is an encoding for host name labels that use non-ASCII
characters. Thus, a primary master name server MUST NOT contain an characters. Thus, a primary master name server MUST NOT contain an
ACE-encoded label that decodes to an ASCII label. The ToASCII operation ACE-encoded label that decodes to an ASCII label. The ToASCII operation
skipping to change at line 465 skipping to change at line 501
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.
A. References A. References
[AMC-ACE-Z] Adam Costello, "AMC-ACE-Z version 0.3.1", [AMC-ACE-Z] Adam Costello, "AMC-ACE-Z version 0.3.1",
draft-ietf-idn-amc-ace-z. draft-ietf-idn-amc-ace-z.
[DNSSEC] Don Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999.
[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of [NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep. Internationalized Host Names", draft-ietf-idn-nameprep.
[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.
[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989. and Support" (RFC 1123), STD 3, October 1989.
 End of changes. 9 change blocks. 
20 lines changed or deleted 59 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/