draft-ietf-idn-idna-03.txt

bind-3.2.

for the name parts that are sent to the resolver, and will always get
name parts encoded in ACE from the resolver.

IDNA-aware applications MUST be able to work with both
non-internationalized host name parts (those that conform to [STD13] and
[STD3]) and internationalized host name parts. An IDNA-aware application
that is resolving a non-internationalized host name part MUST NOT do
any preparation or conversion to ACE on any non-internationalized name
part.

2.1.3 Resolvers and DNS servers

An operating system might have a set of libraries for converting host
names to nameprepped ACE. 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
candidates for almost any operating system, and script-specific charsets
are likely for localized operating systems). The output would be either
the unchanged name part (if the input already conforms to [STD13] and
[STD3]), or the nameprepped, ACE-encoded name part.

DNS servers MUST use the ACE format for internationalized host name
parts.

If a signalling system which makes negotiation possible between old and
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
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
memo.

2.1.4 Avoiding exposing users to the raw ACE encoding

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
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
of resolution to users.

If an application decodes an ACE name but cannot show all of the
characters in the decoded name, such as if the name contains characters
that the output system cannot display, the application SHOULD show the
name in ACE format instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to transfer
the name correctly to other programs. Programs that by default show the
ACE form when they cannot show all the characters in a name part SHOULD
also have a mechanism to show the name with as many characters as
possible and replacement characters in the positions where characters
cannot be displayed. In many cases, the application doesn't know exactly
what the underlying rendering engine can or cannot display.

In addition to the condition above, if an application decodes an ACE
name but finds that the decoded name was not properly prepared according
to [NAMEPREP] (for example, if it has illegal characters in it), the
application SHOULD show the name in ACE format and SHOULD NOT display
the name in its decoded form. This is to avoid security issues described
in [NAMEPREP].

2.1.5 Automatic detection of ACE

An application which receives a host name SHOULD verify whether or not
the host name is in ACE. This is possible by verifying the prefix in
each of the labels, and seeing whether or not the label is in ACE. This
MUST be done regardless of whether or not the communication channel used
(such as keyboard input, cut and paste, application protocol,
application payload, and so on) is encoding with ACE.

The reason for this requirement is that many applications are not
ACE-aware. Applications that are not ACE-aware will send host names in
ACE but mark the charset as being US-ASCII or some other charset which
has the characters that are valid in [STD13] as a subset.

2.1.6 Bidirectional text

In IDNA, text storage and display follows the rules in the Unicode standard
[Unicode3.1]. In particular, all Unicode text is stored in logical order;
the Unicode standard has an extensive discussion of how to deal with reorder
glyphs for display when dealing with bidirectional text such as Arabic or
Hebrew. See [UAX9] for more information.


3. Name Server Considerations

It is imperative that there be only one encoding for a particular host
name. ACE is an encoding for host name parts that use characters outside
those allowed for host names [STD13]. Thus, a primary master name server
MUST NOT contain an ACE-encoded name that decodes to a host name that is
allowed in [STD13] and [STD3].

Name servers MUST NOT have any records with host names that contain
internationalized name parts unless those name parts have be prepared
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
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]
because requests always go through [NAMEPREP] before getting to the DNS.
Note that [NAMEPREP] describes how to handle versioning of unallocated
codepoints.

The host name data in zone files (as specified by section 5 of RFC 1035)
MUST be both nameprepped and ACE encoded.


4. Root Server Considerations

Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the DNS root servers.


5. Security Considerations

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

This memo describes an algorithm which encodes characters that are not
valid according to STD3 and STD13 into octet values that are valid. No
security issues such as string length increases or new allowed values
are introduced by the encoding process or the use of these encoded
values, apart from those introduced by the ACE encoding itself.

When detecting an ACE-encoded host name, and decoding the ACE, care must
be taken that the resulting value(s) are valid characters which can be
handled by the application. This is described in more detail in section
2.1.4.

Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
based on different interpretations of the internationalized host name.

Because this document normatively refers to [NAMEPREP], it includes the
security considerations from that document as well.


6. References

[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.

[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.

[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989.

[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
1034) and "Domain names - implementation and specification" (RFC 1035,
STD 13, November 1987.

[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm.
http://www.unicode.org/unicode/reports/tr9/

[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode
Consortium. The Unicode Standard, Version 3.0. Reading, MA,
Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended
by: Unicode Standard Annex #27: Unicode 3.1
<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.



B. Changes from the -02 draft

Editorial changes throughout

2.1.1: Major changes to the second paragraph. Added major text to fourth
paragraph.

2.1.4: Added to the end of the second paragraph. Added the third
paragraph.

2.1.6: Complete change.

6: Added [Unicode3.1] and [UAX9].


C. Authors' Addresses

Patrik Faltstrom
Cisco Systems
Arstaangsvagen 31 J
S-117 43 Stockholm  Sweden
[e-mail]

Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA  95060  USA
[e-mail]