draft-ietf-precis-framework-14.txt   draft-ietf-precis-framework-15.txt 
PRECIS P. Saint-Andre PRECIS P. Saint-Andre
Internet-Draft &yet Internet-Draft &yet
Obsoletes: 3454 (if approved) M. Blanchet Obsoletes: 3454 (if approved) M. Blanchet
Intended status: Standards Track Viagenie Intended status: Standards Track Viagenie
Expires: August 13, 2014 February 9, 2014 Expires: September 15, 2014 March 14, 2014
PRECIS Framework: Preparation and Comparison of Internationalized PRECIS Framework: Preparation and Comparison of Internationalized
Strings in Application Protocols Strings in Application Protocols
draft-ietf-precis-framework-14 draft-ietf-precis-framework-15
Abstract Abstract
Application protocols using Unicode characters in protocol strings Application protocols using Unicode characters in protocol strings
need to properly prepare such strings in order to perform valid need to properly prepare such strings in order to perform valid
comparison operations (e.g., for purposes of authentication or comparison operations (e.g., for purposes of authentication or
authorization). This document defines a framework enabling authorization). This document defines a framework enabling
application protocols to perform the preparation and comparison of application protocols to perform the preparation and comparison of
internationalized strings ("PRECIS") in a way that depends on the internationalized strings ("PRECIS") in a way that depends on the
properties of Unicode characters and thus is agile with respect to properties of Unicode characters and thus is agile with respect to
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 August 13, 2014. This Internet-Draft will expire on September 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 47 skipping to change at page 2, line 47
7.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 19 7.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 19
7.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 19 7.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 19
7.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 20 7.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 20
7.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 20 7.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 20
7.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 20 7.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 20
7.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 20 7.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 20
7.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 21 7.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 21
7.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 21 7.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 21
7.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 21 7.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 21
7.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 21 7.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 21
7.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 21 7.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 22
8. Calculation of the Derived Property . . . . . . . . . . . . . 22 8. Calculation of the Derived Property . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. PRECIS Derived Property Value Registry . . . . . . . . . 23 9.1. PRECIS Derived Property Value Registry . . . . . . . . . 23
9.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 23 9.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 23
9.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 24 9.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10.1. General Issues . . . . . . . . . . . . . . . . . . . . . 26 10.1. General Issues . . . . . . . . . . . . . . . . . . . . . 26
10.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 26 10.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 26
10.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 27 10.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 26
10.4. Local Character Set Issues . . . . . . . . . . . . . . . 27 10.4. Local Character Set Issues . . . . . . . . . . . . . . . 27
10.5. Visually Similar Characters . . . . . . . . . . . . . . 27 10.5. Visually Similar Characters . . . . . . . . . . . . . . 27
10.6. Security of Passwords . . . . . . . . . . . . . . . . . 29 10.6. Security of Passwords . . . . . . . . . . . . . . . . . 29
11. Interoperability Considerations . . . . . . . . . . . . . . . 30 11. Interoperability Considerations . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 30
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Codepoint Table . . . . . . . . . . . . . . . . . . 33 Appendix A. Codepoint Table . . . . . . . . . . . . . . . . . . 33
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 64 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
As described in the problem statement for the preparation and As described in the problem statement for the preparation and
comparison of internationalized strings ("PRECIS") [RFC6885], many comparison of internationalized strings ("PRECIS") [RFC6885], many
IETF protocols have used the Stringprep framework [RFC3454] as the IETF protocols have used the Stringprep framework [RFC3454] as the
skipping to change at page 7, line 16 skipping to change at page 7, line 16
to be excluded from the string. to be excluded from the string.
Unassigned: Defines application behavior in the presence of code Unassigned: Defines application behavior in the presence of code
points that are unknown (i.e., not yet designated) for the version points that are unknown (i.e., not yet designated) for the version
of Unicode used by the application. of Unicode used by the application.
This document defines the valid, contextual rule required, This document defines the valid, contextual rule required,
disallowed, and unassigned rules for the IdentifierClass and disallowed, and unassigned rules for the IdentifierClass and
FreeformClass. As described under Section 4, profiles of these FreeformClass. As described under Section 4, profiles of these
string classes are responsible for defining the width mapping, string classes are responsible for defining the width mapping,
additional mapping, case mapping, normalization, directionality, and additional mappings, case mapping, normalization, directionality, and
exclusion rules. exclusion rules.
3.2. IdentifierClass 3.2. IdentifierClass
Most application technologies need strings that can be used to refer Most application technologies need strings that can be used to refer
to, include, or communicate protocol strings like usernames, file to, include, or communicate protocol strings like usernames, file
names, data feed identifiers, and chatroom names. We group such names, data feed identifiers, and chatroom names. We group such
strings into a class called "IdentifierClass" having the following strings into a class called "IdentifierClass" having the following
features. features.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
o Code points traditionally used as letters and numbers in writing o Code points traditionally used as letters and numbers in writing
systems, i.e., the LetterDigits ("A") category first defined in systems, i.e., the LetterDigits ("A") category first defined in
[RFC5892] and listed here under Section 7.1. [RFC5892] and listed here under Section 7.1.
o Code points in the range U+0021 through U+007E, i.e., the o Code points in the range U+0021 through U+007E, i.e., the
(printable) ASCII7 ("K") rule defined under Section 7.11. These (printable) ASCII7 ("K") rule defined under Section 7.11. These
code points are "grandfathered" into PRECIS and thus are valid code points are "grandfathered" into PRECIS and thus are valid
even if they would otherwise be disallowed according to the even if they would otherwise be disallowed according to the
property-based rules specified in the next section. property-based rules specified in the next section.
Note: Although the PRECIS IdentifierClass re-uses the LetterDigits Informational Note: Although the PRECIS IdentifierClass re-uses
category from IDNA2008, the range of characters allowed in the the LetterDigits category from IDNA2008, the range of characters
IdentifierClass is wider than the range of characters allowed in allowed in the IdentifierClass is wider than the range of
IDNA2008. The main reason is that IDNA2008 applies the Unstable characters allowed in IDNA2008. The main reason is that IDNA2008
category before the LetterDigits category, thus disallowing uppercase applies the Unstable category before the LetterDigits category,
characters, whereas the IdentifierClass does not apply the Unstable thus disallowing uppercase characters, whereas the IdentifierClass
category. does not apply the Unstable category.
3.2.2. Contextual Rule Required 3.2.2. Contextual Rule Required
o A number of characters from the Exceptions ("F") category defined o A number of characters from the Exceptions ("F") category defined
under Section 7.6 (see Section 7.6 for a full list). under Section 7.6 (see Section 7.6 for a full list).
o Joining characters, i.e., the JoinControl ("H") category defined o Joining characters, i.e., the JoinControl ("H") category defined
under Section 7.8. under Section 7.8.
3.2.3. Disallowed 3.2.3. Disallowed
skipping to change at page 9, line 5 skipping to change at page 9, line 5
rejected. rejected.
3.3. FreeformClass 3.3. FreeformClass
Some application technologies need strings that can be used in a Some application technologies need strings that can be used in a
free-form way, e.g., as a password in an authentication exchange (see free-form way, e.g., as a password in an authentication exchange (see
[I-D.ietf-precis-saslprepbis] or a nickname in a chatroom (see [I-D.ietf-precis-saslprepbis] or a nickname in a chatroom (see
[I-D.ietf-precis-nickname]). We group such things into a class [I-D.ietf-precis-nickname]). We group such things into a class
called "FreeformClass" having the following features. called "FreeformClass" having the following features.
Note: Consult Section 10.6 for relevant security considerations when Security Warning: Consult Section 10.6 for relevant security
strings conforming to the FreeformClass, or a profile thereof, are considerations when strings conforming to the FreeformClass, or a
used as passwords. profile thereof, are used as passwords.
3.3.1. Valid 3.3.1. Valid
o Traditional letters and numbers, i.e., the LetterDigits ("A") o Traditional letters and numbers, i.e., the LetterDigits ("A")
category first defined in [RFC5892] and listed here under category first defined in [RFC5892] and listed here under
Section 7.1. Section 7.1.
o Letters and digits other than the "traditional" letters and digits o Letters and digits other than the "traditional" letters and digits
allowed in IDNs, i.e., the OtherLetterDigits ("R") category allowed in IDNs, i.e., the OtherLetterDigits ("R") category
defined under Section 7.18. defined under Section 7.18.
skipping to change at page 10, line 18 skipping to change at page 10, line 18
set SHALL be considered Unassigned for purposes of the FreeformClass, set SHALL be considered Unassigned for purposes of the FreeformClass,
and a string containing such code points SHALL be rejected. and a string containing such code points SHALL be rejected.
4. Profiles 4. Profiles
4.1. Principles 4.1. Principles
This framework document defines the valid, contextual-rule-required, This framework document defines the valid, contextual-rule-required,
disallowed, and unassigned rules for the IdentifierClass and the disallowed, and unassigned rules for the IdentifierClass and the
FreeformClass. A profile of a PRECIS string class MUST define the FreeformClass. A profile of a PRECIS string class MUST define the
width mapping, additional mapping (if any), case mapping, width mapping, additional mappings (if any), case mapping,
normalization, directionality, and exclusion rules. A profile MAY normalization, directionality, and exclusion rules. A profile MAY
also restrict the allowable characters above and beyond the also restrict the allowable characters above and beyond the
definition of the relevant PRECIS string class (but MUST NOT add as definition of the relevant PRECIS string class (but MUST NOT add as
valid any code points or character categories that are disallowed by valid any code points or character categories that are disallowed by
the relevant PRECIS string class). These matters are discussed in the relevant PRECIS string class). These matters are discussed in
the following subsections. the following subsections.
Profiles of the PRECIS string classes MUST register with the IANA as Profiles of the PRECIS string classes MUST register with the IANA as
described under Section 9.3. It is RECOMMENDED for profile names to described under Section 9.3. It is RECOMMENDED for profile names to
be of the form "ProfilenameBaseClass", where the "Profilename" string be of the form "ProfilenameBaseClass", where the "Profilename" string
skipping to change at page 11, line 23 skipping to change at page 11, line 23
characters and mapping of special characters (e.g., non-ASCII space characters and mapping of special characters (e.g., non-ASCII space
characters to ASCII space or certain characters to nothing). characters to ASCII space or certain characters to nothing).
4.1.3. Case Mapping 4.1.3. Case Mapping
The case mapping rule of a profile specifies whether case mapping is The case mapping rule of a profile specifies whether case mapping is
performed (instead of case preservation) on uppercase and titlecase performed (instead of case preservation) on uppercase and titlecase
characters, and how the mapping is done (e.g., mapping uppercase and characters, and how the mapping is done (e.g., mapping uppercase and
titlecase characters to their lowercase equivalents). titlecase characters to their lowercase equivalents).
If case preservation is not desired, it is RECOMMENDED to use Unicode If case mapping is desired (instead of case preservation), it is
Default Case Folding as defined in Chapter 3 of the Unicode Standard RECOMMENDED to use Unicode Default Case Folding as defined in Chapter
[UNICODE]. 3 of the Unicode Standard [UNICODE].
Another option is to use the "local case mapping" method specified in Informational Note: Unicode Default Case Folding is not designed
[I-D.ietf-precis-mappings]. Note: because that method applies normal to handle various localization issues (such as so-called "dotless
case mapping to Unicode characters that do not have special rules for i" in several Turkic languages). The PRECIS mappings document
locale-dependent or context-dependent mapping, if case mapping is [I-D.ietf-precis-mappings] describes these issues in greater
desired then a profile needs to specify either the "local case detail and defines a "local case mapping" method that handles some
mapping" method from [I-D.ietf-precis-mappings] or another method locale-dependent and context-dependent mappings.
such as Unicode Default Case Folding.
In order to maximize entropy and minimize the potential for false In order to maximize entropy and minimize the potential for false
positives, it is NOT RECOMMENDED for application protocols to map positives, it is NOT RECOMMENDED for application protocols to map
uppercase and titlecase code points to their lowercase equivalents uppercase and titlecase code points to their lowercase equivalents
when strings conforming to the FreeformClass, or a profile thereof, when strings conforming to the FreeformClass, or a profile thereof,
are used in passwords; instead, it is RECOMMENDED to preserve the are used in passwords; instead, it is RECOMMENDED to preserve the
case of all code points contained in such strings and then perform case of all code points contained in such strings and then perform
case-sensitive comparison. See also the related discussion in case-sensitive comparison. See also the related discussion in
[I-D.ietf-precis-saslprepbis]. [I-D.ietf-precis-saslprepbis].
skipping to change at page 14, line 4 skipping to change at page 14, line 4
are more flexible than any profiles of the IdentifierClass. In are more flexible than any profiles of the IdentifierClass. In
addition, as explained in the previous section, application protocols addition, as explained in the previous section, application protocols
can also define application-layer constructs containing spaces. can also define application-layer constructs containing spaces.
5. Order of Operations 5. Order of Operations
To ensure proper comparison, the following order of operations is To ensure proper comparison, the following order of operations is
REQUIRED: REQUIRED:
1. Width mapping 1. Width mapping
2. Optionally, additional mappings such as those as specified in 2. Optionally, additional mappings such as mapping of delimiters
[I-D.ietf-precis-mappings]: (e.g., characters such as '@', ':', '/', '+', and '-') and
special handling of certain characters or classes of characters
1. Delimiter mapping (e.g., mapping of non-ASCII spaces to ASCII space or mapping of
control characters to nothing); the PRECIS mappings document
2. Special mapping [I-D.ietf-precis-mappings] describes such mappings in more detail
3. Case mapping as described under Section 4.1.3 of this document 3. Case mapping as described under Section 4.1.3 of this document
(typically either the "local case mapping" method from
[I-D.ietf-precis-mappings] or Unicode Default Case Folding)
4. Normalization 4. Normalization
5. Behavioral rules for determining whether a code point is valid, 5. Behavioral rules for determining whether a code point is valid,
allowed under a contextual rule, disallowed, or unassigned allowed under a contextual rule, disallowed, or unassigned
As already described, the width mapping, additional mapping, case As already described, the width mapping, additional mappings, case
mapping, and normalization operations are specified for each profile, mapping, and normalization operations are specified for each profile,
whereas the behavioral rules are specified for each string class. whereas the behavioral rules are specified for each string class.
Some of the logic behind this order is provided under Section 4.1.1 Some of the logic behind this order is provided under Section 4.1.1
and in [I-D.ietf-precis-mappings]. (see also the PRECIS mappings document [I-D.ietf-precis-mappings]).
6. Code Point Properties 6. Code Point Properties
In order to implement the string classes described above, this In order to implement the string classes described above, this
document does the following: document does the following:
1. Reviews and classifies the collections of code points in the 1. Reviews and classifies the collections of code points in the
Unicode character set by examining various code point properties. Unicode character set by examining various code point properties.
2. Defines an algorithm for determining a derived property value, 2. Defines an algorithm for determining a derived property value,
skipping to change at page 16, line 19 skipping to change at page 16, line 19
1. Characters are placed in one or more character categories either 1. Characters are placed in one or more character categories either
(1) based on core properties defined by the Unicode Standard or (1) based on core properties defined by the Unicode Standard or
(2) by treating the code point as an exception and addressing the (2) by treating the code point as an exception and addressing the
code point based on its code point value. These categories are code point based on its code point value. These categories are
not mutually exclusive. not mutually exclusive.
2. Set operations are used with these categories to determine the 2. Set operations are used with these categories to determine the
values for a property specific to a given string class. These values for a property specific to a given string class. These
operations are specified under Section 8. operations are specified under Section 8.
(Note: Unicode property names and property value names might have Informational Note: Unicode property names and property value
short abbreviations, such as "gc" for the General_Category property names might have short abbreviations, such as "gc" for the
and "Ll" for the Lowercase_Letter property value of the gc property.) General_Category property and "Ll" for the Lowercase_Letter
property value of the gc property.
In the following specification of character categories, the operation In the following specification of character categories, the operation
that returns the value of a particular Unicode character property for that returns the value of a particular Unicode character property for
a code point is designated by using the formal name of that property a code point is designated by using the formal name of that property
(from the Unicode PropertyAliases.txt [1]) followed by '(cp)' for (from the Unicode PropertyAliases.txt [1]) followed by '(cp)' for
"code point". For example, the value of the General_Category "code point". For example, the value of the General_Category
property for a code point is indicated by General_Category(cp). property for a code point is indicated by General_Category(cp).
The first ten categories (A-J) shown below were previously defined The first ten categories (A-J) shown below were previously defined
for IDNA2008 and are copied directly from [RFC5892]. Some of these for IDNA2008 and are copied directly from [RFC5892]. Some of these
skipping to change at page 22, line 27 skipping to change at page 22, line 35
o CONTEXTO o CONTEXTO
o DISALLOWED o DISALLOWED
o ID_DIS o ID_DIS
o FREE_DIS o FREE_DIS
o UNASSIGNED o UNASSIGNED
Note: The value of the derived property calculated can depend on the Informational Note: The value of the derived property calculated
string class; for example, if an identifier used in an application can depend on the string class; for example, if an identifier used
protocol is defined as profiling the PRECIS IdentifierClass then a in an application protocol is defined as profiling the PRECIS
space character such as U+0020 would be assigned to ID_DIS, whereas IdentifierClass then a space character such as U+0020 would be
if an identifier is defined as profiling the PRECIS FreeformClass assigned to ID_DIS, whereas if an identifier is defined as
then the character would be assigned to FREE_PVAL. For the sake of profiling the PRECIS FreeformClass then the character would be
brevity, the designation "FREE_PVAL" is used in the code point assigned to FREE_PVAL. For the sake of brevity, the designation
tables, instead of the longer designation "ID_DIS or FREE_PVAL". In "FREE_PVAL" is used in the code point tables, instead of the
practice, the derived properties ID_PVAL and FREE_DIS are not used in longer designation "ID_DIS or FREE_PVAL". In practice, the
this specification, since every ID_PVAL code point is PVALID and derived properties ID_PVAL and FREE_DIS are not used in this
every FREE_DIS code point is DISALLOWED. specification, since every ID_PVAL code point is PVALID and every
FREE_DIS code point is DISALLOWED.
The algorithm to calculate the value of the derived property is as The algorithm to calculate the value of the derived property is as
follows: follows:
If .cp. .in. Exceptions Then Exceptions(cp); If .cp. .in. Exceptions Then Exceptions(cp);
Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp); Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
Else If .cp. .in. Unassigned Then UNASSIGNED; Else If .cp. .in. Unassigned Then UNASSIGNED;
Else If .cp. .in. ASCII7 Then PVALID; Else If .cp. .in. ASCII7 Then PVALID;
Else If .cp. .in. JoinControl Then CONTEXTJ; Else If .cp. .in. JoinControl Then CONTEXTJ;
Else If .cp. .in. OldHangulJamo Then DISALLOWED; Else If .cp. .in. OldHangulJamo Then DISALLOWED;
skipping to change at page 25, line 45 skipping to change at page 25, line 45
o Is the problem being addressed by this profile well-defined? o Is the problem being addressed by this profile well-defined?
o Does the specification define what kinds of applications are o Does the specification define what kinds of applications are
involved and the protocol elements to which this profile applies? involved and the protocol elements to which this profile applies?
o Would an existing PRECIS string class or profile solve the o Would an existing PRECIS string class or profile solve the
problem? problem?
o Is the profile clearly defined? o Is the profile clearly defined?
o Does the profile reduce the degree to which human users could be
surprised by application behavior (the "principle of least user
surprise")?
o Is the profile based on an appropriate dividing line between user o Is the profile based on an appropriate dividing line between user
interface (culture, context, intent, locale, device limitations, interface (culture, context, intent, locale, device limitations,
etc.) and the use of conformant strings in protocol elements? etc.) and the use of conformant strings in protocol elements?
o Are the width mapping, case mapping, additional mapping, o Are the width mapping, case mapping, additional mappings,
normalization, exclusion, and directionality rules appropriate for normalization, exclusion, and directionality rules appropriate for
the intended use? the intended use?
o Does the profile explain which entities enforce the rules, and o Does the profile explain which entities enforce the rules, and
when such enforcement occurs during protocol operations? when such enforcement occurs during protocol operations?
o Does the profile reduce the degree to which human users could be o Does the profile reduce the degree to which human users could be
surprised or confused by application behavior (the "principle of surprised or confused by application behavior (the "principle of
least user surprise")? least user surprise")?
skipping to change at page 30, line 42 skipping to change at page 30, line 35
The PRECIS framework, which is defined in terms of the latest version The PRECIS framework, which is defined in terms of the latest version
of Unicode as of the time of this writing (6.3), treats the character of Unicode as of the time of this writing (6.3), treats the character
U+19DA NEW TAI LUE THAM as DISALLOWED. Implementers need to be aware U+19DA NEW TAI LUE THAM as DISALLOWED. Implementers need to be aware
that this treatment is different from IDNA2008 (originally defined in that this treatment is different from IDNA2008 (originally defined in
terms of Unicode 5.2), which treats U+19DA as PVALID. terms of Unicode 5.2), which treats U+19DA as PVALID.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-precis-mappings]
Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS
classes", draft-ietf-precis-mappings-06 (work in
progress), January 2014.
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[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.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[UNICODE] The Unicode Consortium, "The Unicode Standard", 2013, [UNICODE] The Unicode Consortium, "The Unicode Standard", 2013,
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-precis-mappings]
Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS
classes", draft-ietf-precis-mappings-07 (work in
progress), February 2014.
[I-D.ietf-precis-nickname] [I-D.ietf-precis-nickname]
Saint-Andre, P., "Preparation and Comparison of Saint-Andre, P., "Preparation and Comparison of
Nicknames", draft-ietf-precis-nickname-08 (work in Nicknames", draft-ietf-precis-nickname-09 (work in
progress), December 2013. progress), January 2014.
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Username and Password Saint-Andre, P. and A. Melnikov, "Username and Password
Preparation Algorithms", draft-ietf-precis-saslprepbis-06 Preparation Algorithms", draft-ietf-precis-saslprepbis-06
(work in progress), December 2013. (work in progress), December 2013.
[I-D.ietf-xmpp-6122bis] [I-D.ietf-xmpp-6122bis]
Saint-Andre, P., "Extensible Messaging and Presence Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", draft-ietf-xmpp- Protocol (XMPP): Address Format", draft-ietf-xmpp-
6122bis-10 (work in progress), January 2014. 6122bis-11 (work in progress), February 2014.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000. 2865, June 2000.
[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,
skipping to change at page 64, line 20 skipping to change at page 64, line 20
Hoehrmann, Paul Hoffman, Jeffrey Hutzelman, Simon Josefsson, John Hoehrmann, Paul Hoffman, Jeffrey Hutzelman, Simon Josefsson, John
Klensin, Alexey Melnikov, Takahiro Nemoto, Yoav Nir, Mike Parker, Klensin, Alexey Melnikov, Takahiro Nemoto, Yoav Nir, Mike Parker,
Pete Resnick, Andrew Sullivan, Dave Thaler, Yoshiro Yoneya, and Pete Resnick, Andrew Sullivan, Dave Thaler, Yoshiro Yoneya, and
Florian Zeitz. Florian Zeitz.
Some algorithms and textual descriptions have been borrowed from Some algorithms and textual descriptions have been borrowed from
[RFC5892]. Some text regarding security has been borrowed from [RFC5892]. Some text regarding security has been borrowed from
[RFC5890] and [I-D.ietf-xmpp-6122bis]. [RFC5890] and [I-D.ietf-xmpp-6122bis].
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
supporting his work on earlier versions of this document while he was employing him during his work on earlier versions of this document.
employed there.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
&yet &yet
Email: ietf@stpeter.im Email: ietf@stpeter.im
Marc Blanchet Marc Blanchet
Viagenie Viagenie
 End of changes. 25 change blocks. 
67 lines changed or deleted 61 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/