draft-ietf-precis-problem-statement-00.txt   draft-ietf-precis-problem-statement-01.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: April 21, 2011 October 18, 2010 Expires: June 12, 2011 December 9, 2010
Stringprep Revision Problem Statement Stringprep Revision Problem Statement
draft-ietf-precis-problem-statement-00.txt draft-ietf-precis-problem-statement-01.txt
Abstract Abstract
Using Unicode codepoints in protocol strings that expect comparison Using Unicode codepoints in protocol strings that expect comparison
with other strings [[anchor1: The WG will need to decide whether with other strings requires preparation of the string that contains
"other strings" is too broad. In particular, what about protocol
slots that can take strings other than plain ASCII?
--ajs@shinkuro.com]] 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
need to be similarly updated or a replacement of Stringprep need to need to be similarly updated or a replacement of Stringprep needs to
be designed. This document outlines the issues to be faced by those be designed. This document outlines the issues to be faced by those
designing a Stringprep replacement. designing a Stringprep replacement.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 21, 2011. This Internet-Draft will expire on June 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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. Usage and Issues of Stringprep . . . . . . . . . . . . . . . . 5 2. Issues raised during newprep BOF . . . . . . . . . . . . . . . 5
2.1. Issues raised during newprep BOF . . . . . . . . . . . . . 5 3. Major Topics for Consideration . . . . . . . . . . . . . . . . 6
2.2. Specific issues with particular Stringprep profiles . . . 6 3.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Inclusion vs. exclusion of characters . . . . . . . . . . 6 3.1.1. Comparison methods . . . . . . . . . . . . . . . . . . 6
2.4. Stringprep and NFKC . . . . . . . . . . . . . . . . . . . 7 3.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 7
2.5. Case mapping . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Dealing with characters . . . . . . . . . . . . . . . . . 7
2.6. Whether to use ASCII-compatible encoding . . . . . . . . . 7 3.2.1. Case folding, case sensitivity, and case
2.7. Issues with delimiters . . . . . . . . . . . . . . . . . . 8 preservation . . . . . . . . . . . . . . . . . . . . . 7
3. Considerations for Stringprep replacement . . . . . . . . . . 8 3.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3.2.3. Character mapping . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. Prohibited characters . . . . . . . . . . . . . . . . 8
6. Discussion home for this draft . . . . . . . . . . . . . . . . 9 3.2.5. Internal structure, delimiters, and special
7. Informative References . . . . . . . . . . . . . . . . . . . . 9 characters . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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.2. User output . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations for Stringprep replacement . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Discussion home for this draft . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Protocols known to be using Stringprep . . . . . . . 15
Appendix B. Changes between versions . . . . . . . . . . . . . . 15
B.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
B.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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
UTF-8 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
with different constraints than IDNA2003. with different constraints than 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. 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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 Unicode generates a stable and complete table of the supported Unicode
codepoints. This algorithm is based on an inclusion-based approach, codepoints. This algorithm is based on an inclusion-based approach,
instead of the exclusion-based approach of Stringprep/Nameprep. instead of the exclusion-based approach of Stringprep/Nameprep.
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 some listed above that defined Stringprep profiles. It also lists some
early conclusions and requirements for a potential replacement of early conclusions and requirements for a potential replacement of
Stringprep. Stringprep.
2. Usage and Issues of Stringprep 2. Issues raised during newprep BOF
2.1. Issues raised during newprep BOF
During IETF 77, a BOF discussed the current state of the protocols During IETF 77, a BOF discussed the current state of the protocols
that have defined Stringprep profiles [NEWPREP]. The main that have defined Stringprep profiles [NEWPREP]. The main
conclusions are : conclusions are:
o Stringprep is bound to a specific version of Unicode: 3.2. o Stringprep is bound to a specific version of Unicode: 3.2.
Stringprep has not been updated to new versions of Unicode. Stringprep has not been updated to new versions of Unicode.
Therefore, the protocols using Stringprep are stuck to Unicode Therefore, the protocols using Stringprep are stuck to Unicode
3.2. 3.2.
o The protocols need to be updated to support new versions of o The protocols need to be updated to support new versions of
Unicode. The protocols would like to not be bound to a specific Unicode. The protocols would like to not be bound to a specific
version of Unicode, but rather have better Unicode agility in the version of Unicode, but rather have better Unicode agility in the
way of IDNA2008. This is important partly because it is usually way 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
skipping to change at page 6, line 17 skipping to change at page 6, line 15
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 IQN, which is very similar o iSCSI uses a Stringprep profile for the IQN, which is very similar
to (often is) a DNS domain name. to (often is) a 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.
During the newprep BOF, it was the consensus of the attendees that it During the newprep BOF, it was the consensus of the attendees that it
would be highly preferable 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
defined so that the protocols could use internationalized strings defined so that the protocols could use internationalized strings
without a lot of specialized internationalization work, since without a lot of specialized internationalization work, since
internationalization expertise is not available in the respective internationalization expertise is not available in the respective
protocols or working groups. protocols or working groups.
2.2. Specific issues with particular Stringprep profiles 3. Major Topics for Consideration
[[anchor6: This section is where issues raised in the individual This section provides an overview of major topics that a Stringprep
profile reviews goes. A review of the WG trac state on 2010-10-06 of replacement needs to address. The headings correspond roughly with
the tracker suggests those reviews haven't happened yet. categories under which known Stringprep-using protocol RFCs have been
--ajs@shinkuro.com]] evaluated. For the details of those evaluations, see Appendix A.
2.3. Inclusion vs. exclusion of characters 3.1. Comparison
One of the primary changes of IDNA2008 is in the way it approaches 3.1.1. Comparison methods
Unicode characters. IDNA2003 created an explicit list of excluded or
mapped-away characters; anything in Unicode 3.2 that was not so
listed could be assumed to be allowed under the protocol. IDNA2008
begins instead from the assumption that characters are disallowed,
and then relies on Unicode properties to derive whether a given
character actually is allowed in the protocol.
Moreover, there is more than one class of "allowed in the protocol". Identifiers can be conveniently organized into three classes or
While some characters are simply disallowed, some are allowed only in "buckets":
certain contexts. The reasons for the context-dependent rules have
to do with the way some characters are used. For instance, the ZERO
WIDTH JOINER and ZERO WIDTH NON-JOINER characters (ZWJ, U+200D and
ZWNJ, U+200C) are allowed with contextual rules because they are
required in some circumstances, yet are considered punctuation by
Unicode and would therefore be DISALLOWED under the usual IDNA2008
derivation rules.
The working group needs to decide whether similar contextual cases 1. Identifiers that must compare equally byte for byte. [[anchor4:
need to be supported. In the Jabber discussion from Beijing, Ted Hardie asked that (1)
actually be "codepoint for codepoint". Is that what's intended?
It seems to me that that is already a case of (2), because
there's an algorithm to compare (say) my UTF-16 and your UCS-4.
Discussion would be helpful, please. --ajs@crankycanuck.ca]]
2. Identifiers that do not compare equally byte for byte, but that
can always be compared for equality based on an algorithm
everyone can agree on.
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.)
2.4. Stringprep and NFKC A subclass of case (3) is one in which, within some constrained
population, the comparison rules are clear even though such rules are
not universally applicable. So, for instance, users of US-ASCII may
all agree on a comparison function, but the set of US-ASCII users and
Turkish users may not all agree about the same comparison function.
For the purposes of the precis work, it is not plain whether this
subclass case is relevant, so categorization will include it.
In the section treating the existing known cases, Appendix A, these
"buckets" will be called Type 1, Type 2, Type 3, and Type 3a.
3.1.2. Effect of comparison
The comparisons outlined in Section 3.1.1 may have different effects
when applied. It is necessary to evaluate the effects if a
comparison results in a false positive, and what the effects are if a
comparison results in a false negative. It is particularly important
to evaluate the effects on security of these answers.
3.2. Dealing with characters
3.2.1. Case folding, case sensitivity, and case preservation
In IDNA2003, labels are always mapped to lower case before the
Punycode transformation. In IDNA2003, there is no mapping at all:
input is either a valid U-label or it is not. At the same time,
upper-case characters are by definition not valid U-labels, because
they fall into the Unstable category (category B) of [RFC5892].
If there are protocols that require upper and lower cases be
preserved, then the analogy with IDNA2008 will break down.
Accordingly, existing protocols are to be evaluated according to the
following criteria:
1. Does the protocol use case folding? For all blocks of code
points, or just for certain subsets?
2. Is the system or protocol case sensitive?
3. Does the system or protocol preserve case?
3.2.2. Stringprep and NFKC
Stringprep profiles may use normalization. If they do, they use NFKC Stringprep profiles may use normalization. If they do, they use NFKC
[UAX15]. It is not clear that NFKC is the right normalization to use [UAX15]. It is not clear that NFKC is the right normalization to use
in all cases. In [UAX15], there is the following observation in all cases. In [UAX15], there is the following observation
regarding Normalization Forms KC and KD: "It is best to think of regarding Normalization Forms KC and KD: "It is best to think of
these Normalization Forms as being like uppercase or lowercase these Normalization Forms as being like uppercase or lowercase
mappings: useful in certain contexts for identifying core meanings, mappings: useful in certain contexts for identifying core meanings,
but also performing modifications to the text that may not always be but also performing modifications to the text that may not always be
appropriate." For things like the spelling of users' names, then, appropriate." For things like the spelling of users' names, then,
NKFC may not be the best form to use. At the same time, one of the NFKC may not be the best form to use. At the same time, one of the
nice things about NFKC is that it deals with the width of characters nice things about NFKC is that it deals with the width of characters
that are otherwise similar, by canonicalizing half-width to full- that are otherwise similar, by canonicalizing half-width to full-
width. This mapping step can be crucial in practice. The WG will width. This mapping step can be crucial in practice. The WG will
need to analyze the different use profiles and consider whether NFKC need to analyze the different use profiles and consider whether NFKC
or NFC is a better normalization for each profile. or NFC is a better normalization for each profile.
2.5. Case mapping For the purposes of evaluating an existing example of Stringprep use,
it is helpful to know whether it uses no normalization, NFKC, or NFC.
In IDNA2003, labels are always mapped to lower case before the 3.2.3. Character mapping
Punycode transformation. In IDNA2003, there is no mapping at all:
input is either a valid U-label or it is not. At the same time,
upper-case characters are by definition not valid U-labels, because
they fall into the Unstable category (category B) of [RFC5892].
If there are protocols that require upper and lower cases be Along with the case mapping issues raised in Section 3.2.1, there is
preserved, then the analogy with IDNA2008 will break down. The the question of whether some characters are mapped either to other
working group will need to decide whether there are any cases that characters or to nothing during Stringprep. [RFC3454], Section 3,
require upper case, and what to do about it if so. outlines a number of characters that are mapped to nothing, and also
permits Stringprep profiles to define their own mappings.
2.6. Whether to use ASCII-compatible encoding 3.2.4. Prohibited characters
The development of IDNA2008 depended on the notion that there was a Along with case folding and other character mappings, many protocols
narrow repertoire of reasonable traditional labels, and what was have characters that are simply disallowed. For example, control
necessary was to internationalize that repertoire rather than to characters and special characters such as "@" or "/" may be
incorporate any characters into domain name labels. More exactly, prohibited in a protocol.
the idea was to internationalize the traditional hostname rules (the
"LDH rule". See [RFC4690], section 5.1.). Efforts to
internationalize email ([RFC5336]) have started from different
assumptions. The email example suggests that in some cases, the
right answer might be to internationalize the target protocol rather
than to depend on a technology to ensure protocol slots can use only
ASCII. The working group will need to determine which approach is
correct for the different use-cases.
2.7. Issues with delimiters One of the primary changes of IDNA2008 is in the way it approaches
Unicode code points. IDNA2003 created an explicit list of excluded
or mapped-away characters; anything in Unicode 3.2 that was not so
listed could be assumed to be allowed under the protocol. IDNA2008
begins instead from the assumption that code points are disallowed,
and then relies on Unicode properties to derive whether a given code
point actually is allowed in the protocol.
There are two kinds of issues to address with delimiters. First, Moreover, there is more than one class of "allowed in the protocol".
exactly where a delimiter will appear on the screen when dealing with While some code points are disallowed outright, some are allowed only
bidirectional parts of a string can be extremely surprising. In the in certain contexts. The reasons for the context-dependent rules
case of IDNA2008, just what to do in these cases remains a display have to do with the way some characters are used. For instance, the
issue (there is no question about the wire format, because the wire ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER (ZWJ, U+200D and ZWNJ,
format is an A-label and it is always left to right). U+200C) are allowed with contextual rules because they are required
in some circumstances, yet are considered punctuation by Unicode and
would therefore be DISALLOWED under the usual IDNA2008 derivation
rules.
Second, there is the question of whether to include different kinds 3.2.5. Internal structure, delimiters, and special characters
of protocol separators. For instance, FULL STOP, U+002E (.) may not
be available on all keyboards. In addition, in some languages there
is more than one full stop which are variants of one another. The
working group will need to decide how to handle such cases: whether
there will be a mapping, some restrictions, or something else.
3. Considerations for Stringprep replacement IDNA2008 has a special problem with delimiters, because the delimiter
"character" in the DNS wire format is not really part of the data.
In DNS, the wire format indicates label length. When the label is
presented in presentation format as part of a fully qualified domain
name, the label separator FULL STOP, U+002E (.) is used. But because
that label separator does not travel with the wire format of the
domain name, there is no way to encode a different,
"internationalized" separator in IDNA2008.
Other protocols may include characters with similar special meaning
within the protocol. Common characters for these purposes include
FULL STOP, U+002E (.); COMMERCIAL AT, U+0040 (@); HYPHEN-MINUS,
U+002D (-); SOLIDUS, U+002F (/); and LOW LINE, U+005F (_). The mere
inclusion of such a character in the protocol is not enough for it to
be considered similar to another protocol using the same character;
instead, handling of the character must be taken into consideration
as well.
An important issue to tackle here is whether it is valuable to map to
or from these special characters as part of the Stringprep
replacement. In some locales, the analogue to FULL STOP, U+002E is
some other character, and users may expect to be able to substitute
their normal stop for FULL STOP.
3.3. Where the data comes from and where it goes
3.3.1. User input and the source of protocol elements
Some protocol elements are provided by users, and others are not.
Those that are not may presumably be subject to greater restrictions,
whereas those that users provide likely need to permit the broadest
range of code points. The following questions are helpful:
1. Do users input the strings directly?
2. If so, how? (keyboard, stylus, voice, copy-paste, etc.)
3. Where do we place the dividing line between user interface and
protocol? (see [RFC5895])
3.3.2. User output
Just as only some protocol elements are expected to be entered
directly by users, only some protocol elements are intended to be
consumed directly by users. It is important to know how users are
expected to be able to consume the protocol elements, because
different environments present different challenges. An element that
is only ever delivered as part of a vCard remains in machine-readable
format, so the problem of visual confusion is not a great one. Is
the protocol element published as part of a vCard, a web directory,
on a business card, or on "the side of a bus"? Do users use the
protocol element as an identifier (which means that they might enter
it again in some other context)?
3.3.3. Operations
Some strings are useful as part of the protocol but are not used as
input to other operations (for instance, purely informative or
descriptive text). Other strings are used directly as input to other
operations (such as cryptographic hash functions), or are used
together with other strings to (such as concatenating a string with
some others to form a unique identifier).
3.3.3.1. String classes
Strings often have a similar function in different protocols. For
instance, many different protocols contain user identifiers or
passwords. A single profile for all such uses might be desirable.
Often, a string in a protocol is effectively a protocol element from
another protocol. For instance, different systems might use the same
credentials database for authentication.
3.3.3.2. Community considerations
A Stringprep replacement that does anything more than just update
Stringprep to the latest version of Unicode will probably entail some
changes. It is important to identify the willingness of the
protocol-using community to accept backwards-incompatible changes.
By the same token, it is important to evaluate the desire of the
community for features not available under Stringprep.
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.
o The sets of string classes need to be evaluated for the following o The sets of string classes need to be evaluated according to the
properties: considerations that make up the headings in Section 3
* the normalization needed (NFC vs NFKC); o It is reasonable to limit scope to Unicode code points, and rule
* whether case-folding, case preservation, and case-insensitive the mapping of data from other character encodings outside the
matching is needed; scope of this effort.
* what restrictions on input are reasonable for the class (i.e.
whether there is something like an "LDH rule" for the class),
or whether the ASCII-only input in the protocol slot is lightly
constrained;
* the extent to which bidi considerations are important for the
class.
Existing deployments already depend on Stringprep profiles. Existing deployments already depend on Stringprep profiles.
Therefore, the working group will need to consider the effects of any Therefore, the working group will need to consider the effects of any
new strategy on existing deployments. By way of comparison, it is new strategy on existing deployments. By way of comparison, it is
worth noting that some characters were acceptable in IDNA labels worth noting that some characters were acceptable in IDNA labels
under IDNA2003, but are not protocol-valid under IDNA2008 (and under IDNA2003, but are not protocol-valid under IDNA2008 (and
conversely). Different implementers may make different decisions conversely). Different implementers may make different decisions
about what to do in such cases; this could have interoperability about what to do in such cases; this could have interoperability
effects. The working group will need to trade better support for effects. The working group will need to trade better support for
different linguistic environments against the potential side effects different linguistic environments against the potential side effects
of backward incompatibility. of backward incompatibility.
4. Security Considerations 5. 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.
5. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Discussion home for this draft 7. Discussion home for this draft
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.
7. Informative References 8. Acknowledgements
This document is the product of the PRECIS IETF Working Group, and
participants in that Working Group were helpful in addressing issues
with the text.
Specific contributions came from Alan DeKok, Alexey Melnikov, Peter
Saint-Andre, Dave Thaler, and Yoshiro Yoneya.
Dave Thaler provided the "buckets" insight in Section 3.1.1, central
to the organization of the problem.
9. Informative References
[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 11, line 41 skipping to change at page 14, line 10
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
RFC 5122, February 2008. RFC 5122, February 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008.
[RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K.
Shumard, "IAX: Inter-Asterisk eXchange Version 2", Shumard, "IAX: Inter-Asterisk eXchange Version 2",
RFC 5456, February 2010. RFC 5456, February 2010.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
skipping to change at page 12, line 29 skipping to change at page 14, line 44
RFC 5892, August 2010. RFC 5892, August 2010.
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
Internationalized Domain Names for Applications (IDNA)", Internationalized Domain Names for Applications (IDNA)",
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
Internationalized Domain Names in Applications (IDNA)
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
[[anchor21: This is where I'm supposed to have put the stuff already
in trac. --ajs@crankycanuck.ca]]
Appendix B. Changes between versions
Note to RFC Editor: This section should be removed prior to
publication.
B.1. 00
First WG version. Based on
draft-blanchet-precis-problem-statement-00.
B.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.
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
 End of changes. 35 change blocks. 
109 lines changed or deleted 261 lines changed or added

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