draft-ietf-idn-idna-12.txt   draft-ietf-idn-idna-13.txt 
Internet Draft Patrik Faltstrom Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-12.txt Cisco draft-ietf-idn-idna-13.txt Cisco
Septebmer 25, 2002 Paul Hoffman October 4, 2002 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 Domain Names in Applications (IDNA) Internationalizing Domain 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 166 skipping to change at line 166
not valid internationalized labels. not valid internationalized labels.
An "internationalized domain name" (IDN) is a domain name in which every An "internationalized domain name" (IDN) is a domain name in which every
label is an internationalized label. This implies that every ASCII label is an internationalized label. This implies that every ASCII
domain name is an IDN. This document does not attempt to define an domain name is an IDN. This document does not attempt to define an
"internationalized host name". Just as has been the case with ASCII "internationalized host name". Just as has been the case with ASCII
names, some DNS zone administrators may impose restrictions, beyond names, some DNS zone administrators may impose restrictions, beyond
those imposed by DNS or IDNA, on the characters or strings that may be those imposed by DNS or IDNA, on the characters or strings that may be
registered as labels in their zones. Such restrictions have no impact on registered as labels in their zones. Such restrictions have no impact on
the syntax or semantics of DNS protocol messages; a query for a name the syntax or semantics of DNS protocol messages; a query for a name
that does not exist will yield the same response regardless of the that matches no records will yield the same response regardless of the
reason why it is not in the zone. Clients issuing queries or reason why it is not in the zone. Clients issuing queries or
interpreting responses cannot be assumed to have any knowledge of interpreting responses cannot be assumed to have any knowledge of
zone-specific restrictions or conventions. zone-specific restrictions or conventions.
In IDNA, equivalence of labels is defined in terms of the ToASCII In IDNA, equivalence of labels is defined in terms of the ToASCII
operation, which constructs an ASCII form for a given label, whether or operation, which constructs an ASCII form for a given label, whether or
not the label was already an ASCII label. Labels are defined to be not the label was already an ASCII label. Labels are defined to be
equivalent if and only if their ASCII forms produced by ToASCII match equivalent if and only if their ASCII forms produced by ToASCII match
using a case-insensitive ASCII comparison. ASCII labels already have a using a case-insensitive ASCII comparison. ASCII labels already have a
notion of equivalence: upper case and lower case are considered notion of equivalence: upper case and lower case are considered
skipping to change at line 812 skipping to change at line 812
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
Adam M. Costello Adam M. Costello
University of California, Berkeley University of California, Berkeley
idna-spec.amc @ nicemice.net idna-spec.amc @ nicemice.net
A. Changes from -11 to -12 A. Changes from -12 to -13
[[ To be removed when published as an RFC ]] [[ To be removed when published as an RFC ]]
In section 2, clarified the definitions for "internationalized domain In section 2, in the definition of "internationalized domain name",
name", "internationalized label", and "ACE label". The new definitions changed "does not exist" to "matches no records".
consist of the three paragraphs now beginning with the one that starts
'An "internationalized label" is a...'.
In section 3.1, changed the first sentence of requirement 3 from:
ACE labels obtained from domain name slots SHOULD be hidden from
users except when the use of the non-ASCII form would cause problems
or when the ACE form is explicitly requested.
to:
ACE labels obtained from domain name slots SHOULD be hidden from
users when it is known that the environment can handle the non-ACE
form, except when the ACE form is explicitly requested. When it is
not known whether or not the environment can handle the non-ACE form,
the application MAY use the non-ACE form (which might fail, such as
by not being displayed properly), or it MAY use the ACE form (which
will look unintelligle to the user).
In section 6.1, reworded the second paragraph to make the
cross-reference to section 6.4 more clear.
Added new security considerations paragraph to the end of section 10.
Added the IANA considerations in section 11.
 End of changes. 4 change blocks. 
4 lines changed or deleted 4 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/