draft-ietf-precis-problem-statement-08.txt   draft-ietf-precis-problem-statement-09.txt 
Network Working Group M. Blanchet Network Working Group M. Blanchet
Internet-Draft Viagenie Internet-Draft Viagenie
Intended status: Informational A. Sullivan Intended status: Informational A. Sullivan
Expires: March 23, 2013 Dyn, Inc. Expires: July 26, 2013 Dyn, Inc.
September 19, 2012 January 22, 2013
Stringprep Revision and PRECIS Problem Statement Stringprep Revision and PRECIS Problem Statement
draft-ietf-precis-problem-statement-08.txt draft-ietf-precis-problem-statement-09.txt
Abstract Abstract
If a protocol expects to compare two strings and is prepared only for If a protocol expects to compare two strings and is prepared only for
those strings to be ASCII, then using Unicode codepoints in those those strings to be ASCII, then using Unicode codepoints in those
strings requires they be prepared somehow. Internationalizing Domain strings requires they be prepared somehow. Internationalizing Domain
Names in Applications (here called IDNA2003) defined and used Names in Applications (here called IDNA2003) defined and used
Stringprep and Nameprep. Other protocols subsequently defined Stringprep and Nameprep. Other protocols subsequently defined
Stringprep profiles. A new approach different from Stringprep and Stringprep profiles. A new approach different from Stringprep and
Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 23, 2013. This Internet-Draft will expire on July 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Stringprep Profiles Limitations . . . . . . . . . . . . . . . 6 4. Stringprep Profiles Limitations . . . . . . . . . . . . . . . 6
5. Major Topics for Consideration . . . . . . . . . . . . . . . . 8 5. Major Topics for Consideration . . . . . . . . . . . . . . . . 7
5.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Types of Identifiers . . . . . . . . . . . . . . . . . 8 5.1.1. Types of Identifiers . . . . . . . . . . . . . . . . . 7
5.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 8 5.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 8
5.2. Dealing with characters . . . . . . . . . . . . . . . . . 9 5.2. Dealing with characters . . . . . . . . . . . . . . . . . 8
5.2.1. Case folding, case sensitivity, and case 5.2.1. Case folding, case sensitivity, and case
preservation . . . . . . . . . . . . . . . . . . . . . 9 preservation . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 9 5.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 8
5.2.3. Character mapping . . . . . . . . . . . . . . . . . . 10 5.2.3. Character mapping . . . . . . . . . . . . . . . . . . 9
5.2.4. Prohibited characters . . . . . . . . . . . . . . . . 10 5.2.4. Prohibited characters . . . . . . . . . . . . . . . . 9
5.2.5. Internal structure, delimiters, and special 5.2.5. Internal structure, delimiters, and special
characters . . . . . . . . . . . . . . . . . . . . . . 10 characters . . . . . . . . . . . . . . . . . . . . . . 9
5.2.6. Restrictions because of glyph similarity . . . . . . . 11 5.2.6. Restrictions because of glyph similarity . . . . . . . 10
5.3. Where the data comes from and where it goes . . . . . . . 11 5.3. Where the data comes from and where it goes . . . . . . . 10
5.3.1. User input and the source of protocol elements . . . . 11 5.3.1. User input and the source of protocol elements . . . . 10
5.3.2. User output . . . . . . . . . . . . . . . . . . . . . 11 5.3.2. User output . . . . . . . . . . . . . . . . . . . . . 11
5.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 12 5.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 11
6. Considerations for Stringprep replacement . . . . . . . . . . 13 6. Considerations for Stringprep replacement . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Discussion home for this draft . . . . . . . . . . . . . . . . 14 9. Discussion home for this draft . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. Informative References . . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Classification of Stringprep Profiles . . . . . . . . 18 Appendix A. Classification of Stringprep Profiles . . . . . . . . 18
Appendix B. Evaluation of Stringprep Profiles . . . . . . . . . . 19 Appendix B. Evaluation of Stringprep Profiles . . . . . . . . . . 18
B.1. iSCSI Stringprep Profile: RFC3722 (and RFC3721, B.1. iSCSI Stringprep Profile: RFC3722 (and RFC3721,
RFC3720) . . . . . . . . . . . . . . . . . . . . . . . . . 19 RFC3720) . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.2. SMTP/POP3/ManageSieve Stringprep Profiles: B.2. SMTP/POP3/ManageSieve Stringprep Profiles:
RFC4954,RFC5034,RFC 5804 . . . . . . . . . . . . . . . . . 21 RFC4954,RFC5034,RFC 5804 . . . . . . . . . . . . . . . . . 20
B.3. IMAP Stringprep Profiles: RFC5738, RFC4314: Usernames . . 22 B.3. IMAP Stringprep Profiles: RFC5738, RFC4314: Usernames . . 22
B.4. IMAP Stringprep Profiles: RFC5738: Passwords . . . . . . . 24 B.4. IMAP Stringprep Profiles: RFC5738: Passwords . . . . . . . 23
B.5. Anonymous SASL Stringprep Profiles: RFC4505 . . . . . . . 25 B.5. Anonymous SASL Stringprep Profiles: RFC4505 . . . . . . . 24
B.6. XMPP Stringprep Profiles: RFC3920 Nodeprep . . . . . . . . 27 B.6. XMPP Stringprep Profiles: RFC3920 Nodeprep . . . . . . . . 26
B.7. XMPP Stringprep Profiles: RFC3920 Resourceprep . . . . . . 28 B.7. XMPP Stringprep Profiles: RFC3920 Resourceprep . . . . . . 27
B.8. EAP Stringprep Profiles: RFC3748 . . . . . . . . . . . . . 28 B.8. EAP Stringprep Profiles: RFC3748 . . . . . . . . . . . . . 28
Appendix C. Changes between versions . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
C.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.3. 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.4. 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.5. 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.6. 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.7. 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Internationalizing Domain Names in Applications (here called Internationalizing Domain Names in Applications (here called
IDNA2003) [RFC3490], [RFC3491], [RFC3492], [RFC3454] describes a IDNA2003) [RFC3490], [RFC3491], [RFC3492], [RFC3454] describes a
mechanism for encoding Unicode labels making up Internationalized mechanism for encoding Unicode labels making up Internationalized
Domain Names (IDNs) as standard DNS labels. The labels were Domain Names (IDNs) as standard DNS labels. The labels were
processed using a method called Nameprep [RFC3491] and Punycode processed using a method called Nameprep [RFC3491] and Punycode
[RFC3492]. That method was specific to IDNA2003, but is generalized [RFC3492]. That method was specific to IDNA2003, but is generalized
as Stringprep [RFC3454]. The general mechanism is used by other as Stringprep [RFC3454]. The general mechanism is used by other
protocols with similar needs, but with different constraints than protocols with similar needs, but with different constraints than
IDNA2003. IDNA2003.
Stringprep defines a framework within which protocols define their Stringprep defines a framework within which protocols define their
Stringprep profiles. Known IETF specifications using Stringprep are Stringprep profiles. Some known IETF specifications using Stringprep
listed below: are listed below:
o The Nameprep profile [RFC3490] for use in Internationalized Domain o The Nameprep profile [RFC3490] for use in Internationalized Domain
Names (IDNs); Names (IDNs);
o IAX using Nameprep [RFC5456];
o NFSv4 [RFC3530] and NFSv4.1 [RFC5661]; o NFSv4 [RFC3530] and NFSv4.1 [RFC5661];
o The iSCSI profile [RFC3722] for use in Internet Small Computer o The iSCSI profile [RFC3722] for use in Internet Small Computer
Systems Interface (iSCSI) Names; Systems Interface (iSCSI) Names;
o EAP [RFC3748]; o EAP [RFC3748];
o The Nodeprep and Resourceprep profiles [RFC3920] for use in the o The Nodeprep and Resourceprep profiles [RFC3920] for use in the
Extensible Messaging and Presence Protocol (XMPP), and the XMPP to Extensible Messaging and Presence Protocol (XMPP), and the XMPP to
CPIM mapping [RFC3922] (the latter of these relies on the former); CPIM mapping [RFC3922] (the latter of these relies on the former);
o IRI and URI in XMPP [RFC5122];
o The Policy MIB profile [RFC4011] for use in the Simple Network o The Policy MIB profile [RFC4011] for use in the Simple Network
Management Protocol (SNMP); Management Protocol (SNMP);
o The SASLprep profile [RFC4013] for use in the Simple
Authentication and Security Layer (SASL), and SASL itself
[RFC4422];
o TLS [RFC4279]; o TLS [RFC4279];
o IMAP4 using SASLprep [RFC4314];
o The trace profile [RFC4505] for use with the SASL ANONYMOUS
mechanism;
o The LDAP profile [RFC4518] for use with LDAP [RFC4511] and its o The LDAP profile [RFC4518] for use with LDAP [RFC4511] and its
authentication methods [RFC4513]; authentication methods [RFC4513];
o Plain SASL using SASLprep [RFC4616];
o NNTP using SASLprep [RFC4643];
o PKIX subject identification using LDAPprep [RFC4683]; o PKIX subject identification using LDAPprep [RFC4683];
o Internet Application Protocol Collation Registry [RFC4790]; o PKIX CRL using LDAPprep [RFC5280];
o The SASLprep profile [RFC4013] for use in the Simple
Authentication and Security Layer (SASL), and SASL itself
[RFC4422];
o Plain SASL using SASLprep [RFC4616];
o SMTP Auth using SASLprep [RFC4954]; o SMTP Auth using SASLprep [RFC4954];
o POP3 Auth using SASLprep [RFC5034]; o POP3 Auth using SASLprep [RFC5034];
o TLS SRP using SASLprep [RFC5054]; o TLS SRP using SASLprep [RFC5054];
o IRI and URI in XMPP [RFC5122];
o PKIX CRL using LDAPprep [RFC5280];
o IAX using Nameprep [RFC5456];
o SASL SCRAM using SASLprep [RFC5802]; o SASL SCRAM using SASLprep [RFC5802];
o Remote management of Sieve using SASLprep [RFC5804]; o Remote management of Sieve using SASLprep [RFC5804];
o NNTP using SASLprep [RFC4643];
o IMAP4 using SASLprep [RFC4314];
o The trace profile [RFC4505] for use with the SASL ANONYMOUS
mechanism;
o Internet Application Protocol Collation Registry [RFC4790];
o The unicode-casemap Unicode Collation [RFC5051]. o The unicode-casemap Unicode Collation [RFC5051].
However, a review (see [ietf78precis]) of these protocol However, a review (see [ietf78precis]) of these protocol
specifications found that they are very similar and can be grouped specifications found that they are very similar and can be grouped
into a short number of classes. Moreover, many reuse the same into a short number of classes. Moreover, many reuse the same
Stringprep profile, such as the SASL one. Stringprep profile, such as the SASL one.
IDNA2003 was replaced because of some limitations described in IDNA2003 was replaced because of some limitations described in
[RFC4690]. The new IDN specification, called IDNA2008 [RFC5890], [RFC4690]. The new IDN specification, called IDNA2008 [RFC5890],
[RFC5891], [RFC5892], [RFC5893] was designed based on the [RFC5891], [RFC5892], [RFC5893] was designed based on the
considerations found in [RFC5894]. One of the effects of IDNA2008 is considerations found in [RFC5894]. One of the effects of IDNA2008 is
that Nameprep and Stringprep are not used at all. Instead, an that Nameprep and Stringprep are not used at all. Instead, an
algorithm based on Unicode properties of codepoints is defined. That algorithm based on Unicode properties of codepoints is defined. That
algorithm generates a stable and complete table of the supported algorithm generates a stable and complete table of the supported
Unicode codepoints for each Unicode version. This algorithm is based Unicode codepoints for each Unicode version. This algorithm uses an
on an inclusion-based approach, instead of the exclusion-based inclusion-based approach, instead of the exclusion-based approach of
approach of Stringprep/Nameprep. That is, IDNA2003 created an Stringprep/Nameprep. That is, IDNA2003 created an explicit list of
explicit list of excluded or mapped-away characters; anything in excluded or mapped-away characters; anything in Unicode 3.2 that was
Unicode 3.2 that was not so listed could be assumed to be allowed not so listed could be assumed to be allowed under the protocol.
under the protocol. IDNA2008 begins instead from the assumption that IDNA2008 begins instead from the assumption that code points are
code points are disallowed, and then relies on Unicode properties to disallowed, and then relies on Unicode properties to derive whether a
derive whether a given code point actually is allowed in the given code point actually is allowed in the protocol.
protocol.
This document lists the shortcomings and issues found by protocols This document lists the shortcomings and issues found by protocols
listed above that defined Stringprep profiles. It also lists the listed above that defined Stringprep profiles. It also lists the
requirements for any potential replacement of Stringprep. requirements for any potential replacement of Stringprep.
2. Keywords 2. Keywords
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses various internationalization terms, which are
defined and discussed in [RFC6365].
Additionally, this document defines the following keyword:
o PRECIS: Preparation and Comparison of Internationalized Strings
3. Conventions 3. Conventions
A single Unicode code point in this memo is denoted by "U+" followed A single Unicode code point in this memo is denoted by "U+" followed
by four to six hexadecimal digits, as used in [Unicode61], Appendix by four to six hexadecimal digits, as used in [Unicode61], Appendix
A. A.
4. Stringprep Profiles Limitations 4. Stringprep Profiles Limitations
During IETF 77 (March 2010), a BOF discussed the current state of the During IETF 77 (March 2010), a BOF discussed the current state of the
protocols that have defined Stringprep profiles [NEWPREP]. The main protocols that have defined Stringprep profiles [NEWPREP]. The main
skipping to change at page 7, line 20 skipping to change at page 6, line 25
o The protocols would like to not be bound to a specific version of o The protocols would like to not be bound to a specific version of
Unicode, but rather have better Unicode version agility in the way Unicode, but rather have better Unicode version agility in the way
of IDNA2008. This is important partly because it is usually of IDNA2008. This is important partly because it is usually
impossible for an application to require Unicode 3.2; the impossible for an application to require Unicode 3.2; the
application gets whatever version of Unicode is available on the application gets whatever version of Unicode is available on the
host. host.
o The protocols require better bidirectional support (bidi) than o The protocols require better bidirectional support (bidi) than
currently offered by Stringprep. currently offered by Stringprep.
o If the protocols are updated to use a new version of Stringprep or o If the protocols are updated to use a new version of Stringprep or
another framework, then backward compatibility is an important another framework, then backward compatibility is an important
requirement. For example, Stringprep is based on and profiles may requirement. For example, Stringprep normalization is based on
use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15]. and profiles may use Unicode Normalization Form KC (NFKC) [UAX15],
while IDNA2008 mostly uses Unicode Normalization Form C (NFC)
[UAX15].
o Identifiers are passed between protocols. For example, the same o Identifiers are passed between protocols. For example, the same
username string of codepoints may be passed between SASL, XMPP, username string of codepoints may be passed between SASL, XMPP,
LDAP and EAP. Therefore, common set of rules or classes of LDAP and EAP. Therefore, common set of rules or classes of
strings are preferred over specific rules for each protocol. strings are preferred over specific rules for each protocol.
Without real planning in advance, many stringprep profiles reuse Without real planning in advance, many Stringprep profiles reuse
other profiles, so this goal was accomplished by accident with other profiles, so this goal was accomplished by accident with
Stringprep. Stringprep.
Protocols that use Stringprep profiles use strings for different Protocols that use Stringprep profiles use strings for different
purposes: purposes:
o XMPP uses a different Stringprep profile for each part of the XMPP o XMPP uses a different Stringprep profile for each part of the XMPP
address (JID): a localpart which is similar to a username and used address (JID): a localpart which is similar to a username and used
for authentication, a domainpart which is a domain name and a for authentication, a domainpart which is a domain name, and a
resource part which is less restrictive than the localpart. resource part which is less restrictive than the localpart.
o iSCSI uses a Stringprep profile for the names of protocol o iSCSI uses a Stringprep profile for the names of protocol
participants (called initiators and targets). The IQN format of participants (called initiators and targets). The IQN format of
iSCSI names contains a reversed DNS domain name. iSCSI names contains a reversed DNS domain name.
o SASL and LDAP uses a Stringprep profile for usernames. o SASL and LDAP uses a Stringprep profile for usernames.
o LDAP uses a set of Stringprep profiles. o LDAP uses a set of Stringprep profiles.
The apparent judgement of the BOF attendees [NEWPREP] was that it The apparent judgement of the BOF attendees [NEWPREP] was that it
would be highly desirable to have a replacement of Stringprep, with would be highly desirable to have a replacement of Stringprep, with
similar characteristics to IDNA2008. That replacement should be similar characteristics to IDNA2008. That replacement should be
skipping to change at page 9, line 45 skipping to change at page 9, line 4
following observation regarding Normalization Forms KC and KD: "It is following observation regarding Normalization Forms KC and KD: "It is
best to think of these Normalization Forms as being like uppercase or best to think of these Normalization Forms as being like uppercase or
lowercase mappings: useful in certain contexts for identifying core lowercase mappings: useful in certain contexts for identifying core
meanings, but also performing modifications to the text that may not meanings, but also performing modifications to the text that may not
always be appropriate." In general, it can be said that NFKC is more always be appropriate." In general, it can be said that NFKC is more
aggressive about finding matches between codepoints than NFC. For aggressive about finding matches between codepoints than NFC. For
things like the spelling of users' names, then, NFKC may not be the things like the spelling of users' names, then, NFKC may not be the
best form to use. At the same time, one of the nice things about best form to use. At the same time, one of the nice things about
NFKC is that it deals with the width of characters that are otherwise NFKC is that it deals with the width of characters that are otherwise
similar, by canonicalizing half-width to full-width. This mapping similar, by canonicalizing half-width to full-width. This mapping
step can be crucial in practice. A replacement for stringprep step can be crucial in practice. A replacement for Stringprep
depends on analyzing the different use profiles and considering depends on analyzing the different use profiles and considering
whether NFKC or NFC is a better normalization for each profile. whether NFKC or NFC is a better normalization for each profile.
For the purposes of evaluating an existing example of Stringprep use, For the purposes of evaluating an existing example of Stringprep use,
it is helpful to know whether it uses no normalization, NFKC, or NFC. it is helpful to know whether it uses no normalization, NFKC, or NFC.
5.2.3. Character mapping 5.2.3. Character mapping
Along with the case mapping issues raised in Section 5.2.1, there is Along with the case mapping issues raised in Section 5.2.1, there is
the question of whether some characters are mapped either to other the question of whether some characters are mapped either to other
skipping to change at page 11, line 25 skipping to change at page 10, line 32
some other character, and users may expect to be able to substitute some other character, and users may expect to be able to substitute
their normal stop for FULL STOP, U+002E. At the same time, there are their normal stop for FULL STOP, U+002E. At the same time, there are
predictability arguments in favour of treating identifiers with FULL predictability arguments in favour of treating identifiers with FULL
STOP, U+002E in them just the way they are treated under IDNA2008. STOP, U+002E in them just the way they are treated under IDNA2008.
5.2.6. Restrictions because of glyph similarity 5.2.6. Restrictions because of glyph similarity
Homoglyphs are similarly (or identically) rendered glyphs of Homoglyphs are similarly (or identically) rendered glyphs of
different codepoints. For DNS names, homoglyphs may enable phishing. different codepoints. For DNS names, homoglyphs may enable phishing.
If a protocol requires some visual comparison by end-users, then the If a protocol requires some visual comparison by end-users, then the
issue of homoglyphs are to be considered. In the DNS context, theses issue of homoglyphs is to be considered. In the DNS context, theses
issues are documented in [RFC5894] and [RFC4690]. IDNA2008 does not, issues are documented in [RFC5894] and [RFC4690]. IDNA2008 does not,
however, have a mechanism to deal with them, trusting to DNS zone however, have a mechanism to deal with them, trusting to DNS zone
operators to enact sensible policies for the subset of Unicode they operators to enact sensible policies for the subset of Unicode they
wish to support, given their user community. A similar policy/ wish to support, given their user community. A similar policy/
protocol split may not be desirable in every protocol. protocol split may not be desirable in every protocol.
5.3. Where the data comes from and where it goes 5.3. Where the data comes from and where it goes
5.3.1. User input and the source of protocol elements 5.3.1. User input and the source of protocol elements
skipping to change at page 13, line 14 skipping to change at page 12, line 27
version of Unicode. This is not merely a theoretical possibility, version of Unicode. This is not merely a theoretical possibility,
because it has occurred ([RFC6452]). because it has occurred ([RFC6452]).
Accordingly, as in IDNA2008, a Stringprep replacement that intends to Accordingly, as in IDNA2008, a Stringprep replacement that intends to
be Unicode version agnostic will need to work out a mechanism to be Unicode version agnostic will need to work out a mechanism to
address cases where incompatible changes occur because of new Unicode address cases where incompatible changes occur because of new Unicode
versions. versions.
6. Considerations for Stringprep replacement 6. Considerations for Stringprep replacement
The above suggests the following guidance for replacing Stringprep: The above suggests the following guidance:
o A stringprep replacement should be defined. o A Stringprep replacement should be defined.
o The replacement should take an approach similar to IDNA2008, (e.g. o The replacement should take an approach similar to IDNA2008, (e.g.
by using codepoint properties instead of codepoint whitelisting) by using codepoint properties instead of codepoint whitelisting)
in that it enables better Unicode agility. in that it enables better Unicode agility.
o Protocols share similar characteristics of strings. Therefore, o Protocols share similar characteristics of strings. Therefore,
defining internationalization preparation algorithms for the defining internationalization preparation algorithms for the
smallest set of string classes may be sufficient for most cases, smallest set of string classes may be sufficient for most cases,
providing coherence among a set of related protocols or protocols providing coherence among a set of related protocols or protocols
where identifiers are exchanged. where identifiers are exchanged.
o The sets of string classes need to be evaluated according to the o The sets of string classes need to be evaluated according to the
considerations that make up the headings in Section 5 considerations that make up the headings in Section 5
o It is reasonable to limit scope to Unicode code points, and rule o It is reasonable to limit scope to Unicode code points, and rule
the mapping of data from other character encodings outside the the mapping of data from other character encodings outside the
scope of this effort. scope of this effort.
o The replacement ought at least to provide guidance to applications o The replacement ought at least to provide guidance to applications
using the replacement on how to handle protocol incompatibilities using the replacement on how to handle protocol incompatibilities
resulting from changes to Unicode. In an ideal world, the resulting from changes to Unicode. In an ideal world, the
stringprep replacement would handle the changes automatically, but Stringprep replacement would handle the changes automatically, but
it appears that such automatic handling would require magic and it appears that such automatic handling would require magic and
cannot be expected. cannot be expected.
o Compatibility within each protocol between a technique that is o Compatibility within each protocol between a technique that is
stringprep-based and the technique's replacement has to be Stringprep-based and the technique's replacement has to be
considered very carefully. considered very carefully.
Existing deployments already depend on Stringprep profiles. Existing deployments already depend on Stringprep profiles.
Therefore, a replacement must consider the effects of any new Therefore, a replacement must consider the effects of any new
strategy on existing deployments. By way of comparison, it is worth strategy on existing deployments. By way of comparison, it is worth
noting that some characters were acceptable in IDNA labels under noting that some characters were acceptable in IDNA labels under
IDNA2003, but are not protocol-valid under IDNA2008 (and conversely); IDNA2003, but are not protocol-valid under IDNA2008 (and conversely);
disagreement about what to do during the transition has resulted in disagreement about what to do during the transition has resulted in
different approaches to mapping. Different implementers may make different approaches to mapping. Different implementers may make
different decisions about what to do in such cases; this could have different decisions about what to do in such cases; this could have
interoperability effects. It is necessary to trade better support interoperability effects. It is necessary to trade better support
for different linguistic environments against the potential side for different linguistic environments against the potential side
effects of backward incompatibility. effects of backward incompatibility.
7. Security Considerations 7. Security Considerations
This document merely states what problems are to be solved, and does This document merely states what problems are to be solved, and does
not define a protocol. There are undoubtedly security implications not define a protocol. There are undoubtedly security implications
of the particular results that will come from the work to be of the particular results that will come from the work to be
completed. completed. Moreover, the Stringprep Security Considerations
[RFC3454] Section applies. See also the analysis in the subsections
of Appendix B, below.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Discussion home for this draft 9. Discussion home for this draft
Note: RFC-Editor, please remove this section before publication. Note: RFC-Editor, please remove this section before publication.
This document is intended to define the problem space discussed on This document is intended to define the problem space discussed on
skipping to change at page 14, line 44 skipping to change at page 14, line 13
to the organization of the problem. to the organization of the problem.
Evaluations of Stringprep profiles that are included in Appendix B Evaluations of Stringprep profiles that are included in Appendix B
were done by: David Black, Alexey Melnikov, Peter Saint-Andre, Dave were done by: David Black, Alexey Melnikov, Peter Saint-Andre, Dave
Thaler. Thaler.
11. Informative References 11. Informative References
[I-D.iab-identifier-comparison] [I-D.iab-identifier-comparison]
Thaler, D., "Issues in Identifier Comparison for Security Thaler, D., "Issues in Identifier Comparison for Security
Purposes", draft-iab-identifier-comparison-04 (work in Purposes", draft-iab-identifier-comparison-07 (work in
progress), August 2012. progress), August 2012.
[NEWPREP] "Newprep BoF Meeting Minutes", March 2010. [NEWPREP] "Newprep BoF Meeting Minutes", March 2010.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985. host table specification", RFC 952, October 1985.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 18, line 11 skipping to change at page 17, line 25
RFC 5893, August 2010. RFC 5893, August 2010.
[RFC5894] Klensin, J., "Internationalized Domain Names for [RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, August 2010. Rationale", RFC 5894, August 2010.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA) Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010. 2008", RFC 5895, September 2010.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365,
September 2011.
[RFC6452] Faltstrom, P. and P. Hoffman, "The Unicode Code Points and [RFC6452] Faltstrom, P. and P. Hoffman, "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA) - Internationalized Domain Names for Applications (IDNA) -
Unicode 6.0", RFC 6452, November 2011. Unicode 6.0", RFC 6452, November 2011.
[UAX15] "Unicode Standard Annex #15: Unicode Normalization Forms", [UAX15] "Unicode Standard Annex #15: Unicode Normalization Forms",
UAX 15, September 2009. UAX 15, September 2009.
[Unicode61] [Unicode61]
The Unicode Consortium. The Unicode Standard, Version The Unicode Consortium. The Unicode Standard, Version
6.1, defined by:, "The Unicode Standard -- Version 6.1", 6.1, defined by:, "The Unicode Standard -- Version 6.1",
skipping to change at page 19, line 34 skipping to change at page 18, line 46
This summary is by no means normative nor the actual evaluations This summary is by no means normative nor the actual evaluations
themselves. A template was used for reviewers to get a coherent view themselves. A template was used for reviewers to get a coherent view
of all evaluations. of all evaluations.
B.1. iSCSI Stringprep Profile: RFC3722 (and RFC3721, RFC3720) B.1. iSCSI Stringprep Profile: RFC3722 (and RFC3721, RFC3720)
Description: An iSCSI session consists of an initiator (i.e., host Description: An iSCSI session consists of an initiator (i.e., host
or server that uses storage) communicating with a target (i.e., a or server that uses storage) communicating with a target (i.e., a
storage array or other system that provides storage). Both the storage array or other system that provides storage). Both the
iSCSI initiator and target are named by iSCSI Names. The iSCSI iSCSI initiator and target are named by iSCSI Names. The iSCSI
stringprep profile is used for iSCSI names. Stringprep profile is used for iSCSI names.
How it is used: iSCSI initiators and targets (see above). They can How it is used: iSCSI initiators and targets (see above). They can
also be used to identify SCSI ports (these are software entities also be used to identify SCSI ports (these are software entities
in the iSCSI protocol, not hardware ports), and iSCSI logical in the iSCSI protocol, not hardware ports), and iSCSI logical
units (storage volumes), although both are unusual in practice. units (storage volumes), although both are unusual in practice.
What entities create these identifiers? Generally a Human user (1) What entities create these identifiers? Generally a Human user (1)
configures an Automated system (2) that generates the names. configures an Automated system (2) that generates the names.
Advance configuration of the system is required due to the Advance configuration of the system is required due to the
embedded use of external unique identifier (from the DNS or IEEE). embedded use of external unique identifier (from the DNS or IEEE).
How is the string input in the system? Keyboard and copy-paste are How is the string input in the system? Keyboard and copy-paste are
common. Copy-paste is common because iSCSI names are long enough common. Copy-paste is common because iSCSI names are long enough
to be problematic for humans to remember, causing use of email, to be problematic for humans to remember, causing use of email,
sneaker-net, text files, etc. to avoid mistype mistakes. sneaker-net, text files, etc. to avoid mistype mistakes.
Where do we place the dividing line between user interface and Where do we place the dividing line between user interface and
protocol? The iSCSI protocol requires that all internationalization protocol? The iSCSI protocol requires that all internationalization
skipping to change at page 21, line 4 skipping to change at page 20, line 18
structuring purposes (e.g., only the first occurrence of a colon structuring purposes (e.g., only the first occurrence of a colon
character is structural, others are not). character is structural, others are not).
How are users exposed to these strings? How are they published? How are users exposed to these strings? How are they published?
iSCSI names appear in server and storage system configuration iSCSI names appear in server and storage system configuration
interfaces. They also appear in system logs. interfaces. They also appear in system logs.
Is the string / identifier used as input to other operations? Is the string / identifier used as input to other operations?
Effectively, no. The rarely used port and logical unit names Effectively, no. The rarely used port and logical unit names
involve concatenation, which effectively extends a unique iSCSI involve concatenation, which effectively extends a unique iSCSI
Name for a target to uniquely identify something within that Name for a target to uniquely identify something within that
target. target.
How much tolerance for change from existing Stringprep approach?
How much tolerance for change from existing stringprep approach?
Good tolerance; the community would prefer that Good tolerance; the community would prefer that
internationalization experts solve internationalization problems. internationalization experts solve internationalization problems.
How strong a desire for change (e.g., for Unicode agility)? Unicode How strong a desire for change (e.g., for Unicode agility)? Unicode
agility is desired in principle as long as nothing significant agility is desired in principle as long as nothing significant
breaks. breaks.
B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC4954,RFC5034,RFC B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC4954,RFC5034,RFC
5804 5804
Description: Authorization identity (user identifier) exchanged Description: Authorization identity (user identifier) exchanged
skipping to change at page 22, line 10 skipping to change at page 21, line 27
format as an email address (and EAI email address in the future), format as an email address (and EAI email address in the future),
or as a left hand side of an email address. Note: whatever is or as a left hand side of an email address. Note: whatever is
recommended for SMTP/POP/ManageSieve authorization identity should recommended for SMTP/POP/ManageSieve authorization identity should
also be used for IMAP authorization identities, as IMAP/POP3/SMTP/ also be used for IMAP authorization identities, as IMAP/POP3/SMTP/
ManageSieve are frequently implemented together. ManageSieve are frequently implemented together.
Internal Structure: None Internal Structure: None
User Output: Unlikely, but possible. For example, if it is the same User Output: Unlikely, but possible. For example, if it is the same
as an email address. as an email address.
Operations: - Sometimes concatenated with other data and then used Operations: - Sometimes concatenated with other data and then used
as input to a cryptographic hash function as input to a cryptographic hash function
How much tolerance for change from existing stringprep approach? Not How much tolerance for change from existing Stringprep approach? Not
sure. sure.
Background information: In RFC 5034, when describing the POP3 AUTH Background information: In RFC 5034, when describing the POP3 AUTH
command: The authorization identity generated by the SASL exchange command: The authorization identity generated by the SASL exchange
is a simple username, and SHOULD use the SASLprep profile (see is a simple username, and SHOULD use the SASLprep profile (see
RFC4013) of the StringPrep algorithm (see RFC3454) to prepare RFC4013) of the StringPrep algorithm (see RFC3454) to prepare
these names for matching. If preparation of the authorization these names for matching. If preparation of the authorization
identity fails or results in an empty string (unless it was identity fails or results in an empty string (unless it was
transmitted as the empty string), the server MUST fail the transmitted as the empty string), the server MUST fail the
authentication. In RFC 4954, when describing the SMTP AUTH authentication. In RFC 4954, when describing the SMTP AUTH
command: The authorization identity generated by this SASL command: The authorization identity generated by this SASL
skipping to change at page 24, line 4 skipping to change at page 23, line 13
or as a left hand side of an email address. Note: whatever is or as a left hand side of an email address. Note: whatever is
recommended for IMAP username should also be used for ManageSieve, recommended for IMAP username should also be used for ManageSieve,
POP3 and SMTP authorization identities, as IMAP/POP3/SMTP/ POP3 and SMTP authorization identities, as IMAP/POP3/SMTP/
ManageSieve are frequently implemented together. ManageSieve are frequently implemented together.
Internal Structure: None Internal Structure: None
User Output: Unlikely, but possible. For example, if it is the same User Output: Unlikely, but possible. For example, if it is the same
as an email address. - access control lists (e.g. in IMAP ACL as an email address. - access control lists (e.g. in IMAP ACL
extension), both when managing membership and listing membership extension), both when managing membership and listing membership
of existing access control lists. - often show up as mailbox names of existing access control lists. - often show up as mailbox names
(under Other Users IMAP namespace) (under Other Users IMAP namespace)
Operations: - Sometimes concatenated with other data and then used Operations: - Sometimes concatenated with other data and then used
as input to a cryptographic hash function as input to a cryptographic hash function
How much tolerance for change from existing stringprep approach? Not How much tolerance for change from existing Stringprep approach? Not
sure. Non-ASCII IMAP usernames are currently prohibited by IMAP sure. Non-ASCII IMAP usernames are currently prohibited by IMAP
(RFC 3501). However they are allowed when used in IMAP ACL (RFC 3501). However they are allowed when used in IMAP ACL
extension. extension.
B.4. IMAP Stringprep Profiles: RFC5738: Passwords B.4. IMAP Stringprep Profiles: RFC5738: Passwords
Description: "Password" parameter to the IMAP LOGIN command Description: "Password" parameter to the IMAP LOGIN command
How It's Used: Used for authentication (Passwords) How It's Used: Used for authentication (Passwords)
Who Generates It: Either generated by email system administrators Who Generates It: Either generated by email system administrators
using some tools/conventions, or specified by the human user. using some tools/conventions, or specified by the human user.
skipping to change at page 24, line 46 skipping to change at page 24, line 10
implementations allow spaces in these. Password in all email implementations allow spaces in these. Password in all email
related protocols should be treated in the same way. Same related protocols should be treated in the same way. Same
passwords are frequently shared with web, IM, etc. applications. passwords are frequently shared with web, IM, etc. applications.
Internal Structure: None Internal Structure: None
User Output: - text of email messages (e.g. in "you forgot your User Output: - text of email messages (e.g. in "you forgot your
password" email messages) - web page / directory - side of the bus password" email messages) - web page / directory - side of the bus
/ in ads -- possible / in ads -- possible
Operations: Sometimes concatenated with other data and then used as Operations: Sometimes concatenated with other data and then used as
input to a cryptographic hash function. Frequently stored as is, input to a cryptographic hash function. Frequently stored as is,
or hashed. or hashed.
How much tolerance for change from existing stringprep approach? Not How much tolerance for change from existing Stringprep approach? Not
sure. Non-ASCII IMAP passwords are currently prohibited by IMAP sure. Non-ASCII IMAP passwords are currently prohibited by IMAP
(RFC 3501), however they are likely to be in widespread use. (RFC 3501), however they are likely to be in widespread use.
Background information: RFC 5738 (IMAP INTERNATIONALIZATION): 5. Background information: RFC 5738 (IMAP INTERNATIONALIZATION): 5.
UTF8=USER Capability If the "UTF8=USER" capability is advertised, UTF8=USER Capability If the "UTF8=USER" capability is advertised,
that indicates the server accepts UTF-8 user names and passwords that indicates the server accepts UTF-8 user names and passwords
and applies SASLprep RFC4013 to both arguments of the LOGIN and applies SASLprep RFC4013 to both arguments of the LOGIN
command. The server MUST reject UTF-8 that fails to comply with command. The server MUST reject UTF-8 that fails to comply with
the formal syntax in RFC 3629 RFC3629 or if it encounters Unicode the formal syntax in RFC 3629 RFC3629 or if it encounters Unicode
characters listed in Section 2.3 of SASLprep RFC 4013 RFC4013. characters listed in Section 2.3 of SASLprep RFC 4013 RFC4013.
RFC 4314 (IMAP4 Access Control List (ACL) Extension): 3. Access RFC 4314 (IMAP4 Access Control List (ACL) Extension): 3. Access
control management commands and responses Servers, when processing control management commands and responses Servers, when processing
a command that has an identifier as a parameter (i.e., any of a command that has an identifier as a parameter (i.e., any of
skipping to change at page 25, line 17 skipping to change at page 24, line 25
that indicates the server accepts UTF-8 user names and passwords that indicates the server accepts UTF-8 user names and passwords
and applies SASLprep RFC4013 to both arguments of the LOGIN and applies SASLprep RFC4013 to both arguments of the LOGIN
command. The server MUST reject UTF-8 that fails to comply with command. The server MUST reject UTF-8 that fails to comply with
the formal syntax in RFC 3629 RFC3629 or if it encounters Unicode the formal syntax in RFC 3629 RFC3629 or if it encounters Unicode
characters listed in Section 2.3 of SASLprep RFC 4013 RFC4013. characters listed in Section 2.3 of SASLprep RFC 4013 RFC4013.
RFC 4314 (IMAP4 Access Control List (ACL) Extension): 3. Access RFC 4314 (IMAP4 Access Control List (ACL) Extension): 3. Access
control management commands and responses Servers, when processing control management commands and responses Servers, when processing
a command that has an identifier as a parameter (i.e., any of a command that has an identifier as a parameter (i.e., any of
SETACL, DELETEACL, and LISTRIGHTS commands), SHOULD first prepare SETACL, DELETEACL, and LISTRIGHTS commands), SHOULD first prepare
the received identifier using "SASLprep" profile SASLprep of the the received identifier using "SASLprep" profile SASLprep of the
"stringprep" algorithm Stringprep. If the preparation of the "Stringprep" algorithm Stringprep. If the preparation of the
identifier fails or results in an empty string, the server MUST identifier fails or results in an empty string, the server MUST
refuse to perform the command with a BAD response. Note that refuse to perform the command with a BAD response. Note that
Section 6 recommends additional identifier's verification steps. Section 6 recommends additional identifier's verification steps.
and in Section 6: This document relies on SASLprep to describe and in Section 6: This document relies on SASLprep to describe
steps required to perform identifier canonicalization steps required to perform identifier canonicalization
(preparation). The preparation algorithm in SASLprep was (preparation). The preparation algorithm in SASLprep was
specifically designed such that its output is canonical, and it is specifically designed such that its output is canonical, and it is
well-formed. However, due to an anomaly PR29 in the specification well-formed. However, due to an anomaly PR29 in the specification
of Unicode normalization, canonical equivalence is not guaranteed of Unicode normalization, canonical equivalence is not guaranteed
for a select few character sequences. Identifiers prepared with for a select few character sequences. Identifiers prepared with
skipping to change at page 26, line 36 skipping to change at page 25, line 45
distinct users are treated as the same user. But note that the distinct users are treated as the same user. But note that the
trace field is not authenticated, so it can be easily falsified. trace field is not authenticated, so it can be easily falsified.
Tolerance of changes in the community The community would be Tolerance of changes in the community The community would be
flexible. flexible.
Delimiters No internal structure, but see comments above about Delimiters No internal structure, but see comments above about
frequent use of email addresses. frequent use of email addresses.
Background information: The Anonymous Mechanism The mechanism Background information: The Anonymous Mechanism The mechanism
consists of a single message from the client to the server. The consists of a single message from the client to the server. The
client may include in this message trace information in the form client may include in this message trace information in the form
of a string of UTF-8-encoded Unicode characters prepared in of a string of UTF-8-encoded Unicode characters prepared in
accordance with StringPrep and the "trace" stringprep profile accordance with StringPrep and the "trace" Stringprep profile
defined in Section 3 of this document. The trace information, defined in Section 3 of this document. The trace information,
which has no semantical value, should take one of two forms: an which has no semantical value, should take one of two forms: an
Internet email address, or an opaque string that does not contain Internet email address, or an opaque string that does not contain
the '@' (U+0040) character and that can be interpreted by the the '@' (U+0040) character and that can be interpreted by the
system administrator of the client's domain. For privacy reasons, system administrator of the client's domain. For privacy reasons,
an Internet email address or other information identifying the an Internet email address or other information identifying the
user should only be used with permission from the user. 3. The user should only be used with permission from the user. 3. The
"trace" Profile of "Stringprep" This section defines the "trace" "trace" Profile of "Stringprep" This section defines the "trace"
profile of StringPrep. This profile is designed for use with the profile of StringPrep. This profile is designed for use with the
SASL ANONYMOUS Mechanism. Specifically, the client is to prepare SASL ANONYMOUS Mechanism. Specifically, the client is to prepare
skipping to change at page 29, line 24 skipping to change at page 28, line 36
Disallowed characters: n/a (per-method) Disallowed characters: n/a (per-method)
String classes: Although some EAP methods may use a syntax similar String classes: Although some EAP methods may use a syntax similar
to other types of identifiers, EAP mandates that the actual values to other types of identifiers, EAP mandates that the actual values
must not be assumed to be identifiers usable with anything else. must not be assumed to be identifiers usable with anything else.
Internal structure: n/a (per-method) Internal structure: n/a (per-method)
User output: Identifiers are never human displayed except perhaps as User output: Identifiers are never human displayed except perhaps as
they're typed by a human. they're typed by a human.
Operations: n/a (per-method) Operations: n/a (per-method)
Community considerations: There is no resistance to change for the Community considerations: There is no resistance to change for the
base EAP protocol (as noted, the WG didn't want the existing base EAP protocol (as noted, the WG didn't want the existing
text). However actual use of stringprep, if any, within specific text). However actual use of Stringprep, if any, within specific
EAP methods may have resistance. It is currently unknown whether EAP methods may have resistance. It is currently unknown whether
any EAP methods use stringprep. any EAP methods use Stringprep.
Appendix C. Changes between versions
Note to RFC Editor: This section should be removed prior to
publication.
C.1. 00
First WG version. Based on
draft-blanchet-precis-problem-statement-00.
C.2. 01
o Made clear that the document is talking only about Unicode code
points, and not any particular encoding.
o Substantially reorganized the document along the lines of the
review template at <http://trac.tools.ietf.org/wg/precis/trac/
wiki/StringprepReviewTemplate>.
o Included specific questions for each topic for consideration.
o Moved spot for individual protocol review to appendix. Not
populated yet.
C.3. 02
o Cleared up details of comparison classes
o Added a section on changes in Unicode
C.4. 03
o Aligned comparison discussion with identifier discussion from
draft-iab-identifier-comparison-00
o Added section on classes of strings ("Namey" and so on)
C.5. 04
Keepalive version
C.6. 05
o Changed classes of strings to align with framework doc
o Altered table in Appendix A
o Added all profiles evaluations from the wg wiki in appendix B
C.7. 06
o Respond to comments received in WGLC
o Removed classes of strings (also from Appendix A)
o Moved inclusion/exclusion distinction to Introduction
o Fix some sentences to clarify terminology and add or fix
references
Authors' Addresses Authors' Addresses
Marc Blanchet Marc Blanchet
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec, QC G1R 2E1 Quebec, QC G1R 2E1
Canada Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
 End of changes. 49 change blocks. 
139 lines changed or deleted 93 lines changed or added

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