draft-ietf-idnabis-protocol-11.txt   draft-ietf-idnabis-protocol-12.txt 
Network Working Group J. Klensin Network Working Group J. Klensin
Obsoletes: 3490, 3491 Obsoletes: 3490, 3491
(if approved) (if approved)
Updates: 3492 (if approved) Updates: 3492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 10, 2009 Expires: November 9, 2009
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-11.txt draft-ietf-idnabis-protocol-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 September 10, 2009. This Internet-Draft will expire on November 9, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document supplies the protocol definition for a revised and This document is the revised protocol definition for
updated specification for internationalized domain names (IDNs). The internationalized domain names (IDNs). The rationale for changes,
rationale for these changes, the relationship to the older the relationship to the older specification, and important
specification, and important terminology are provided in other terminology are provided in other documents. This document specifies
documents. This document specifies the protocol mechanism, called the protocol mechanism, called Internationalizing Domain Names in
Internationalizing Domain Names in Applications (IDNA), for Applications (IDNA), for registering and looking up IDNs in a way
registering and looking up IDNs in a way that does not require that does not require changes to the DNS itself. IDNA is only meant
changes to the DNS itself. IDNA is only meant for processing domain for processing domain names, not free text.
names, not free text.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 5 1.1. Discussion Forum . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements and Applicability . . . . . . . . . . . . . . . . 6 3. Requirements and Applicability . . . . . . . . . . . . . . . . 6
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 7 3.2.1. DNS Resource Records . . . . . . . . . . . . . . . . . 7
3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 7 3.2.2. Non-domain-name Data Types Stored in the DNS . . . . . 7
4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 7 4. Registration Protocol . . . . . . . . . . . . . . . . . . . . 7
4.1. Input to IDNA Registration Process . . . . . . . . . . . . 8 4.1. Input to IDNA Registration Process . . . . . . . . . . . . 8
4.2. Permitted Character and Label Validation . . . . . . . . . 8 4.2. Permitted Character and Label Validation . . . . . . . . . 8
4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Input Format . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Rejection of Characters that are not Permitted . . . . 9 4.2.2. Rejection of Characters that are not Permitted . . . . 8
4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 9 4.2.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.2.4. Registration Validation Summary . . . . . . . . . . . 10 4.2.4. Registration Validation Summary . . . . . . . . . . . 9
4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10 4.3. Registry Restrictions . . . . . . . . . . . . . . . . . . 10
4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 11 4.4. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10
4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 11 4.5. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 11 5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 12 5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 11
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 12 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11
5.3. Character Changes in Preprocessing or the User 5.3. Character Changes in Preprocessing or the User
Interface . . . . . . . . . . . . . . . . . . . . . . . . 12 Interface . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 13 5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Validation and Character List Testing . . . . . . . . . . 14 5.5. Validation and Character List Testing . . . . . . . . . . 13
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 15 5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 14
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 15 5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Local Mapping Alternatives . . . . . . . . . . . . . 19 Appendix A. Local Mapping Alternatives . . . . . . . . . . . . . 18
A.1. Transitional Mapping Model . . . . . . . . . . . . . . . . 19 A.1. Transitional Mapping Model . . . . . . . . . . . . . . . . 18
A.1.1. Fallback Lookup . . . . . . . . . . . . . . . . . . . 20 A.1.1. Fallback Lookup . . . . . . . . . . . . . . . . . . . 19
A.1.2. Two-step Lookup . . . . . . . . . . . . . . . . . . . 20 A.1.2. Two-step Lookup . . . . . . . . . . . . . . . . . . . 19
A.2. Internationalized Resource Identifier (IRI) Mapping A.2. Internationalized Resource Identifier (IRI) Mapping
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Summary of Major Changes from IDNA2003 . . . . . . . 22 Appendix B. Summary of Major Changes from IDNA2003 . . . . . . . 21
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 21
C.1. Changes between Version -00 and -01 of C.1. Changes between Version -00 and -01 of
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 22 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 21
C.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 C.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 22
C.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 C.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 22
C.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23 C.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 22
C.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 23 C.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 22
C.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 24 C.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 23
C.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 24 C.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 23
C.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 24 C.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 23
C.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 25 C.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 24
C.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 25 C.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 24
C.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 25 C.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 C.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document supplies the protocol definition for a revised and This document supplies the protocol definition for internationalized
updated specification for internationalized domain names. Essential domain names. Essential definitions and terminology for
definitions and terminology for understanding this document and a understanding this document and a road map of the collection of
road map of the collection of documents that make up IDNA2008 appear documents that make up IDNA2008 appear in [IDNA2008-Defs].
in [IDNA2008-Defs]. Appendix B discusses the relationship between Appendix B discusses the relationship between this specification and
this specification and the earlier version of IDNA (referred to here the earlier version of IDNA (referred to here as "IDNA2003") and the
as "IDNA2003") and the rationale for these changes, along with rationale for these changes, along with considerable explanatory
considerable explanatory material and advice to zone administrators material and advice to zone administrators who support IDNs is
who support IDNs is provided in another documents, notably provided in another documents, notably [IDNA2008-Rationale].
[IDNA2008-Rationale].
IDNA works by allowing applications to use certain ASCII string IDNA works by allowing applications to use certain ASCII string
labels (beginning with a special prefix) to represent non-ASCII name labels (beginning with a special prefix) to represent non-ASCII name
labels. Lower-layer protocols need not be aware of this; therefore labels. Lower-layer protocols need not be aware of this; therefore
IDNA does not depend on changes to any infrastructure. In IDNA does not changes any infrastructure. In particular, IDNA does
particular, IDNA does not depend on any changes to DNS servers, not depend on any changes to DNS servers, resolvers, or protocol
resolvers, or protocol elements, because the ASCII name service elements, because the ASCII name service provided by the existing DNS
provided by the existing DNS is entirely sufficient for IDNA. can be used for IDNA.
IDNA is applied only to DNS labels. Standards for combining labels IDNA applies only to DNS labels. The base DNS standards [RFC1034]
into fully-qualified domain names and parsing labels out of those [RFC1035] and their various updates specify how to combine labels
names are covered in the base DNS standards [RFC1034] [RFC1035] and into fully-qualified domain names and parse labels out of those
their various updates. An application may, of course, apply locally- names.
appropriate conventions to the presentation forms of domain names as
discussed in [IDNA2008-Rationale].
While they share terminology, reference data, and some operations, This document describes two separate protocols, one for IDN
this document describes two separate protocols, one for IDN registration (Section 4) and one for IDN lookup (Section 5), that
registration (Section 4) and one for IDN lookup (Section 5). share some terminology, reference data and operations. [[anchor2:
Note in draft: See the note in the introduction to.]]Section 5
1.1. Discussion Forum 1.1. Discussion Forum
[[anchor3: RFC Editor: please remove this section.]] [[anchor4: RFC Editor: please remove this section.]]
This work is being discussed in the IETF IDNABIS WG and on the This work is being discussed in the IETF IDNABIS WG and on the
mailing list idna-update@alvestrand.no mailing list idna-update@alvestrand.no
2. Terminology 2. Terminology
General terminology applicable to IDNA, but with meanings familiar to Terminology used in IDNA, but also in Unicode or other character set
those who have worked with Unicode or other character set standards standards and the DNS, appears in [IDNA2008-Defs]. Terminology that
and the DNS, appears in [IDNA2008-Defs]. Terminology that is an is required as part of the IDNA definition, including the definitions
integral, normative, part of the IDNA definition, including the of "ACE", appears in that document as well. Readers of this document
definitions of "ACE", appears in that document as well. Familiarity are assumed to be familiar with [IDNA2008-Defs] and with the DNS-
with the terminology materials in that document is assumed for specific terminology in RFC 1034 [RFC1034].
reading this one. The reader of this document is assumed to be
familiar with DNS-specific terminology as defined in RFC 1034
[RFC1034].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Requirements and Applicability 3. Requirements and Applicability
3.1. Requirements 3.1. Requirements
IDNA conformance means adherence to the following requirements: IDNA makes the following requirements:
1. Whenever a domain name is put into an IDN-unaware domain name 1. Whenever a domain name is put into an IDN-unaware domain name
slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only
ASCII characters (i.e., must be either an A-label or an NR-LDH- ASCII characters (i.e., must be either an A-label or an NR-LDH-
label), or must be a label associated with a DNS application that label), unless the DNS application is not subject to historical
is not subject to either IDNA or the historical recommendations recommendations for "hostname"-style names (see [RFC1034] and
for "hostname"-style names [RFC1034]. Section 3.2.1).
2. Comparison of labels MUST be done on equivalent forms: either 2. Labels MUST be compared using equivalent forms: either both
both A-Label forms or both U-Label forms. Because A-labels and A-Label forms or both U-Label forms. Because A-labels and
U-labels can be transformed into each other without loss of U-labels can be transformed into each other without loss of
information, these comparisons are equivalent. However, when a information, these comparisons are equivalent. A pair of
pair of putative A-labels are compared, the comparison MUST use A-labels MUST be compared as case-insensitive ASCII (as with all
an ASCII case-insensitive comparison (as with all comparisons of comparisons of ASCII DNS labels). U-labels must be compared
ASCII DNS labels). Comparisons on putative U-labels must test as-is, without case-folding or other intermediate steps. Note
that the two strings are identical, without case-folding or other that it is not necessary to validate labels in order to compare
intermediate steps. Note that it is not necessary to verify that them. In many cases, validation may be important for other
labels are valid in order to compare them. In many cases, reasons and SHOULD be performed.
verification of validity (that the strings actually are A-labels
or U-labels) may be important for other reasons and SHOULD be
performed.
3. Labels being registered MUST conform to the requirements of 3. Labels being registered MUST conform to the requirements of
Section 4. Labels being looked up and the lookup process MUST Section 4. Labels being looked up and the lookup process MUST
conform to the requirements of Section 5. conform to the requirements of Section 5.
3.2. Applicability 3.2. Applicability
IDNA is applicable to all domain names in all domain name slots IDNA applies to all domain names in all domain name slots in
except where it is explicitly excluded. It is not applicable to protocols except where it is explicitly excluded. It does not apply
domain name slots which do not use the LDH syntax rules. to domain name slots which do not use the Letter/Digit/Hyphen (LDH)
syntax rules.
This implies that IDNA is applicable to many protocols that predate Because it uses the DNS, IDNA applies to many protocols that were
IDNA. Note that IDNs occupying domain name slots in those older specified before it was designed. IDNs occupying domain name slots
protocols MUST be in A-label form until and unless those protocols in those older protocols MUST be in A-label form until and unless
and implementations of them are explicitly upgraded to be aware of those protocols and implementations of them are explicitly upgraded
IDNs in native character (Unicode, not encoded as A-labels) form. to be aware of IDNs in Unicode. IDNs actually appearing in DNS
IDNs actually appearing in DNS queries or responses MUST be A-labels. queries or responses MUST be A-labels.
IDNA is not defined for extended label types (see RFC 2671, Section 3
[RFC2671]).
3.2.1. DNS Resource Records 3.2.1. DNS Resource Records
IDNA applies only to domain names in the NAME and RDATA fields of DNS IDNA applies only to domain names in the NAME and RDATA fields of DNS
resource records whose CLASS is IN. resource records whose CLASS is IN. See RFC 1034 [RFC1034] for
precise definitions of these terms.
There are currently no other exclusions on the applicability of IDNA The application of IDNA to DNS resource records depends entirely on
to DNS resource records. Applicability depends entirely on the the CLASS of the record, and not on the TYPE except as noted below.
CLASS, and not on the TYPE except as noted below. This will remain This will remain true, even as new types are defined, unless a new
true, even as new types are defined, unless there is a compelling type defines type-specific rules. Special naming conventions for SRV
reason for a new type that requires type-specific rules. The special records (and "underscore names" more generally) are incompatible with
naming conventions applicable to SRV records (and "underscore names" IDNA coding. The first two labels on a SRV type record (the ones
more generally) are examples of type-specific rules that are required to start in "_") MUST NOT be A-labels or U-labels, because
incompatible with IDNA coding. Hence the first two labels (the ones conversion to an A-label would lose information (since the underscore
required to start in "_") on a record with TYPE SRV MUST NOT be is not a letter, digit, or hyphen and is consequently DISALLOWED in
A-labels or U-labels (while it would be possible to write a non-ASCII IDNs). Of course, those labels may be part of a domain that uses IDN
string with a leading underscore, conversion to an A-label would be labels at higher levels in the tree.
impossible without loss of information because the underscore is not
a letter, digit, or hyphen and is consequently DISALLOWED in IDNs).
Of course, those labels may be part of a domain that uses IDN labels
at higher levels in the tree.
3.2.2. Non-domain-name Data Types Stored in the DNS 3.2.2. Non-domain-name Data Types Stored in the DNS
Although IDNA enables the representation of non-ASCII characters in Although IDNA enables the representation of non-ASCII characters in
domain names, that does not imply that IDNA enables the domain names, that does not imply that IDNA enables the
representation of non-ASCII characters in other data types that are representation of non-ASCII characters in other data types that are
stored in domain names, specifically in the RDATA field for types stored in domain names, specifically in the RDATA field for types
that have structured RDATA format. For example, an email address that have structured RDATA format. For example, an email address
local part is stored in a domain name in the RNAME field as part of local part is stored in a domain name in the RNAME field as part of
the RDATA of an SOA record (hostmaster@example.com would be the RDATA of an SOA record (hostmaster@example.com would be
represented as hostmaster.example.com). IDNA specifically does not represented as hostmaster.example.com). IDNA does not update the
update the existing email standards, which allow only ASCII existing email standards, which allow only ASCII characters in local
characters in local parts. Even though work is in progress to define parts. Even though work is in progress to define
internationalization for email addresses [RFC4952], changes to the internationalization for email addresses [RFC4952], changes to the
email address part of the SOA RDATA would require action in, or email address part of the SOA RDATA would require action in, or
updates to, other standards, specifically those that specify the updates to, other standards, specifically those that specify the
format of the SOA RR. 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) Note that, while the registration and lookup protocols (Section 5)
are very similar in most respects, they are different and are very similar in most respects, they are different and
implementers should carefully follow the steps they are implementing. implementers should carefully follow the appropriate steps.
4.1. Input to IDNA Registration Process 4.1. Input to IDNA Registration Process
[[anchor7: Note in Draft: This subsection is new in -09/, based on Registration processes, especially processing by entities, such as
comments on the mailing list in January and February 2009. It "registrars" who deal with registrants before the request actually
replaces the previous first two subsections of this section and reaches the zone manager ("registry") are outside the scope of these
completely eliminates the discussion of local mapping for protocols and may differ significantly depending on local needs. By
registration.]] the time a string enters the IDNA registration process as described
in this specification, it is expected to be in Unicode and MUST be in
Registration processes are outside the scope of these protocols and Unicode Normalization Form C (NFC [Unicode-UAX15]). Entities
may differ significantly depending on local needs. By the time a responsible for zone files ("registries") are expected to accept only
string enters the IDNA registration process as described in this the exact string for which registration is requested, free of any
specification, it is expected to be in Unicode and MUST be in Unicode mappings or local adjustments. They SHOULD avoid any possible
Normalization Form C (NFC [Unicode-UAX15]). Entities responsible for ambiguity by accepting registrations only for A-labels, possibly
zone files ("registries") are expected to accept only the exact paired with the relevant U-labels so that they can verify the
string for which registration is requested, free of any mappings or correspondence.
local adjustments. They SHOULD avoid any possible ambiguity by
accepting registrations only for A-labels, possibly paired with the
relevant U-labels so that they can verify the correspondence.
4.2. Permitted Character and Label Validation 4.2. Permitted Character and Label Validation
4.2.1. Input Format 4.2.1. Input Format
The registry MAY permit submission of labels in A-label form and is The registry SHOULD permit submission of labels in A-label form and
encouraged to accept both the A-label form and the U-label one. If is encouraged to accept both the A-label form and the U-label one.
it does so, it MUST perform a conversion to a U-label, perform the If it does so, it MUST perform a conversion to a U-label, perform the
steps and tests described below, and verify that the A-label produced steps and tests described below, and verify that the A-label produced
by the step in Section 4.4 matches the one provided as input. In by the step in Section 4.4 matches the one provided as input. In
addition, if a U-label was provided, that U-label and the one addition, if a U-label was provided, that U-label and the one
obtained by conversion of the A-label MUST match exactly. If, for obtained by conversion of the A-label MUST match exactly. If, for
some reason, these tests fail, the registration MUST be rejected. If some reason, these tests fail, the registration MUST be rejected. If
the conversion to a U-label is not performed, the registry MUST still the conversion to a U-label is not performed, the registry MUST still
verify that the A-label is superficially valid, i.e., that it does verify that the A-label is superficially valid, i.e., that it does
not violate any of the rules of Punycode [RFC3492] encoding such as not violate any of the rules of Punycode [RFC3492] encoding such as
the prohibition on trailing hyphen-minus, appearance of non-basic the prohibition on trailing hyphen-minus, appearance of non-basic
characters before the delimiter, and so on. Fake A-labels, i.e., characters before the delimiter, and so on. Fake A-labels, i.e.,
invalid strings that appear to be A-labels but are not, MUST NOT be invalid strings that appear to be A-labels but are not, MUST NOT be
placed in DNS zones that support IDNA. placed in DNS zones that support IDNA.
4.2.2. Rejection of Characters that are not Permitted 4.2.2. Rejection of Characters that are not Permitted
The candidate Unicode string is checked to verify that characters The candidate Unicode string MUST NOT contain characters in the
that IDNA does not permit do not appear in it. Those characters are "DISALLOWED" and "UNASSIGNED" lists specified in [IDNA2008-Tables].
identified in the "DISALLOWED" and "UNASSIGNED" lists that are
specified in [IDNA2008-Tables] and described informally in
[IDNA2008-Rationale]. Characters that are either DISALLOWED or
UNASSIGNED MUST NOT be part of labels to be processed for
registration in the DNS.
4.2.3. Label Validation 4.2.3. Label Validation
The proposed label (in the form of a Unicode string, i.e., a string The proposed label (in the form of a Unicode string, i.e., a string
that at least superficially appears to be a U-label) is then that at least superficially appears to be a U-label) is then
examined, performing tests that require examination of more than one examined, performing tests that require examination of more than one
character. character. Character order is considered to be the on-the-wire
order, not the display order.
4.2.3.1. Rejection of Hyphen Sequences in U-labels 4.2.3.1. Consecutive Hyphens
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
the third and fourth character positions when the label is considered the third and fourth character positions.
in "on the wire" order.
4.2.3.2. Leading Combining Marks 4.2.3.2. Leading Combining Marks
The first character of the string (when the label is considered in The Unicode string MUST NOT begin with a combining mark or combining
"on the wire" order) is examined to verify that it is not a combining character (see The Unicode Standard, Section 2.11 [Unicode] for an
mark (or combining character) (see The Unicode Standard, Section 2.11 exact definition).
[Unicode] for an exact definition). If it is a combining mark, the
string MUST NOT be registered.
4.2.3.3. Contextual Rules 4.2.3.3. Contextual Rules
Each code point is checked for its identification as a character The Unicode string MUST NOT contain any characters whose validity is
requiring contextual processing for registration (the list of context-dependent, unless the validity is positively confirmed by a
characters appears as the combination of CONTEXTJ and CONTEXTO in contextual rule. To check this, each code-point marked as CONTEXTJ
[IDNA2008-Tables] as do the contextual rules themselves). If that and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule. If such
indication appears, the table of contextual rules is checked for a a code-point is missing a rule, it is invalid. If the rule exists
rule for that character. If no rule is found, the proposed label is but the result of applying the rule is negative or inconclusive, the
rejected and MUST NOT be installed in a zone file. If one is found, proposed label is invalid.
it is applied (typically as a test on the entire label or on adjacent
characters within the label). If the application of the rule does
not conclude that the character is valid in context, the proposed
label MUST BE rejected. (See the IANA Considerations: IDNA Context
Registry section of [IDNA2008-Tables].)
These contextual rules are required to support the use of characters NOTE: These contextual rules are required to support characters that
that could be used, under other conditions, to produce misleading could be used, under some conditions, to produce misleading labels or
labels or to cause unacceptable ambiguity in label matching and to cause unacceptable ambiguity in label matching and interpretation.
interpretation. For example, labels containing invisible ("zero- For example, labels containing zero-width characters may be permitted
width") characters may be permitted in context with characters whose in context with characters whose presentation forms are significantly
presentation forms are significantly changed by the presence or changed by the zero-width characters, while other labels in which
absence of the zero-width characters, while other labels in which
zero-width characters appear may be rejected. zero-width characters appear may be rejected.
[[anchor11: Note in draft: Should this note be moved to Rationale???
It has no normative consequences here.]]
4.2.3.4. Labels Containing Characters Written Right to Left 4.2.3.4. Labels Containing Characters Written Right to Left
Special tests are required for strings containing characters that are If the proposed label contains any characters that are written from
normally written from right to left. The criteria for classifying right to left it MUST meet the "bidi" criteria [IDNA2008-BIDI].
characters in terms of directionality are identified in the "Bidi"
document [IDNA2008-BIDI] in this series. That document also
describes conditions for strings that contain one or more of those
characters to be U-labels. The tests for those conditions, specified
there, are applied. Strings that contain right to left characters
but that do not conform to the IDNA Bidi rules MUST NOT be inserted
as labels in zone files.
4.2.4. Registration Validation Summary 4.2.4. Registration Validation Summary
Strings that contain at least one non-ASCII character, have been Strings that contain at least one non-ASCII character, have been
produced by the steps above, whose contents pass all of the tests in produced by the steps above, whose contents pass all of the tests in
Section 4.2, and are 63 or fewer characters long in ACE form (see Section 4.2, and are 63 or fewer characters long in ACE form (see
Section 4.4), are U-labels. Section 4.4), are U-labels.
To summarize, tests are made in Section 4.2 for invalid characters, To summarize, tests are made in Section 4.2 for invalid characters,
invalid combinations of characters, for labels that are invalid even invalid combinations of characters, for labels that are invalid even
if the characters they contain are valid individually, and for labels if the characters they contain are valid individually, and for labels
that do not conform to the restrictions for strings containing right that do not conform to the restrictions for strings containing right
to left characters. to left characters.
4.3. Registry Restrictions 4.3. Registry Restrictions
Registries at all levels of the DNS, not just the top level, are In addition to the rules and tests above, there are many reasons why
expected to establish policies about the labels that may be a registry could reject a label. Registries at all levels of the
registered, and for the processes associated with that action. While DNS, not just the top level, establish policies about label
exact policies are not specified as part of IDNA2008 and it is registrations. Policies are likely to be informed by the local
expected that different registries may specify different policies, languages and may depend on many factors including what characters
there SHOULD be policies. Even a trivial policy (e.g., "anything can are in the label (for example, a label may be rejected based on other
be registered in this zone that can be represented as an A-label - labels already registered). See [IDNA2008-Rationale] for a
U-label pair") has value because it provides notice to users and discussion and recommendations about registry policies.
applications implementers that the registry cannot be relied upon to
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. That document also contains a discussion and recommendations
about possible types of rules.
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.4. Punycode Conversion 4.4. Punycode Conversion
The resulting U-label is converted to an A-label. The A-label, more The resulting U-label is converted to an A-label. The A-label, more
precisely defined elsewhere, is the encoding of the U-label according precisely defined elsewhere, is the encoding of the U-label according
skipping to change at page 11, line 34 skipping to change at page 10, line 43
The failure conditions identified in the Punycode encoding procedure The failure conditions identified in the Punycode encoding procedure
cannot occur if the input is a U-label as determined by the steps cannot occur if the input is a U-label as determined by the steps
above. above.
4.5. Insertion in the Zone 4.5. 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 Lookup Protocol 5. Domain Name Lookup Protocol
Lookup is conceptually different from registration and different Lookup is different from registration and different tests are applied
tests are applied on the client. Although some validity checks are on the client. Although some validity checks are necessary to avoid
necessary to avoid serious problems with the protocol (see serious problems with the protocol, the lookup-side tests are more
Section 5.5ff.), the lookup-side tests are more permissive and rely permissive and rely on the assumption that names that are present in
on the assumption that names that are present in the DNS are valid. the DNS are valid. That assumption is, however, a weak one because
That assumption is, however, a weak one because the presence of wild the presence of wild cards in the DNS might cause a string that is
cards in the DNS might cause a string that is not actually registered not actually registered in the DNS to be successfully looked up.
in the DNS to be successfully looked up.
[[anchor13: Note in Draft: Try to reorganize and renumber Section 5 The two steps in Section 5.2 and Section 5.3 are required.
[[anchor14: Note in Draft: Try to reorganize and renumber Section 5
(Lookup) so that it exactly parallels Section 4 (Registration). This (Lookup) so that it exactly parallels Section 4 (Registration). This
has not been done in drafts -10 or -11 because the task will be much has not been done in drafts -10 through -12 because the task will be
easier if the local mapping material is pulled from here (and there much easier if the local mapping material is pulled from here (and
is no point trying to align the section numbers twice).]] there is no point trying to align the section numbers twice).]]
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. Alternately, some process not directly domain name is extracted. Alternately, some process not directly
involving the user may read the string from a file or obtain it in involving the 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 some other way. Processing in this step and the next two are local
matters, to be accomplished prior to actual invocation of IDNA, but matters, to be accomplished prior to actual invocation of IDNA.
at least the two steps in Section 5.2 and Section 5.3 must be
accomplished in some way.
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. A Unicode string may require
beyond the scope of this document, but may involve normalization normalization as discussed in Section 4.1. The result MUST be a
identical to that discussed in Section 4.1. The result MUST be a
Unicode string in NFC form. Unicode string in NFC form.
5.3. Character Changes in Preprocessing or the User Interface 5.3. Character Changes in Preprocessing or the User Interface
[[anchor14: Note in Drafts -10 and -11. As of the time this draft [[anchor15: Note in Draft -12. This entire section is likely to need
was posted, the WG was continuing to discuss various alternatives to to be rewritten when we make final decisions about mapping.]]
this section, which was pragmatic relative to various options and
behavior but that seems to make no one happy from a predictability or
transition standpoint. Please see the (temporary) first appendix to
this document for a first cut at possible alternate formulations.]]
The Unicode string MAY then be processed to prevent confounding of The Unicode string MAY then be processed to prevent confounding of
user expectations. For instance, it might be reasonable, at this user expectations. For instance, it might 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, but even this should be makes sense in the user's environment, but even this should be
approached with caution due to some edge cases: in the long term, it approached with caution due to some edge cases: in the long term, it
is probably better for users to understand IDNs strictly in lower- is probably better for users to understand IDNs strictly in lower-
case, U-label, form. More generally, preprocessing may be useful to case, U-label, form. More generally, preprocessing may be useful to
smooth the transition from IDNA2003, especially for direct user smooth the transition from IDNA2003, especially for direct user
input, but with similar cautions. In general, IDNs appearing in input, but with similar cautions. In general, IDNs appearing in
skipping to change at page 14, line 37 skipping to change at page 13, line 37
that rule. Note that this implies that a rule much be defined, that rule. Note that this implies that a rule much be defined,
not null: a character that requires a contextual rule but for not null: a character that requires a contextual rule but for
which the rule is null is treated in this step as having failed to which the rule is null is treated in this step as having failed to
conform to the rule. conform to the rule.
o Labels containing code points that are identified in o Labels containing code points that are identified in
[IDNA2008-Tables] as "CONTEXTO", but for which no such rule [IDNA2008-Tables] as "CONTEXTO", but for which no such rule
appears in the table of rules. Applications resolving DNS names appears in the table of rules. Applications resolving DNS names
or carrying out equivalent operations are not required to test or carrying out equivalent operations are not required to test
contextual rules for "CONTEXTO" characters, only to verify that a contextual rules for "CONTEXTO" characters, only to verify that a
rule is defined (although they MAY make such tests to give better rule is defined (although they MAY make such tests to provide
information to the user). better protection or give better information to the user).
o Labels whose first character is a combining mark (see o Labels whose first character is a combining mark (see
Section 4.2.3.2. Section 4.2.3.2).
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 lookup test may be omitted in special circumstances, such as when the lookup
application knows that the conditions are enforced elsewhere, because application knows that the conditions are enforced elsewhere, because
an attempt to look up and resolve such strings will almost certainly an attempt to look up and resolve such strings will almost certainly
lead to a DNS lookup failure except when wildcards are present in the lead to a DNS lookup failure except when wildcards are present in the
zone. However, applying the test is likely to give much better zone. However, applying the test is likely to give much better
information about the reason for a lookup failure -- information that information about the reason for a lookup failure -- information that
may be usefully passed to the user when that is feasible -- than DNS may be usefully passed to the user when that is feasible -- than DNS
resolution failure information alone. In any event, lookup resolution failure information alone. In any event, lookup
applications should avoid attempting to resolve labels that are applications should avoid attempting to resolve labels that are
invalid under that test. invalid under that test.
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 lookup application MUST rely on the For all other strings, the lookup application MUST rely on the
presence or absence of labels in the DNS to determine the validity of presence or absence of labels in the DNS to determine the validity of
those labels and the validity of the characters they contain. If those labels and the validity of the characters they contain. If
they are registered, they are presumed to be valid; if they are not, they are registered, they are presumed to be valid; if they are not,
their possible validity is not relevant. A lookup application that their possible validity is not relevant. While a lookup application
declines to process a string that conforms to the rules above and may reasonably issue warnings about strings it believes may be
does not look it up in the DNS is not in conformance with this problematic, applications that decline to process a string that
protocol. conforms to the rules above (i.e., does not look it up in the DNS)
are not in conformance with this protocol.
5.6. Punycode Conversion 5.6. Punycode Conversion
The string that has now been validated for lookup is converted to ACE The string that has now been validated for lookup is converted to ACE
form using the Punycode algorithm (with the ACE prefix added). With form using the Punycode algorithm (with the ACE prefix added). With
the understanding that this summary is not normative (the steps above the understanding that this summary is not normative (the steps above
are), the string has either are), the string is either
o been determined to be in Unicode and in NFC form with no leading o in Unicode NFC form that contains no leading combining marks,
combining marks, to contain no DISALLOWED or UNASSIGNED code contains no DISALLOWED or UNASSIGNED code points, has rules
points, to have rules associated with any code points in CONTEXTJ associated with any code points in CONTEXTJ or CONTEXTO, and, for
or CONTEXTO, and, for those in CONTEXTJ, to satisfy the conditions those in CONTEXTJ, to satisfies the conditions of the rules; or
of the rules.
o satisfied the conditions for A-label input in Section 5.4 under o in A-label form, was supplied under circumstances in which the
circumstances in which the U-label conversions and tests have not U-label conversions and tests have not been performed (see
been performed Section 5.4).
5.7. DNS Name Resolution 5.7. DNS Name Resolution
That resulting validated string is looked up in the DNS, using normal That resulting validated string is looked up in the DNS, using normal
DNS resolver procedures. That lookup can obviously either succeed DNS resolver procedures. That lookup can obviously either succeed
(returning information) or fail. (returning information) or fail.
6. Security Considerations 6. Security Considerations
Security Considerations for this version of IDNA, except for the Security Considerations for this version of IDNA, except for the
skipping to change at page 16, line 39 skipping to change at page 15, line 39
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 the other contributors, Stephane Bortzmeyer, Vint suggestions from the other contributors, Stephane Bortzmeyer, Vint
Cerf, Mark Davis, Paul Hoffman, Kent Karlsson, Erik van der Poel, Cerf, Lisa Dusseault, Mark Davis, Paul Hoffman, Kent Karlsson, Erik
Marcos Sanz, Andrew Sullivan, Ken Whistler, and other WG van der Poel, Marcos Sanz, Andrew Sullivan, Ken Whistler, and other
participants. Special thanks are due to Paul Hoffman for permission WG participants. Special thanks are due to Paul Hoffman for
to extract material from his Internet-Draft to form the basis for permission to extract material from his Internet-Draft to form the
Appendix B. basis for Appendix B.
10. References 10. References
10.1. Normative References 10.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 21, line 26 skipping to change at page 20, line 26
In particular, if both interpretations of the name return values, the In particular, if both interpretations of the name return values, the
lookup application has no practical way to tell whether the relevant lookup application has no practical way to tell whether the relevant
registry has applied "variant" or "bundling" techniques to ensure registry has applied "variant" or "bundling" techniques to ensure
that both domain names are under the same control or not. From that that both domain names are under the same control or not. From that
perspective, the approach in the previous subsection assumes that has perspective, the approach in the previous subsection assumes that has
been done (if the IDNA2003-interpretation label is present at all) been done (if the IDNA2003-interpretation label is present at all)
while this one assumes that such bundling is unlikely to have while this one assumes that such bundling is unlikely to have
occurred. occurred.
[[anchor24: Note in Draft: If this appendix is used, RFC3490 must be [[anchor25: Note in Draft: If this appendix is used, RFC3490 must be
moved from Informative to Normative.]] moved from Informative to Normative.]]
A.2. Internationalized Resource Identifier (IRI) Mapping Model A.2. Internationalized Resource Identifier (IRI) Mapping Model
This subsection is intended to be descriptive of an approach that This subsection is intended to be descriptive of an approach that
lies outside IDNA, rather than a normative component of it. If it lies outside IDNA, rather than a normative component of it. If it
were adopted, Section 5.3 would be deleted and the material below were adopted, Section 5.3 would be deleted and the material below
would be referenced, either as a non-normative Appendix in Protocol would be referenced, either as a non-normative Appendix in Protocol
or, more reasonably, as a section of Rationale. or, more reasonably, as a section of Rationale.
skipping to change at page 22, line 45 skipping to change at page 21, line 45
contexts or as part of running text in paragraphs. contexts or as part of running text in paragraphs.
9. Remove the dot separator from the mandatory part of the 9. Remove the dot separator from the mandatory part of the
protocol. protocol.
10. Make some currently-valid labels that are not actually IDNA 10. Make some currently-valid labels that are not actually IDNA
labels invalid. labels invalid.
Appendix C. Change Log Appendix C. Change Log
[[anchor27: RFC Editor: Please remove this appendix.]] [[anchor28: RFC Editor: Please remove this appendix.]]
C.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol C.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.
C.2. Version -02 C.2. Version -02
skipping to change at page 25, line 16 skipping to change at page 24, line 16
o Removed Security Considerations material to Defs document. o Removed Security Considerations material to Defs document.
o Removed the Name Server Considerations material to Rationale. o Removed the Name Server Considerations material to Rationale.
That material is not normative and not needed to implement the That material is not normative and not needed to implement the
protocol itself. protocol itself.
o Adjusted terminology to match new version of Defs. o Adjusted terminology to match new version of Defs.
o Removed all discussion of local mapping and option for it from o Removed all discussion of local mapping and option for it from
registration protocol. registration protocol. Such mapping is now completely prohibited
on Registration.
o Removed some old placeholders and inquiries because no comments o Removed some old placeholders and inquiries because no comments
have been received. have been received.
o Small editorial corrections. o Small editorial corrections.
C.10. Version -10 C.10. Version -10
o Rewrote the registration input material slightly to further o Rewrote the registration input material slightly to further
clarify the "no mapping on registration" principle. clarify the "no mapping on registration" principle.
skipping to change at page 26, line 5 skipping to change at page 25, line 5
draft). draft).
o Recast the last steps of the Lookup description to eliminate o Recast the last steps of the Lookup description to eliminate
"apparent" (previously "putative") terminology. "apparent" (previously "putative") terminology.
o Rewrote major portions of the temporary appendix that describes o Rewrote major portions of the temporary appendix that describes
transitional mappings to improve clarity and add context. transitional mappings to improve clarity and add context.
o Did some fine-tuning of terminology, notably in Section 3.2.1. o Did some fine-tuning of terminology, notably in Section 3.2.1.
C.12. Version -12
o Extensive editorial improvements, mostly due to suggestions from
Lisa Dusseault.
o Conformance statements have been made consistent, especially in
Section 4.2.1 and subsequent text, which said "SHOULD" in one
place and then said "MAY" as the result of incomplete removal of
registration-time mapping. Also clarified the definition of
"registration processes" in Section 4.1 -- the previous text had
confused several people.
o A few new "question to the WG notes have been added about
appropriateness or placement of text. If there are no comments on
the mailing list, the editor will apply his own judgment.
o Several of the usual small typos and other editorial errors have
been corrected.
o Section 5 has still not been reorganized to match Section 4 in
structure and subsection numbering -- will be done as soon as the
mapping decisions and references are final.
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. 54 change blocks. 
256 lines changed or deleted 238 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/