draft-ietf-idnabis-protocol-03.txt   draft-ietf-idnabis-protocol-04.txt 
Network Working Group J. Klensin Network Working Group J. Klensin
Obsoletes: 3490 (if approved) Obsoletes: 3490 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 28, 2009 Expires: March 16, 2009
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-03.txt draft-ietf-idnabis-protocol-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 28, 2009. This Internet-Draft will expire on March 16, 2009.
Abstract Abstract
This document supplies the protocol definition for a revised and This document supplies the protocol definition for a revised and
updated specification for internationalized domain names (IDNs). The updated specification for internationalized domain names (IDNs). The
rationale for these changes, the relationship to the older rationale for these changes, the relationship to the older
specification, and important terminology are provided in other specification, and important terminology are provided in other
documents. This document specifies the protocol mechanism, called documents. This document specifies the protocol mechanism, called
Internationalizing Domain Names in Applications (IDNA), for Internationalizing Domain Names in Applications (IDNA), for
registering and looking up IDNs in a way that does not require registering and looking up IDNs in a way that does not require
changes to the DNS itself. IDNA is only meant for processing domain changes to the DNS itself. IDNA is only meant for processing domain
names, not free text. names, not free text.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 4 1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements and Applicability . . . . . . . . . . . . . . . . 5 3. Requirements and Applicability . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 6 3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 5
3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 6 3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 5
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 6 4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 5
4.1. Proposed label . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Proposed label . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Conversion to Unicode and Normalization . . . . . . . . . 7 4.2. Conversion to Unicode and Normalization . . . . . . . . . 6
4.3. Permitted Character and Label Validation . . . . . . . . . 7 4.3. Permitted Character and Label Validation . . . . . . . . . 6
4.3.1. Rejection of Characters that are not Permitted . . . . 7 4.3.1. Rejection of Characters that are not Permitted . . . . 6
4.3.2. Label Validation . . . . . . . . . . . . . . . . . . . 7 4.3.2. Label Validation . . . . . . . . . . . . . . . . . . . 7
4.3.3. Registration Validation Summary . . . . . . . . . . . 8 4.3.3. Registration Validation Summary . . . . . . . . . . . 7
4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 9 4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 8
4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 9 4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 8
4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 9 4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 8
5. Domain Name Resolution (Lookup) Protocol . . . . . . . . . . . 9 5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 8
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10 5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 9
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 9
5.3. Character Changes in Preprocessing or the User 5.3. Character Changes in Preprocessing or the User
Interface . . . . . . . . . . . . . . . . . . . . . . . . 10 Interface . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 11 5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Validation and Character List Testing . . . . . . . . . . 11 5.5. Validation and Character List Testing . . . . . . . . . . 10
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13 5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 12
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13 5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 12
6. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 6. Name Server Considerations . . . . . . . . . . . . . . . . . . 12
6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 13 6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 12
6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 13 6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 12
6.3. Root and other DNS Server Considerations . . . . . . . . . 14 6.3. Root and other DNS Server Considerations . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Changes between Version -00 and -01 of 9.1. Changes between Version -00 and -01 of
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 15 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 14
9.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 14
9.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 16 9.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. The Contextual Rules Registry . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix B. Contextual Rules Registry - Alternate Syntax . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.1. HYPHEN-MINUS . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 19
B.2. ZERO WIDTH NON-JOINER . . . . . . . . . . . . . . . . . . 23
B.3. ZERO WIDTH JOINER . . . . . . . . . . . . . . . . . . . . 24
B.4. MIDDLE DOT . . . . . . . . . . . . . . . . . . . . . . . . 24
B.5. GREEK LOWER NUMERAL SIGN (KERAIA) . . . . . . . . . . . . 25
B.6. MODIFIER LETTER PRIME . . . . . . . . . . . . . . . . . . 25
B.7. COMBINING CYRILLIC TITLO . . . . . . . . . . . . . . . . . 26
B.8. HEBREW PUNCTUATION GERESH . . . . . . . . . . . . . . . . 26
B.9. HEBREW PUNCTUATION GERSHAYIM . . . . . . . . . . . . . . . 26
B.10. IDEOGRAPHIC ITERATION MARK; . . . . . . . . . . . . . . . 27
B.11. VERTICAL IDEOGRAPHIC ITERATION MARK . . . . . . . . . . . 27
B.12. KATAKANA MIDDLE DOT . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
This document supplies the protocol definition for a revised and This document supplies the protocol definition for a revised and
updated specification for internationalized domain names. The updated specification for internationalized domain names. The
rationale for these changes and relationship to the older rationale for these changes and relationship to the older
specification and some new terminology is provided in other specification and some new terminology is provided in other
documents, notably [IDNA2008-Rationale]. documents, notably [IDNA2008-Rationale].
IDNA works by allowing applications to use certain ASCII string IDNA works by allowing applications to use certain ASCII string
skipping to change at page 6, line 48 skipping to change at page 5, line 48
email address part of the SOA RDATA would require action in other email address part of the SOA RDATA would require action in other
standards, specifically those that specify the format of the SOA RR. standards, specifically those that specify the format of the SOA RR.
4. Registration Protocol 4. Registration Protocol
This section defines the procedure for registering an IDN. The This section defines the procedure for registering an IDN. The
procedure is implementation independent; any sequence of steps that procedure is implementation independent; any sequence of steps that
produces exactly the same result for all labels is considered a valid produces exactly the same result for all labels is considered a valid
implementation. implementation.
Note that, while the registration and lookup protocols (Section 5)
are very similar in most respects, they are different and
implementers should carefully follow the steps they are implementing.
4.1. Proposed label 4.1. Proposed label
The registrant submits a request for an IDN. The user typically The registrant submits a request for an IDN. The user typically
produces the request string by the keyboard entry of a character produces the request string by the keyboard entry of a character
sequence in the local native character set (which might, of course, sequence in the local native character set (which might, of course,
be Unicode). The registry MAY permit submission of labels in A-label be Unicode). The registry MAY permit submission of labels in A-label
form. If it does so, it SHOULD perform a conversion to a U-label, form. If it does so, it SHOULD perform a conversion to a U-label,
perform the steps and tests described below, and verify that the perform the steps and tests described below, and verify that the
A-label produced by the step in Section 4.5 matches the one provided A-label produced by the step in Section 4.5 matches the one provided
as input. If, for some reason, it does not, the registration MUST be as input. If, for some reason, it does not, the registration MUST be
skipping to change at page 8, line 28 skipping to change at page 7, line 34
Each code point is checked for its identification as characters Each code point is checked for its identification as characters
requiring contextual processing for registration (the list of requiring contextual processing for registration (the list of
characters appears as the combination of CONTEXTJ and CONTEXTO in characters appears as the combination of CONTEXTJ and CONTEXTO in
[IDNA2008-Tables]). If that indication appears, the table of [IDNA2008-Tables]). If that indication appears, the table of
contextual rules is checked for a rule for that character. If no contextual rules is checked for a rule for that character. If no
rule is found, the proposed label is rejected and MUST NOT be rule is found, the proposed label is rejected and MUST NOT be
installed in a zone file. If one is found, it is applied (typically installed in a zone file. If one is found, it is applied (typically
as a test on the entire label or on adjacent characters). If the as a test on the entire label or on adjacent characters). If the
application of the rule does not conclude that the character is valid application of the rule does not conclude that the character is valid
in context, the proposed label MUST BE rejected. (See the IANA in context, the proposed label MUST BE rejected. (See the IANA
Considerations: IDNA Context Registry section of [IDNA2008-Rationale] Considerations: IDNA Context Registry section of
and Appendix A of this document.) [IDNA2008-Rationale].)
4.3.2.4. Labels Containing Characters Written Right to Left 4.3.2.4. Labels Containing Characters Written Right to Left
Additional special tests for right-to-left strings are applied (See Additional special tests for right-to-left strings are applied (See
[IDNA2008-BIDI]. Strings that contain right to left characters that [IDNA2008-BIDI]. Strings that contain right to left characters that
do not conform to the rule(s) identified there MUST NOT be inserted do not conform to the rule(s) identified there MUST NOT be inserted
in zone files. as labels in zone files.
[[anchor15: If the bidi specification continues to specify checking
more than one label, this subsection will need to be revised and/or
moved to a separate "FQDN validation" section.]]
4.3.3. Registration Validation Summary 4.3.3. Registration Validation Summary
Strings that have been produced by the steps above, and whose Strings that have been produced by the steps above, and whose
contents pass the above tests, are U-labels. contents pass the above tests, are U-labels.
To summarize, tests are made here for invalid characters, invalid To summarize, tests are made here for invalid characters, invalid
combinations of characters, and for labels that are invalid even if combinations of characters, and for labels that are invalid even if
the characters they contain are valid individually. For example, the characters they contain are valid individually. For example,
labels containing invisible ("zero-width") characters may be labels containing invisible ("zero-width") characters may be
permitted in context with characters whose presentation forms are permitted in context with characters whose presentation forms are
significantly changed by the presence or absence of the zero-width significantly changed by the presence or absence of the zero-width
characters, while other labels in which zero-width characters appear characters, while other labels in which zero-width characters appear
may be rejected. may be rejected.
[[anchor17: Should the example text be removed or moved? Note that [[anchor16: Should the example text be removed or moved? Note that
I've been strongly encouraged to supply specific examples to reduce I've been strongly encouraged to supply specific examples to reduce
abstraction and questions about the appropriateness of the text. abstraction and questions about the appropriateness of the text.
-JcK]] -JcK]]
4.4. Registry Restrictions 4.4. Registry Restrictions
Registries at all levels of the DNS, not just the top level, are Registries at all levels of the DNS, not just the top level, are
expected to establish policies about the labels that may be expected to establish policies about the labels that may be
registered, and for the processes associated with that action. While registered, and for the processes associated with that action. While
exact policies are not specified as part of IDNA2008 and it is exact policies are not specified as part of IDNA2008 and it is
expected that different registries may specify different policies, expected that different registries may specify different policies,
there SHOULD be policies. These per-registry policies and there SHOULD be policies. Even a trivial policy (e.g., "anything can
restrictions are an essential element of the IDNA registration be registered in this zone that can be represented as an A-label -
protocol even for registries (and corresponding zone files) deep in U-label pair") has value because it provides notice to users and
the DNS hierarchy. As discussed in [IDNA2008-Rationale], such applications implementers that the registry cannot be relied upon to
restrictions have always existed in the DNS. provide even minimal user-protection restrictions. These per-
registry policies and restrictions are an essential element of the
IDNA registration protocol even for registries (and corresponding
zone files) deep in the DNS hierarchy. As discussed in
[IDNA2008-Rationale], such restrictions have always existed in the
DNS.
The string produced by the above steps is checked and processed as The string produced by the above steps is checked and processed as
appropriate to local registry restrictions. Application of those appropriate to local registry restrictions. Application of those
registry restrictions may result in the rejection of some labels or registry restrictions may result in the rejection of some labels or
the application of special restrictions to others. the application of special restrictions to others.
4.5. Punycode Conversion 4.5. Punycode Conversion
The resulting U-label is converted to an A-label (i.e., the encoding The resulting U-label is converted to an A-label (i.e., the encoding
of that label according to the Punycode algorithm [RFC3492] with the of that label according to the Punycode algorithm [RFC3492] with the
ACE prefix added, i.e., the "xn--..." form). ACE prefix added, i.e., the "xn--..." form).
[[anchor18: Explain why 3492 failures cannot occur or explain what to [[anchor17: Explain why 3492 failures cannot occur or explain what to
do if they do.]] do if they do.]]
4.6. Insertion in the Zone 4.6. Insertion in the Zone
The A-label is registered in the DNS by insertion into a zone. The A-label is registered in the DNS by insertion into a zone.
5. Domain Name Resolution (Lookup) Protocol 5. Domain Name Lookup Protocol
Resolution is conceptually different from registration and different Lookup is conceptually different from registration and different
tests are applied on the client. Although some validity checks are tests are applied on the client. Although some validity checks are
necessary to avoid serious problems with the protocol (see necessary to avoid serious problems with the protocol (see
Section 5.5 ff.), the resolution-side tests are more permissive and Section 5.5 ff.), the lookup-side tests are more permissive and rely
rely heavily on the assumption that names that are present in the DNS heavily on the assumption that names that are present in the DNS are
are valid. valid.
5.1. Label String Input 5.1. Label String Input
The user supplies a string in the local character set, typically by The user supplies a string in the local character set, typically by
typing it or clicking on, or copying and pasting, a resource typing it or clicking on, or copying and pasting, a resource
identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the
domain name is extracted. Or some process not directly involving the domain name is extracted. Or some process not directly involving the
user may read the string from a file or obtain it in some other way. user may read the string from a file or obtain it in some other way.
Processing in this step and the next two are local matters, to be Processing in this step and the next two are local matters, to be
accomplished prior to actual invocation of IDNA, but at least these accomplished prior to actual invocation of IDNA, but at least these
skipping to change at page 10, line 25 skipping to change at page 9, line 30
5.2. Conversion to Unicode 5.2. Conversion to Unicode
The string is converted from the local character set into Unicode, if The string is converted from the local character set into Unicode, if
it is not already Unicode. The exact nature of this conversion is it is not already Unicode. The exact nature of this conversion is
beyond the scope of this document, but may involve normalization, as beyond the scope of this document, but may involve normalization, as
described in Section 4.2. described in Section 4.2.
5.3. Character Changes in Preprocessing or the User Interface 5.3. Character Changes in Preprocessing or the User Interface
The Unicode string MAY then be processed, in a way specific to the The Unicode string MAY then be processed to prevent confounding of
local environment, to make the result of the IDNA processing match
user expectations. For instance, it would be reasonable, at this user expectations. For instance, it would be reasonable, at this
step, to convert all upper case characters to lower case, if this step, to convert all upper case characters to lower case, if this
makes sense in the user's environment. makes sense in the user's environment. The procedures described in
this section are ordinarily useful only for processing direct user
input and when needed for backward compatibility with IDNA2003. In
general, IDNs appearing in files and those transmitted across the
network as part of protocols are expected to be in either ASCII form
(including A-labels) or to contain U-labels, not forms requiring
mapping or other conversions.
Other examples of processing for localization might be applied, if Other examples of processing for localization might be applied,
appropriate, at this point. They include interpreting various especially to direct user input, at this point. They include
characters as separating domain name components from each other interpreting various characters as separating domain name components
(label separators) because they either look like periods or are used from each other (label separators) because they either look like
to separate sentences, mapping different "width" forms of the same periods or are used to separate sentences, mapping halfwidth or
character into the one form permitted in labels[[anchor20: This needs fullwidth East Asian characters to the common form permitted in
clarification]], or giving special treatment to characters whose labels, or giving special treatment to characters whose presentation
presentation forms are dependent only on placement in the label. forms are dependent only on placement in the label. Such
Such localization changes are also outside the scope of this localization changes are also outside the scope of this
specification. specification.
Recommendations for preprocessing for global contexts (i.e., when Recommendations for preprocessing for global contexts (i.e., when
local considerations do not apply or cannot be used) and for maximum local considerations do not apply or cannot be used) and for maximum
interoperability with labels that might have been specified under interoperability with labels that might have been specified under
liberal readings of IDNA2003 are given in [IDNA2008-Rationale]. liberal readings of IDNA2003 are given in [IDNA2008-Rationale]. It
is important to note that the intent of these specifications is that
[[anchor21: The question of preprocessing remains controversial in labels in application protocols, files, or links are intended to be
the WG. One school of thought is that, for compatibility with in U-label or A-label form. Preprocessing MUST NOT map a character
IDNA2003, preprocessing should be standardized and required, with that is valid in a label (i.e., one that is PROTOCOL-VALID or
only one form permitted. Another sees important advantages in having permitted in any context) into another character. Excessively
the mappings between U-labels and A-labels be symmetric, unambiguous, liberal use of preprocessing, especially to strings stored in files,
and information-preserving. And a third believes that local mappings poses a threat to consistent and predictable behavior for the user
will occur regardless of what we specify and that it is better to even if not to actual interoperability.
specify the protocol on that basis than to indirectly encourage local
inventions. The first group (and perhaps others) believe that local
mappings will be, to put it mildly, "very bad... for
interoperability.]]
Because these transformations are local, it is important that domain Because these transformations are local, it is important that domain
names that might be passed between systems (e.g., in IRIs) be names that might be passed between systems (e.g., in IRIs) be
U-labels or A-labels and not forms that might be accepted locally as U-labels or A-labels and not forms that might be accepted locally as
a consequence of this step. This step is not standardized as part of a consequence of this step. This step is not standardized as part of
IDNA, and is not further specified here. IDNA, and is not further specified here.
5.4. A-label Input 5.4. A-label Input
If the input to this procedure appears to be an A-label (i.e., it If the input to this procedure appears to be an A-label (i.e., it
skipping to change at page 11, line 38 skipping to change at page 10, line 46
form (this requires that the lookup application be IDNA-aware). form (this requires that the lookup application be IDNA-aware).
Applications that are not IDNA-aware will obviously omit that Applications that are not IDNA-aware will obviously omit that
testing; others may treat the string as opaque to avoid the testing; others may treat the string as opaque to avoid the
additional processing at the expense of providing less protection and additional processing at the expense of providing less protection and
information to users. information to users.
5.5. Validation and Character List Testing 5.5. Validation and Character List Testing
As with the registration procedure, the Unicode string is checked to As with the registration procedure, the Unicode string is checked to
verify that all characters that appear in it are valid for IDNA verify that all characters that appear in it are valid for IDNA
resolution input. As discussed above and in [IDNA2008-Rationale], lookup processing input. As discussed above and in
the resolution check is more liberal than the registration one. [IDNA2008-Rationale], the lookup check is more liberal than the
Putative labels with any of the following characteristics MUST BE registration one. Putative labels with any of the following
rejected prior to DNS lookup: characteristics MUST BE rejected prior to DNS lookup:
o Labels containing code points that are unassigned in the version o Labels containing code points that are unassigned in the version
of Unicode being used by the application, i.e., in the of Unicode being used by the application, i.e., in the
"Unassigned" Unicode category or the UNASSIGNED category of "Unassigned" Unicode category or the UNASSIGNED category of
[IDNA2008-Tables]. [IDNA2008-Tables].
o Labels that are not in NFC form. o Labels that are not in NFC form.
o Labels containing prohibited code points, i.e., those that are o Labels containing prohibited code points, i.e., those that are
assigned to the "DISALLOWED" category in the permitted character assigned to the "DISALLOWED" category in the permitted character
skipping to change at page 12, line 20 skipping to change at page 11, line 27
present. present.
o Labels containing other code points that are shown in the o Labels containing other code points that are shown in the
permitted character table as requiring a contextual rule permitted character table as requiring a contextual rule
("CONTEXTO" in the tables), but for which no such rule appears in ("CONTEXTO" in the tables), but for which no such rule appears in
the table of rules. With the exception in the rule immediately the table of rules. With the exception in the rule immediately
above, applications resolving DNS names or carrying out equivalent above, applications resolving DNS names or carrying out equivalent
operations are not required to test contextual rules, only to operations are not required to test contextual rules, only to
verify that a rule exists. verify that a rule exists.
o Labels whose first character is a combining mark. [[anchor23: Note o Labels whose first character is a combining mark.>
in Draft: this definition may need to be further tightened.]]
In addition, the application SHOULD apply the following test. The In addition, the application SHOULD apply the following test. The
test may be omitted in special circumstances, such as when the test may be omitted in special circumstances, such as when the lookup
resolver application knows that the conditions are enforced application knows that the conditions are enforced elsewhere, because
elsewhere, because an attempt to resolve such strings will almost an attempt to look up and resolve such strings will almost certainly
certainly lead to a DNS lookup failure. However, applying the test lead to a DNS lookup failure. However, applying the test is likely
is likely to give much better information about the reason for a to give much better information about the reason for a lookup failure
lookup failure -- information that may be usefully passed to the user -- information that may be usefully passed to the user when that is
when that is feasible -- then DNS resolution failure alone. In any feasible -- then DNS resolution failure information alone. In any
event, resolvers should avoid looking up labels that are invalid event, lookup applications should avoid attempting to resolve labels
under that test. that are invalid under that test.
[[anchor24: Should this be a MUST? Pro: this is the only remaining
SHOULD (true?), the test is relatively straightforward, and it helps
avoid visual ambiguity. Con: the "special circumstances" that might
justify doing something different are explained above.]]
o Verification that the string is compliant with the requirements o Verification that the string is compliant with the requirements
for right to left characters, specified in [IDNA2008-BIDI]. for right to left characters, specified in [IDNA2008-BIDI].
For all other strings, the resolver MUST rely on the presence or For all other strings, the lookup application MUST rely on the
absence of labels in the DNS to determine the validity of those presence or absence of labels in the DNS to determine the validity of
labels and the validity of the characters they contain. If they are those labels and the validity of the characters they contain. If
registered, they are presumed to be valid; if they are not, their they are registered, they are presumed to be valid; if they are not,
possible validity is not relevant. A resolver that declines to look their possible validity is not relevant. A lookup application that
up a string that conforms to the above rules is not in conformance declines to process and resolve up a string that conforms to the
with this protocol. above rules is not in conformance with this protocol.
5.6. Punycode Conversion 5.6. Punycode Conversion
The validated string, a U-label, is converted to an A-label using the The validated string, a U-label, is converted to an A-label using the
Punycode algorithm with the ACE prefix added. Punycode algorithm with the ACE prefix added.
5.7. DNS Name Resolution 5.7. DNS Name Resolution
The A-label is looked up in the DNS, using normal DNS procedures. The A-label is looked up in the DNS, using normal DNS resolver
procedures.
6. Name Server Considerations 6. Name Server Considerations
6.1. Processing Non-ASCII Strings 6.1. Processing Non-ASCII Strings
Existing DNS servers do not know the IDNA rules for handling non- Existing DNS servers do not know the IDNA rules for handling non-
ASCII forms of IDNs, and therefore need to be shielded from them. ASCII forms of IDNs, and therefore need to be shielded from them.
All existing channels through which names can enter a DNS server All existing channels through which names can enter a DNS server
database (for example, master files (as described in RFC 1034) and database (for example, master files (as described in RFC 1034) and
DNS update messages [RFC2136]) are IDN-unaware because they predate DNS update messages [RFC2136]) are IDN-unaware because they predate
skipping to change at page 14, line 17 skipping to change at page 13, line 18
A-label form. Conversion to A-labels must be performed prior to a A-label form. Conversion to A-labels must be performed prior to a
zone being signed by the private key for that zone. Because of this zone being signed by the private key for that zone. Because of this
ordering, it is important to recognize that DNSSEC authenticates a ordering, it is important to recognize that DNSSEC authenticates a
domain name containing A-labels or conventional LDH-labels, not domain name containing A-labels or conventional LDH-labels, not
U-labels. In the presence of DNSSEC, no form of a zone file or query U-labels. In the presence of DNSSEC, no form of a zone file or query
response that contains a U-label may be signed or the signature response that contains a U-label may be signed or the signature
validated. validated.
One consequence of this for sites deploying IDNA in the presence of One consequence of this for sites deploying IDNA in the presence of
DNSSEC is that any special purpose proxies or forwarders used to DNSSEC is that any special purpose proxies or forwarders used to
transform user input into IDNs must be earlier in the resolution flow transform user input into IDNs must be earlier in the lookup flow
than DNSSEC authenticating nameservers for DNSSEC to work. than DNSSEC authenticating nameservers for DNSSEC to work.
6.3. Root and other DNS Server Considerations 6.3. Root and other DNS Server Considerations
IDNs in A-label form will generally be somewhat longer than current IDNs in A-label form will generally be somewhat longer than current
domain names, so the bandwidth needed by the root servers is likely domain names, so the bandwidth needed by the root servers is likely
to go up by a small amount. Also, queries and responses for IDNs to go up by a small amount. Also, queries and responses for IDNs
will probably be somewhat longer than typical queries historically, will probably be somewhat longer than typical queries historically,
so EDNS0 [RFC2671] support may be more important (otherwise, queries so EDNS0 [RFC2671] support may be more important (otherwise, queries
and responses may be forced to go to TCP instead of UDP). and responses may be forced to go to TCP instead of UDP).
skipping to change at page 15, line 20 skipping to change at page 14, line 22
The introduction of IDNA means that any existing labels that start The introduction of IDNA means that any existing labels that start
with the ACE prefix would be construed as A-labels, at least until with the ACE prefix would be construed as A-labels, at least until
they failed one of the relevant tests, whether or not that was the they failed one of the relevant tests, whether or not that was the
intent of the zone administrator or registrant. There is no evidence intent of the zone administrator or registrant. There is no evidence
that this has caused any practical problems since RFC 3490 was that this has caused any practical problems since RFC 3490 was
adopted, but the risk still exists in principle. adopted, but the risk still exists in principle.
8. IANA Considerations 8. IANA Considerations
IANA actions for this version of IDNA are specified in IANA actions for this version of IDNA are specified in
[IDNA2008-Rationale]. [IDNA2008-Rationale]. The component of IDNA described in this
document does not require any IANA actions.
9. Change Log 9. Change Log
[[anchor30: RFC Editor: Please remove this section.]] [[anchor24: RFC Editor: Please remove this section.]]
9.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol 9.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol
o Corrected discussion of SRV records. o Corrected discussion of SRV records.
o Several small corrections for clarity. o Several small corrections for clarity.
o Inserted more "open issue" placeholders. o Inserted more "open issue" placeholders.
9.2. Version -02 9.2. Version -02
skipping to change at page 16, line 17 skipping to change at page 15, line 17
o Trimmed change log, removing information about pre-WG drafts. o Trimmed change log, removing information about pre-WG drafts.
o Incorporated a number of changes suggested by Marcos Sanz in his o Incorporated a number of changes suggested by Marcos Sanz in his
note of 2008.07.17 and added several more placeholder anchors. note of 2008.07.17 and added several more placeholder anchors.
o Several minor editorial corrections and improvements. o Several minor editorial corrections and improvements.
o "Editor" designation temporarily removed because the automatic o "Editor" designation temporarily removed because the automatic
posting machinery does not accept it. posting machinery does not accept it.
9.4. Version -04
o Removed Contextual Rule appendices for transfer to Tables.
o Several changes, including removal of discussion anchors, based on
discussions at IETF 72 (Dublin)
o Rewrote the preprocessing material (Section 5.3) somewhat.
10. Contributors 10. Contributors
While the listed editor held the pen, the original versions of this While the listed editor held the pen, the original versions of this
document represent the joint work and conclusions of an ad hoc design document represent the joint work and conclusions of an ad hoc design
team consisting of the editor and, in alphabetic order, Harald team consisting of the editor and, in alphabetic order, Harald
Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. This document Alvestrand, Tina Dam, Patrik Faltstrom, and Cary Karp. This document
draws significantly on the original version of IDNA [RFC3490] both draws significantly on the original version of IDNA [RFC3490] both
conceptually and for specific text. This second-generation version conceptually and for specific text. This second-generation version
would not have been possible without the work that went into that would not have been possible without the work that went into that
first version and its authors, Patrik Faltstrom, Paul Hoffman, and first version and its authors, Patrik Faltstrom, Paul Hoffman, and
skipping to change at page 16, line 43 skipping to change at page 16, line 6
This revision to IDNA would have been impossible without the This revision to IDNA would have been impossible without the
accumulated experience since RFC 3490 was published and resulting accumulated experience since RFC 3490 was published and resulting
comments and complaints of many people in the IETF, ICANN, and other comments and complaints of many people in the IETF, ICANN, and other
communities, too many people to list here. Nor would it have been communities, too many people to list here. Nor would it have been
possible without RFC 3490 itself and the efforts of the Working Group possible without RFC 3490 itself and the efforts of the Working Group
that defined it. Those people whose contributions are acknowledged that defined it. Those people whose contributions are acknowledged
in RFC 3490, [RFC4690], and [IDNA2008-Rationale] were particularly in RFC 3490, [RFC4690], and [IDNA2008-Rationale] were particularly
important. important.
Specific textual changes were incorporated into this document after Specific textual changes were incorporated into this document after
suggestions from Stephane Bortzmeyer, Mark Davis, and others. suggestions from Stephane Bortzmeyer, Mark Davis, Paul Hoffman,
Marcos Sanz and others.
12. References 12. References
12.1. Normative References 12.1. Normative References
[IDNA2008-BIDI] [IDNA2008-BIDI]
Alvestrand, H. and C. Karp, "An updated IDNA criterion for Alvestrand, H. and C. Karp, "An updated IDNA criterion for
right-to-left scripts", July 2008, <https:// right-to-left scripts", July 2008, <https://
datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>. datatracker.ietf.org/drafts/draft-ietf-idnabis-bidi/>.
skipping to change at page 19, line 13 skipping to change at page 18, line 20
(IDNs)", RFC 4690, September 2006. (IDNs)", RFC 4690, September 2006.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007. Internationalized Email", RFC 4952, July 2007.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
5.0", 2007. 5.0", 2007.
Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0 Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
Appendix A. The Contextual Rules Registry
[[anchor38: Note in Draft: The WG seems to be concluding that this
material should actually be in the Tables document, possibly with
some additional material added from Rationale. Unless there are
objections and consensus on some other plan, that move will be made
with -03 of this document. Regardless of where they are placed, the
WG will still need to review the specific content of the rules. In
this version of the document, the table remains something of a
illustrative placeholder, not a final specification.]]
[[anchor39: The next appendix sketches out an alternate way to
present this information. See the notes there.]]
As discussed in the IANA Considerations section of
[IDNA2008-Rationale], a registry of rules that define the contexts in
which particular PROTOCOL-VALID characters, characters associated
with a requirement for Contextual Information, are permitted. These
rules are expressed as tests on the label in which the characters
appear (all, or any part of, the label may be tested). [[anchor40:
Probably the IANA registry spec should be moved directly from
Rationale to Tables -- see above.]]
For each character specified as requiring a contextual rule, a rule
MAY be established with the following data elements:
1. The code point associated with the character.
2. The name of the character.
3. An indication as to whether the code point requires the rule be
processed at lookup time (this indication is equivalent to the
difference between "CONTEXTJ" and "CONTEXTO" in the tables
document [IDNA2008-Tables]).
4. A prose description of the contextual rule.
5. A description of the contextual rule using Unicode Regular
Expression notation [Unicode-RegEx]. Only a Level 1
implementation is needed for the expressions below, which also
make reference to the Unicode Script definition [Unicode-Scripts]
and the Unicode Property Value Aliases list
[Unicode-PropertyValueAliases]. Note that in these regular
expressions, the label is taken to be an entire line, i.e., "^"
refers to the beginning of the label and "$" refers to the end of
the label.
These regular expressions are used as tests. The contextual
requirement is met if there is a match for the regular expression
and not met if there is no match.
[[anchor41: Patrik and I (JcK) would like to find a way to state
these rules that does not require the reader and implementer to
understand what we believe to be a fairly exotic element of the
Unicode specification. See the second Appendix for a possible
alternative. Suggestions welcome.]]
6. An optional comment preceded by "#"
Should there be any conflict between the two statements of a rule,
the regular expression form MUST be considered normative until the
registry can be corrected.
The rules for the characters listed in the Tables document as
exception cases or Join_Controls and for which rules are being
defined at this time appear below.
[[anchor42: Note in draft: This table is not complete and the rule
entries below are temporarily only examples.]]
002D; HYPHEN-MINUS; F;
Must not appear at the beginning or end of a label;
Regular expression:
[^^]\u002D|\u002D[^$] ;
# Note that there are some additional prohibitions in the
specification on consecutive hyphens in anything but a valid
A-label.
200C; ZERO WIDTH NON-JOINER; T;
Between two characters from the same script only. The script must
be one in which the use of this character causes significant
visual transformation of one or both of the adjacent characters;
Regular expression:
[\p(Script:Deva)\p(Script:Tamil)]\u200C[\p(Script:Deva)\p(Script:
Tamil)] ;
[[anchor43: That script list is _not_ complete and, in particular,
more Indic scripts certainly need to be listed. It also does not
correctly express the "same script" restriction mentioned in the
prose, since it only tests adjacent characters.]] This character
is also required for Arabic script. The minimal restriction is
\p(Joining_Type:L)\p(Joining_Type:T)*\u200C\p(Joining_Type:
T)*\p(Joining_Type:R) ;
; more narrow restrictions may be suggested by the Arabic script
group.
200D; ZERO WIDTH JOINER; T;
Between two characters from the same script only. The script must
be one in which the use of this character causes significant
visual transformation of one or both of the adjacent characters;
Regular expression:
[\p(Script:Deva)\p(Script:Tamil)]+
\u200D[\p(Script:Deva)\p(Script:Tamil)]+ ;
[[anchor44: That script list is _not_ complete and, in particular,
more Indic scripts certainly need to be listed. It also does not
correctly express the "same script" restriction mentioned in the
prose, since it only tests adjacent characters. This character is
not required for Arabic script.]]
00B7; MIDDLE DOT; F;
Between two 'l' (U+006C) characters only, used to permit the
Catalan character ela geminada to be expressed;
Regular expression:
\u006C\u00B7\u006C ;
0375; GREEK LOWER NUMERAL SIGN (KERAIA); F;
Greek script only. Might be further restricted to specific
following characters;
Regular expression:
\u0375\p(Script:Greek) ;
02B9; MODIFIER LETTER PRIME; F;;;
# Permitted only in contexts in which GREEK LOWER NUMERAL SIGN,
U+0375, is permitted. GREEK NUMERAL SIGN, U+0374, and the Lower
Numeral Sign (U+0375) are indicators for numeric use of letters in
older Greek writing systems. U+02B9 is relevant because
normalization maps U+0374 into it.;
Regular expression:
\p(Script:Greek)\u02B9\p(Script:Greek) ;
[[anchor45: The test is that the adjacent characters be in the
Greek script. It is not clear whether this is sufficient. The
requirement for a preceding Greek letter may not be necessary.
More input needed.]]
0483; COMBINING CYRILLIC TITLO; F;
Cyrillic script only. Might be further restricted to permit only
a preceding list of characters.
Regular expression:
\p(Script:Cyrillic)\u0483 ;
05F3; HEBREW PUNCTUATION GERESH; F;
The script of the preceding character and the subsequent
character, if any, MUST be Hebrew;
Regular expression:
\p(Script:Hebrew)\u05F3\p(Script:Hebrew)? ;
05F4; HEBREW PUNCTUATION GERSHAYIM; F
The script of the preceding character and the subsequent
character, if any, MUST be Hebrew;
Regular expression:
\p(Script:Hebrew)\u05F4\p(Script:Hebrew)? ;
3005; IDEOGRAPHIC ITERATION MARK; F;
MUST NOT be at the beginning of the label, and the previous
character MUST be in Han Script;
Regular expression:
\p(Script:Hani)\u3005 ;
303B; VERTICAL IDEOGRAPHIC ITERATION MARK; F;
MUST NOT be at the beginning of the label, and the previous
character MUST be in Han Script;
Regular expression:
\p(Script:Hani)\u303B ;
30FB; KATAKANA MIDDLE DOT; F;
Adjacent characters MUST be Katakana;
Regular expression:
\p(Script:Kana)\u30FB\p(Script:Kana) ;
While the information above is to be used to initialize the registry,
IANA should treat the table format in this Appendix simply as an
initial, tentative, suggestion. Subject to review and comment from
the IESG and any Expert Reviewers, IANA is responsible for, and
should develop, a format for that registry, or a copy of it
maintained in parallel, that is convenient for retrieval and machine
processing and publish the location of that version.
Appendix B. Contextual Rules Registry - Alternate Syntax
[[anchor46: This Appendix is temporary. It illustrates, for
discussion, a possible way of presenting the Contextual Rules as a
procedural pseudocode rule set rather than as a regular expression or
property list and also shows a bit of the layout suggested by Mark
Davis. Each entry consists of the name for identification, followed
by an informal description, the code point, and the rule set. Note
that the two appendices are alternate forms of the same information;
only one should be moved to Tablss; the other will be deleted.]]
[[anchor47: The grammatical rules and operations for the pseudocode
below are left as an exercise for the reader in this draft. Note
however that the "Before" and "After" operations, by themselves,
match anything including null, i.e., BeforeScript would match any
script if the character was the first one in the label. Obviously,
if something satisfies all of the rules, then it is contextually
valid. If any of them yield "False" than it isn't. If we decide to
go in this direction, we should form a small ad hoc committee to
either sort that out or possibly convert it to standard Prolog.]]
B.1. HYPHEN-MINUS
Code point: 002D
Overview: Must appear at the beginning or end of a label.
Lookup: False
Rule Set:
If FirstChar .eq. True Then False;
If LastChar .eq. Then False;
Else True;
Comment: Note that there are some additional prohibitions in the
specification on consecutive hyphens in anything but a valid
A-label.
B.2. ZERO WIDTH NON-JOINER
Code point: 200C
Overview: Between two characters from the same script only. The
script must be one in which the use of this character causes
significant visual transformation of one or both of the adjacent
characters.
Lookup: True
Rule Set:
If BeforeScript .eq. ( Deva | Tamil | Arabic ) Then
If AfterScript .eq. ( Deva | Tamil | Arabic ) Then True;
Else False;
[[anchor50: That script list is _not_ complete and, in particular,
more Indic scripts certainly need to be listed. It also does not
correctly express the "same script" restriction mentioned in the
prose, since it only tests adjacent characters.]]
This character is also required for Arabic script. The minimal
restriction (in regex form) is
\p(Joining_Type:L)\p(Joining_Type:T)*\u200C\p(Joining_Type:
T)*\p(Joining_Type:R) ;
; more narrow restrictions may be suggested by the Arabic script
group.
B.3. ZERO WIDTH JOINER
Code point: 200D
Overview: Between two characters from the same script only. The
script must be one in which the use of this character causes
significant visual transformation of one or both of the adjacent
characters.
Lookup: True
Rule Set:
If BeforeScript .eq. ( Deva | Tamil | Arabic ) Then
If AfterScript .eq. ( Deva | Tamil | Arabic ) Then True;
Else False;
[[anchor52: The script list for this character is _not_ complete
and, in particular, more Indic scripts certainly need to be
listed. It also does not correctly express the "same script"
restriction mentioned in the prose, since it only tests adjacent
characters. This character is not required for Arabic script.]]
B.4. MIDDLE DOT
Code point: 00B7
Overview: Between 'l' (U+006C) characters only, used to permit the
Catalan character ela geminada to be expressed
Lookup: False
Rule Set:
If BeforeChar .eq. \006C Then
If AfterChar .eq. \006C Then True;
Else False;
B.5. GREEK LOWER NUMERAL SIGN (KERAIA)
Code point: 0375
Overview: Greek script only. Might be further restricted to
specific following characters
Lookup: False
Rule Set:
If AfterScript .eq. Greek Then True;
Else False;
B.6. MODIFIER LETTER PRIME
Code point: 02B9
Overview: Permitted only in contexts in which GREEK LOWER NUMERAL
SIGN, U+0375, is permitted. GREEK NUMERAL SIGN, U+0374, and the
Lower Numeral Sign (U+0375) are indicators for numeric use of
letters in older Greek writing systems. U+02B9 is relevant
because normalization maps U+0374 into it.
Lookup: False
Rule Set:
BeforeScript If .eq. Greek Then
If AfterScript .eq. Greek Then True;
Else False;
Comment: [[anchor56: The test is that the adjacent characters be in
the Greek script. It is not clear whether this is sufficient.
The requirement for a preceding Greek letter may not be necessary.
More input needed.]]
B.7. COMBINING CYRILLIC TITLO
Code point: 0483
Overview: Cyrillic script only. Might be further restricted to
permit only a preceding list of characters.
Lookup: False
Rule Set:
If BeforeScript .eq. Cyrillic Then
If AfterScript .eq. Cyrillic Then True;
Else False;
B.8. HEBREW PUNCTUATION GERESH
Code point: 05F3
Overview: The script of the preceding character and the subsequent
character, if any, MUST be Hebrew.
Lookup: False
Rule Set:
If FirstChar .eq. True then False;
Else If BeforeScript .eq. Hebrew Then
If AfterScript .eq. Hebrew Then True;
Else False;
B.9. HEBREW PUNCTUATION GERSHAYIM
Code point: 05F4
Overview: The script of the preceding character and the subsequent
character, if any, MUST be Hebrew.
Lookup: False
Rule Set:
If FirstChar .eq. True then False;
Else If BeforeScript .eq. Hebrew Then
If AfterScript .eq. Hebrew Then True;
Else False;
B.10. IDEOGRAPHIC ITERATION MARK;
Code point: 3005
Overview: MUST NOT be at the beginning of the label, and the
previous character MUST be in Han Script.
Lookup: False
Rule Set:
If FirstChar .eq. True Then False;
Else If BeforeScript .eq. Han Then True;
Else False;
B.11. VERTICAL IDEOGRAPHIC ITERATION MARK
Code point: 303B
Overview: MUST NOT be at the beginning of the label, and the
previous character MUST be in Han Script.
Lookup: False
Rule Set:
If FirstChar .eq. True Then False;
Else If BeforeScript .eq. Han Then True;
Else False;
B.12. KATAKANA MIDDLE DOT
Code point: 30FB
Overview: Adjacent characters MUST be Katakana.
Lookup: False
Rule Set:
If FirstChar .eq. True Then False;
Else If BeforeScript .eq. Kana Then
If AfterScript .eq. Kana Then True;
Else False;
Author's Address Author's Address
John C Klensin John C Klensin
1770 Massachusetts Ave, Ste 322 1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 245 1457 Phone: +1 617 245 1457
Email: john+ietf@jck.com Email: john+ietf@jck.com
 End of changes. 32 change blocks. 
540 lines changed or deleted 133 lines changed or added

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