draft-ietf-precis-problem-statement-02.txt   draft-ietf-precis-problem-statement-03.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: October 2, 2011 March 31, 2011 Expires: January 12, 2012 July 11, 2011
Stringprep Revision Problem Statement Stringprep Revision Problem Statement
draft-ietf-precis-problem-statement-02.txt draft-ietf-precis-problem-statement-03.txt
Abstract Abstract
Using Unicode codepoints in protocol strings that expect comparison Using Unicode codepoints in protocol strings that expect comparison
with other strings requires preparation of the string that contains with other strings requires preparation of the string that contains
the Unicode codepoints. Internationalizing Domain Names in the Unicode codepoints. Internationalizing Domain Names in
Applications (IDNA2003) defined and used Stringprep and Nameprep. Applications (IDNA2003) defined and used Stringprep and Nameprep.
Other protocols subsequently defined Stringprep profiles. A new Other protocols subsequently defined Stringprep profiles. A new
approach different from Stringprep and Nameprep is used for a approach different from Stringprep and Nameprep is used for a
revision of IDNA2003 (called IDNA2008). Other Stringprep profiles revision of IDNA2003 (called IDNA2008). Other Stringprep profiles
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 October 2, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues raised during newprep BOF . . . . . . . . . . . . . . . 5 2. Issues raised during newprep BOF . . . . . . . . . . . . . . . 5
3. Major Topics for Consideration . . . . . . . . . . . . . . . . 6 3. Major Topics for Consideration . . . . . . . . . . . . . . . . 6
3.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Comparison methods . . . . . . . . . . . . . . . . . . 6 3.1.1. Types of Identifiers . . . . . . . . . . . . . . . . . 6
3.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 7 3.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 7
3.2. Dealing with characters . . . . . . . . . . . . . . . . . 7 3.2. Dealing with characters . . . . . . . . . . . . . . . . . 7
3.2.1. Case folding, case sensitivity, and case 3.2.1. Case folding, case sensitivity, and case
preservation . . . . . . . . . . . . . . . . . . . . . 7 preservation . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 7 3.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 7
3.2.3. Character mapping . . . . . . . . . . . . . . . . . . 8 3.2.3. Character mapping . . . . . . . . . . . . . . . . . . 8
3.2.4. Prohibited characters . . . . . . . . . . . . . . . . 8 3.2.4. Prohibited characters . . . . . . . . . . . . . . . . 8
3.2.5. Internal structure, delimiters, and special 3.2.5. Internal structure, delimiters, and special
characters . . . . . . . . . . . . . . . . . . . . . . 9 characters . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Where the data comes from and where it goes . . . . . . . 9 3.3. Where the data comes from and where it goes . . . . . . . 9
3.3.1. User input and the source of protocol elements . . . . 9 3.3.1. User input and the source of protocol elements . . . . 9
3.3.2. User output . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. User output . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 10 3.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations for Stringprep replacement . . . . . . . . . . 11 3.3.4. Some useful classes of strings . . . . . . . . . . . . 11
4. Considerations for Stringprep replacement . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Discussion home for this draft . . . . . . . . . . . . . . . . 12 7. Discussion home for this draft . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Informative References . . . . . . . . . . . . . . . . . . . . 12 9. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Protocols known to be using Stringprep . . . . . . . 15 Appendix A. Protocols known to be using Stringprep . . . . . . . 16
Appendix B. Changes between versions . . . . . . . . . . . . . . 16 Appendix B. Detailed discussion of protocols under
B.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 consideration . . . . . . . . . . . . . . . . . . . . 17
B.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Changes between versions . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 C.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
C.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
C.3. 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
C.4. 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Internationalizing Domain Names in Applications (IDNA2003) [RFC3490], Internationalizing Domain Names in Applications (IDNA2003) [RFC3490],
[RFC3491], [RFC3492], [RFC3454] described a mechanism for encoding [RFC3491], [RFC3492], [RFC3454] described a mechanism for encoding
Unicode labels making up Internationalized Domain Names (IDNs) as Unicode labels making up Internationalized Domain Names (IDNs) as
standard DNS labels. The labels were processed using a method called standard DNS labels. The labels were processed using a method called
Nameprep [RFC3491] and Punycode [RFC3492]. That method was specific Nameprep [RFC3491] and Punycode [RFC3492]. That method was specific
to IDNA2003, but is generalized as Stringprep [RFC3454]. The general to IDNA2003, but is generalized as Stringprep [RFC3454]. The general
mechanism can be used to help other protocols with similar needs, but mechanism can be used to help other protocols with similar needs, but
skipping to change at page 4, line 27 skipping to change at page 4, line 27
Stringprep profiles. Known IETF specifications using Stringprep are Stringprep profiles. Known IETF specifications using Stringprep are
listed below: 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 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]; CPIM mapping [RFC3922] (the latter of these relies on the former);
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 o The SASLprep profile [RFC4013] for use in the Simple
Authentication and Security Layer (SASL), and SASL itself Authentication and Security Layer (SASL), and SASL itself
[RFC4422]; [RFC4422];
o TLS [RFC4279]; o TLS [RFC4279];
o IMAP4 using SASLprep [RFC4314]; o IMAP4 using SASLprep [RFC4314];
o The trace profile [RFC4505] for use with the SASL ANONYMOUS o The trace profile [RFC4505] for use with the SASL ANONYMOUS
mechanism; 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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
3. Major Topics for Consideration 3. Major Topics for Consideration
This section provides an overview of major topics that a Stringprep This section provides an overview of major topics that a Stringprep
replacement needs to address. The headings correspond roughly with replacement needs to address. The headings correspond roughly with
categories under which known Stringprep-using protocol RFCs have been categories under which known Stringprep-using protocol RFCs have been
evaluated. For the details of those evaluations, see Appendix A. evaluated. For the details of those evaluations, see Appendix A.
3.1. Comparison 3.1. Comparison
3.1.1. Comparison methods 3.1.1. Types of Identifiers
Identifiers can be conveniently organized into three classes or Following [I-D.iab-identifier-comparison], we can organize
"buckets": identifiers into three classes in respect of how they may be compared
with one another:
1. Identifiers that must compare equally byte for byte. Absolute Identifiers Identifiers that can be compared byte-by-byte
2. Identifiers that do not compare equally byte for byte, but that for equality.
can always be compared for equality based on an algorithm Definite Identifiers Identifiers that have a well-defined comparison
everyone can agree on. (This includes cases like comparison of algorithm on which all parties agree.
Unicode codepoints that are in different encodings: two different Indefinite Identifiers Identifiers that have no single comparison
encodings do not match byte for byte, but can all be recoded to a algorithm on which all parties agree.
single encoding which then does match bye for byte.)
3. Identifiers for which there is no single comparison algorithm on
which everyone can agree. (For instance, there may be locale-
sensitive comparison rules for identifiers.)
A subclass of case (3) is one in which, within some constrained Definite Identifiers include cases like the comparison of Unicode
population, the comparison rules are clear even though such rules are code points in different encodings: they do not match byte for byte,
not universally applicable. So, for instance, users of US-ASCII may but can all be converted to a single encoding which then does match
all agree on a comparison function, but the set of US-ASCII users and byte for byte. Indefinite Identifiers are sometimes algorithmically
Turkish users may not all agree about the same comparison function. comparable by well-specified subsets of parties. For more discussion
For the purposes of the present work, it is not plain whether this of these categories, see [I-D.iab-identifier-comparison].
subclass case is relevant, so categorization will include it.
In the section treating the existing known cases, Appendix A, these The section on treating the existing known cases, Appendix A uses
"buckets" will be called Type 1, Type 2, Type 3, and Type 3a. these categories.
3.1.2. Effect of comparison 3.1.2. Effect of comparison
The comparisons outlined in Section 3.1.1 may have different effects The three classes of comparison style outlined in Section 3.1.1 may
when applied. It is necessary to evaluate the effects if a have different effects when applied. It is necessary to evaluate the
comparison results in a false positive, and what the effects are if a effects if a comparison results in a false positive, and what the
comparison results in a false negative, especially in terms of the effects are if a comparison results in a false negative, especially
consequences to security and usability. in terms of the consequences to security and usability.
3.2. Dealing with characters 3.2. Dealing with characters
This section outlines a range of issues having to do with characters This section outlines a range of issues having to do with characters
in the target protocols, and spends some effort to outline the ways in the target protocols, and spends some effort to outline the ways
in which IDNA2008 might be a good analogy to other protocols, and in which IDNA2008 might be a good analogy to other protocols, and
ways in which it might be a poor one. ways in which it might be a poor one.
3.2.1. Case folding, case sensitivity, and case preservation 3.2.1. Case folding, case sensitivity, and case preservation
skipping to change at page 8, line 47 skipping to change at page 8, line 43
point actually is allowed in the protocol. point actually is allowed in the protocol.
Moreover, there is more than one class of "allowed in the protocol". Moreover, there is more than one class of "allowed in the protocol".
While some code points are disallowed outright, some are allowed only While some code points are disallowed outright, some are allowed only
in certain contexts. The reasons for the context-dependent rules in certain contexts. The reasons for the context-dependent rules
have to do with the way some characters are used. For instance, the have to do with the way some characters are used. For instance, the
ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER (ZWJ, U+200D and ZWNJ, ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER (ZWJ, U+200D and ZWNJ,
U+200C) are allowed with contextual rules because they are required U+200C) are allowed with contextual rules because they are required
in some circumstances, yet are considered punctuation by Unicode and in some circumstances, yet are considered punctuation by Unicode and
would therefore be DISALLOWED under the usual IDNA2008 derivation would therefore be DISALLOWED under the usual IDNA2008 derivation
rules. The goal is to provide the widest possible repetoire of code rules. The goal is to provide the widest possible repertoire of code
points possible and consistent with the traditional DNS, trusting to points possible and consistent with the traditional DNS, trusting to
the operators of individual zones to make sensible (and usually more the operators of individual zones to make sensible (and usually more
restrictive) policies for their zones. restrictive) policies for their zones.
IDNA2008 may be a poor model for what other protocols ought to do in IDNA2008 may be a poor model for what other protocols ought to do in
this case, because it is designed to support an old protocol that is this case, because it is designed to support an old protocol that is
designed to operate on the scale of the entire Internet. Moreover, designed to operate on the scale of the entire Internet. Moreover,
IDNA2008 is intended to be deployed without any change to the base IDNA2008 is intended to be deployed without any change to the base
DNS protocol. Other protocols may aim at deployment in more local DNS protocol. Other protocols may aim at deployment in more local
environments, or may have protocol version negotiation built in. environments, or may have protocol version negotiation built in.
skipping to change at page 9, line 38 skipping to change at page 9, line 33
inclusion of such a character in the protocol is not enough for it to inclusion of such a character in the protocol is not enough for it to
be considered similar to another protocol using the same character; be considered similar to another protocol using the same character;
instead, handling of the character must be taken into consideration instead, handling of the character must be taken into consideration
as well. as well.
An important issue to tackle here is whether it is valuable to map to An important issue to tackle here is whether it is valuable to map to
or from these special characters as part of the Stringprep or from these special characters as part of the Stringprep
replacement. In some locales, the analogue to FULL STOP, U+002E is replacement. In some locales, the analogue to FULL STOP, U+002E is
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
predcitability arguments in favour of treating names with FULL STOP, predictability arguments in favour of treating names with FULL STOP,
U+002E in them just the way they are treated under IDNA2008. U+002E in them just the way they are treated under IDNA2008.
3.3. Where the data comes from and where it goes 3.3. Where the data comes from and where it goes
3.3.1. User input and the source of protocol elements 3.3.1. User input and the source of protocol elements
Some protocol elements are provided by users, and others are not. Some protocol elements are provided by users, and others are not.
Those that are not may presumably be subject to greater restrictions, Those that are not may presumably be subject to greater restrictions,
whereas those that users provide likely need to permit the broadest whereas those that users provide likely need to permit the broadest
range of code points. The following questions are helpful: range of code points. The following questions are helpful:
skipping to change at page 11, line 21 skipping to change at page 11, line 15
This approach depends crucially on the idea that code points, once This approach depends crucially on the idea that code points, once
valid for a protocol profile, will not later be made invalid. That valid for a protocol profile, will not later be made invalid. That
is not a guarantee currently provided by Unicode. Properties of code is not a guarantee currently provided by Unicode. Properties of code
points may change between versions of Unicode. Rarely, such a change points may change between versions of Unicode. Rarely, such a change
could cause a given code point to become invalid under a protocol could cause a given code point to become invalid under a protocol
profile, even though the code point would be valid with an earlier profile, even though the code point would be valid with an earlier
version of Unicode. This is not merely a theoretical possibility, version of Unicode. This is not merely a theoretical possibility,
because it has occurred ([I-D.faltstrom-5892bis]). because it has occurred ([I-D.faltstrom-5892bis]).
Accordingly, a Stringprep replacement that intends to be Unicode Accordingly, a Stringprep replacement that intends to be Unicode
version agnostic will need to work out a mechansism to address cases version agnostic will need to work out a mechanism to address cases
where incompatible changes occur because of new Unicode versions. where incompatible changes occur because of new Unicode versions.
3.3.4. Some useful classes of strings
With the above considerations in hand, we can usefully classify
strings into the following categories, inspired by those outlined in
[I-D.saintandre-xmpp-i18n]:
Domainy strings Strings that are intended for use in a domain name
slot, as defined in [RFC5890]. Note that domainy strings could be
used outside a domain name slot: the question here is what the
eventual intended use for the string is, and not whether the
string is actually functioning as a domain name at any moment.
Namey strings Strings that are intended for use as identifiers but
that are not domainy strings. Namey strings are normally public
data within the protocol where they are used: these are intended
as identifiers that can be passed around to identify something.
Secretish strings Strings that are intended for use as passwords or
passphrases or other such type of token. Secretish strings are
normally not public data within the protocol where they are used:
they function as a token for authorization, and normally should
not be shared publicly.
Protocolish strings Strings that are intended to be used by the
protocol as free-form strings, but that have some significant
handling within the protocol. For instance, a protocol slot that
allows free-form text where case is not preserved would need to
have case mapping rules applied; in this case, the string would be
a protocolish string.
String blobs Elements of the protocol that look like strings to
users, but that are passed around in the protocol unchanged and
that cannot be used for comparison or other purposes. In effect,
these are strings that are part of a protocol payload, and are not
themselves part of the protocol at all.
4. Considerations for Stringprep replacement 4. Considerations for Stringprep replacement
The above suggests the following direction for the working group: The above suggests the following direction for the working group:
o A stringprep replacement should be defined. o A stringprep replacement should be defined.
o The replacement should take an approach similar to IDNA2008, in o The replacement should take an approach similar to IDNA2008, in
that it enables Unicode agility. that it enables Unicode agility.
o Protocols share similar characteristics of strings. Therefore, o Protocols share similar characteristics of strings. Therefore,
defining i18n preparation algorithms for a (small) set of string defining i18n preparation algorithms for a (small) set of string
classes may be sufficient for most cases and provides the classes may be sufficient for most cases and provides the
coherence among a set of protocol friends. coherence among a set of protocol friends.
skipping to change at page 12, line 27 skipping to change at page 13, line 11
This document is intended to define the problem space discussed on This document is intended to define the problem space discussed on
the precis@ietf.org mailing list. the precis@ietf.org mailing list.
8. Acknowledgements 8. Acknowledgements
This document is the product of the PRECIS IETF Working Group, and This document is the product of the PRECIS IETF Working Group, and
participants in that Working Group were helpful in addressing issues participants in that Working Group were helpful in addressing issues
with the text. with the text.
Specific contributions came from Alan DeKok, Alexey Melnikov, Peter Specific contributions came from David Black, Alan DeKok, Bill
Saint-Andre, Dave Thaler, and Yoshiro Yoneya. McQuillan, Alexey Melnikov, Peter Saint-Andre, Dave Thaler, and
Yoshiro Yoneya.
Dave Thaler provided the "buckets" insight in Section 3.1.1, central Dave Thaler provided the "buckets" insight in Section 3.1.1, central
to the organization of the problem. to the organization of the problem.
9. Informative References 9. Informative References
[I-D.faltstrom-5892bis] [I-D.faltstrom-5892bis]
Faltstrom, P. and P. Hoffman, "The Unicode code points and Faltstrom, P. and P. Hoffman, "The Unicode code points and
IDNA - Unicode 6.0", draft-faltstrom-5892bis-04 (work in IDNA - Unicode 6.0", draft-faltstrom-5892bis-05 (work in
progress), March 2011. progress), June 2011.
[I-D.iab-identifier-comparison]
Thaler, D., "Issues in Identifier Comparison for Security
Purposes", draft-iab-identifier-comparison-00 (work in
progress), July 2011.
[I-D.saintandre-xmpp-i18n]
Saint-Andre, P., "Internationalized Addresses in XMPP",
draft-saintandre-xmpp-i18n-03 (work in progress),
March 2011.
[NEWPREP] "Newprep BoF Meeting Minutes", March 2010. [NEWPREP] "Newprep BoF Meeting Minutes", March 2010.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
skipping to change at page 15, line 50 skipping to change at page 16, line 42
[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.
[UAX15] "Unicode Standard Annex #15: Unicode Normalization Forms", [UAX15] "Unicode Standard Annex #15: Unicode Normalization Forms",
UAX 15, September 2009. UAX 15, September 2009.
Appendix A. Protocols known to be using Stringprep Appendix A. Protocols known to be using Stringprep
[[anchor21: This is where I'm supposed to have put the stuff already The known cases are here described in two ways. The types of
in trac. --ajs@crankycanuck.ca]] identifiers the protocol uses is first called out in the ID type
column (from Section 3.1.1), using the short forms "a" for Absolute,
"d" for Definite, and "i" for Indefinite. Next, there is a column
that contains an "i" if the protocol string comes from user input, an
"o" if the protocol string becomes user-facing output, "b" if both
are true, and "n" if neither is true. The remaining columns have an
"x" if and only if the protocol uses that class, as described in
Section 3.3.4. Values marked "-" indicate that an answer is not
useful; in this case, see detailed discussion in Appendix B.
Appendix B. Changes between versions +------+--------+-------+-------+-------+---------+---------+------+
| RFC | IDtype | User? | Dom'y | Nam'y | Sec'ish | Pro'ish | Blob |
+------+--------+-------+-------+-------+---------+---------+------+
| 3722 | a | o | | x | x | x | |
| 3748 | - | - | - | x | - | - | - |
| 3920 | a,d | b | | x | | x | |
| 4314 | a,d | b | | x | x | x | |
+------+--------+-------+-------+-------+---------+---------+------+
Table 1
[[anchor21: The table still needs to be filled in, I am aware.
--ajs@anvilwalrusden.com]]
Appendix B. Detailed discussion of protocols under consideration
Below are detailed reviews of the protocols under consideration
(where such reviews are available). [[anchor22: These are to be cut
and pasted from the wiki. --ajs@anvilwalrusden.com]]
Appendix C. Changes between versions
Note to RFC Editor: This section should be removed prior to Note to RFC Editor: This section should be removed prior to
publication. publication.
B.1. 00 C.1. 00
First WG version. Based on First WG version. Based on
draft-blanchet-precis-problem-statement-00. draft-blanchet-precis-problem-statement-00.
B.2. 01 C.2. 01
o Made clear that the document is talking only about Unicode code o Made clear that the document is talking only about Unicode code
points, and not any particular encoding. points, and not any particular encoding.
o Substantially reorganized the document along the lines of the o Substantially reorganized the document along the lines of the
review template at <http://trac.tools.ietf.org/wg/precis/trac/ review template at <http://trac.tools.ietf.org/wg/precis/trac/
wiki/StringprepReviewTemplate>. wiki/StringprepReviewTemplate>.
o Included specific questions for each topic for consideration. o Included specific questions for each topic for consideration.
o Moved spot for individual protocol review to appendix. Not o Moved spot for individual protocol review to appendix. Not
populated yet. 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)
Authors' Addresses Authors' Addresses
Marc Blanchet Marc Blanchet
Viagenie Viagenie
2600 boul. Laurier, suite 625 2600 boul. Laurier, suite 625
Quebec, QC G1V 4W1 Quebec, QC G1V 4W1
Canada Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca URI: http://viagenie.ca
Andrew Sullivan Andrew Sullivan
519 Maitland St. 519 Maitland St.
London, ON N6B 2Z5 London, ON N6B 2Z5
Canada Canada
Email: ajs@crankycanuck.ca Email: ajs@anvilwalrusden.com
 End of changes. 25 change blocks. 
52 lines changed or deleted 135 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/