draft-ietf-precis-framework-16.txt   draft-ietf-precis-framework-17.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: October 23, 2014 April 21, 2014 Expires: November 28, 2014 May 27, 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-16 draft-ietf-precis-framework-17
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 October 23, 2014. This Internet-Draft will expire on November 28, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. String Classes . . . . . . . . . . . . . . . . . . . . . . . 5 3. String Classes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. IdentifierClass . . . . . . . . . . . . . . . . . . . . . 7 3.2. IdentifierClass . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Contextual Rule Required . . . . . . . . . . . . . . 8
3.2.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 8
3.2.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . 9
3.3. FreeformClass . . . . . . . . . . . . . . . . . . . . . . 9 3.3. FreeformClass . . . . . . . . . . . . . . . . . . . . . . 9
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Contextual Rule Required . . . . . . . . . . . . . . 10
3.3.3. Disallowed . . . . . . . . . . . . . . . . . . . . . 10
3.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 10
3.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 10
4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Width Mapping . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Additional Mappings . . . . . . . . . . . . . . . . . 12
4.1.3. Case Mapping . . . . . . . . . . . . . . . . . . . . 12
4.1.4. Normalization . . . . . . . . . . . . . . . . . . . . 12
4.1.5. Directionality . . . . . . . . . . . . . . . . . . . 12
4.1.6. Exclusions . . . . . . . . . . . . . . . . . . . . . 13
4.2. Building Application-Layer Constructs . . . . . . . . . . 13 4.2. Building Application-Layer Constructs . . . . . . . . . . 13
4.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 13 4.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 14
5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 14 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 14
6. Code Point Properties . . . . . . . . . . . . . . . . . . . . 15 6. Code Point Properties . . . . . . . . . . . . . . . . . . . . 15
7. Category Definitions Used to Calculate Derived Property . . . 16 7. Category Definitions Used to Calculate Derived Property . . . 17
7.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 17 7.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 17
7.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 18
7.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 18 7.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 18
7.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 18 7.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 18
7.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 18 7.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 18
7.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 19 7.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 20
7.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 20 7.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 21
7.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 20 7.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 21
7.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 20 7.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 21
7.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 21 7.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 22
7.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 21 7.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 22
7.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 21 7.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 22
7.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 21 7.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 22
7.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 22 7.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 23
7.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 22 7.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 23
7.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 22 7.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 23
7.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 22 7.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 23
8. Calculation of the Derived Property . . . . . . . . . . . . . 22 8. Calculation of the Derived Property . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. PRECIS Derived Property Value Registry . . . . . . . . . 24 9.1. PRECIS Derived Property Value Registry . . . . . . . . . 25
9.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 24 9.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 25
9.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 25 9.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10.1. General Issues . . . . . . . . . . . . . . . . . . . . . 27
10.1. General Issues . . . . . . . . . . . . . . . . . . . . . 26 10.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 28
10.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 27 10.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 28
10.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 27 10.4. Local Character Set Issues . . . . . . . . . . . . . . . 29
10.4. Local Character Set Issues . . . . . . . . . . . . . . . 27 10.5. Visually Similar Characters . . . . . . . . . . . . . . 29
10.5. Visually Similar Characters . . . . . . . . . . . . . . 28 10.6. Security of Passwords . . . . . . . . . . . . . . . . . 31
10.6. Security of Passwords . . . . . . . . . . . . . . . . . 30 11. Interoperability Considerations . . . . . . . . . . . . . . . 32
11. Interoperability Considerations . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Codepoint Table . . . . . . . . . . . . . . . . . . 35
Appendix A. Codepoint Table . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 66
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
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
basis for preparing and comparing protocol strings that contain basis for preparing and comparing protocol strings that contain
Unicode characters [UNICODE] outside the ASCII range [RFC20]. The Unicode characters [Unicode6.3] outside the ASCII range [RFC20]. The
Stringprep framework was developed during work on the original Stringprep framework was developed during work on the original
technology for internationalized domain names (IDNs), here called technology for internationalized domain names (IDNs), here called
"IDNA2003" [RFC3490], and Nameprep [RFC3491] was the Stringprep "IDNA2003" [RFC3490], and Nameprep [RFC3491] was the Stringprep
profile for IDNs. At the time, Stringprep was designed as a general profile for IDNs. At the time, Stringprep was designed as a general
framework so that other application protocols could define their own framework so that other application protocols could define their own
Stringprep profiles for the preparation and comparison of strings and Stringprep profiles for the preparation and comparison of strings and
identifiers. Indeed, a number of application protocols defined such identifiers. Indeed, a number of application protocols defined such
profiles. profiles.
After the publication of [RFC3454] in 2002, several significant After the publication of [RFC3454] in 2002, several significant
skipping to change at page 5, line 35 skipping to change at page 5, line 49
The character categories and calculation rules defined under The character categories and calculation rules defined under
Section 7 and Section 8 are normative and apply to all Unicode code Section 7 and Section 8 are normative and apply to all Unicode code
points. The code point table provided under Appendix A is non- points. The code point table provided under Appendix A is non-
normative and merely shows, for illustrative purposes, the normative and merely shows, for illustrative purposes, the
consequences of the character categories and calculation rules, as consequences of the character categories and calculation rules, as
well as the resulting property values. well as the resulting property values.
2. Terminology 2. Terminology
Many important terms used in this document are defined in [RFC5890], Many important terms used in this document are defined in [RFC5890],
[RFC6365], [RFC6885], and [UNICODE]. The terms "left-to-right" (LTR) [RFC6365], [RFC6885], and [Unicode6.3]. The terms "left-to-right"
and "right-to-left" (RTL) are defined in Unicode Standard Annex #9 (LTR) and "right-to-left" (RTL) are defined in Unicode Standard Annex
[UAX9]. #9 [UAX9].
As of the date of writing, the version of Unicode published by the As of the date of writing, the version of Unicode published by the
Unicode Consortium is 6.3; however, PRECIS is not tied to a specific Unicode Consortium is 6.3 [Unicode6.3]; however, PRECIS is not tied
version of Unicode. to a specific version of Unicode. The latest version of Unicode is
always available [UnicodeCurrent].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. String Classes 3. String Classes
3.1. Overview 3.1. Overview
Starting in 2010, various "customers" of Stringprep began to discuss Starting in 2010, various "customers" of Stringprep began to discuss
the need to define a post-Stringprep approach to the preparation and the need to define a post-Stringprep approach to the preparation and
comparison of internationalized strings other than IDNs. This comparison of internationalized strings other than IDNs. This
community analyzed the existing Stringprep profiles and also weighed community analyzed the existing Stringprep profiles and also weighed
the costs and benefits of defining a relatively small set of Unicode the costs and benefits of defining a relatively small set of Unicode
characters that would minimize the potential for user confusion characters that would minimize the potential for user confusion
caused by visually similar characters (and thus be relatively "safe") caused by visually similar characters (and thus be relatively "safe")
vs. defining a much larger set of Unicode characters that would vs. defining a much larger set of Unicode characters that would
skipping to change at page 6, line 34 skipping to change at page 6, line 47
been prioritized over expressiveness for this class. been prioritized over expressiveness for this class.
FreeformClass: a sequence of letters, numbers, symbols, spaces, and FreeformClass: a sequence of letters, numbers, symbols, spaces, and
other characters that is used for free-form strings, including other characters that is used for free-form strings, including
passwords as well as display elements such as human-friendly passwords as well as display elements such as human-friendly
nicknames in chatrooms; the intent is that this class will allow nicknames in chatrooms; the intent is that this class will allow
nearly any Unicode character, with the result that expressiveness nearly any Unicode character, with the result that expressiveness
has been prioritized over safety for this class (e.g., protocol has been prioritized over safety for this class (e.g., protocol
designers, application developers, service providers, and end designers, application developers, service providers, and end
users might not understand or be able to enter all of the users might not understand or be able to enter all of the
characters that can be included in the FreeformClass). characters that can be included in the FreeformClass - see
Section 10.3 for details).
Future specifications might define additional PRECIS string classes, Future specifications might define additional PRECIS string classes,
such as a class that falls somewhere between the IdentifierClass and such as a class that falls somewhere between the IdentifierClass and
the FreeformClass. At this time, it is not clear how useful such a the FreeformClass. At this time, it is not clear how useful such a
class would be. In any case, because application developers are able class would be. In any case, because application developers are able
to define profiles of PRECIS string classes, a protocol needing a to define profiles of PRECIS string classes, a protocol needing a
construct between the IdentiferClass and the FreeformClass could construct between the IdentiferClass and the FreeformClass could
define a restricted profile of the FreeformClass if needed. define a restricted profile of the FreeformClass if needed.
The following subsections discuss the IdentifierClass and The following subsections discuss the IdentifierClass and
skipping to change at page 9, line 19 skipping to change at page 9, line 25
(such as case mapping); instead, such issues are handled at the level (such as case mapping); instead, such issues are handled at the level
of profiles. Examples for two profiles of the IdentifierClass can be of profiles. Examples for two profiles of the IdentifierClass can be
found in [I-D.ietf-precis-saslprepbis] (the UsernameIdentifierClass found in [I-D.ietf-precis-saslprepbis] (the UsernameIdentifierClass
profile) and in [I-D.ietf-xmpp-6122bis] (the JIDlocalIdentifierClass profile) and in [I-D.ietf-xmpp-6122bis] (the JIDlocalIdentifierClass
profile). profile).
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.
Security Warning: As mentioned, the FreeformClass prioritizes
expressiveness over safety; Section 10.3 describes some of the
security hazards involved with using or profiling the
FreeformClass.
Security Warning: Consult Section 10.6 for relevant security Security Warning: Consult Section 10.6 for relevant security
considerations when strings conforming to the FreeformClass, or a considerations when strings conforming to the FreeformClass, or a
profile thereof, are 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.
skipping to change at page 12, line 7 skipping to change at page 12, line 21
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 mapping is desired (instead of case preservation), it is If case mapping is desired (instead of case preservation), it is
RECOMMENDED to use Unicode Default Case Folding as defined in Chapter RECOMMENDED to use Unicode Default Case Folding as defined in Chapter
3 of the Unicode Standard [UNICODE]. 3 of the Unicode Standard [Unicode6.3].
Note: Unicode Default Case Folding is not designed to handle Note: Unicode Default Case Folding is not designed to handle
various localization issues (such as so-called "dotless i" in various localization issues (such as so-called "dotless i" in
several Turkic languages). The PRECIS mappings document several Turkic languages). The PRECIS mappings document
[I-D.ietf-precis-mappings] describes these issues in greater [I-D.ietf-precis-mappings] describes these issues in greater
detail and defines a "local case mapping" method that handles some detail and defines a "local case mapping" method that handles some
locale-dependent and context-dependent mappings. locale-dependent and context-dependent mappings.
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
skipping to change at page 12, line 36 skipping to change at page 12, line 50
The normalization rule of a profile specifies which Unicode The normalization rule of a profile specifies which Unicode
normalization form (D, KD, C, or KC) is to be applied (see Unicode normalization form (D, KD, C, or KC) is to be applied (see Unicode
Standard Annex #15 [UAX15] for background information). Standard Annex #15 [UAX15] for background information).
In accordance with [RFC5198], normalization form C (NFC) is In accordance with [RFC5198], normalization form C (NFC) is
RECOMMENDED. RECOMMENDED.
4.1.5. Directionality 4.1.5. Directionality
The directionality rule of a profile specifies which strings are to The directionality rule of a profile specifies how to treat strings
be considered left-to-right (LTR) and right-to-left (RTL), and the containing left-to-right (LTR) and right-to-left (RTL) characters
allowable sequences of characters in LTR and RTL strings (see Unicode (see Unicode Standard Annex #9 [UAX9]). A profile usually specifies
Standard Annex #9 [UAX9]). Possible rules include, but are not a directionality rule that restricts strings to be entirely LTR
limited to, (a) considering any string that contains a right-to-left strings or entirely RTL strings and defines the allowable sequences
code point to be a right-to-left string, or (b) applying the "Bidi of characters in LTR and RTL strings. Possible rules include, but
Rule" from [RFC5893]. are not limited to, (a) considering any string that contains a right-
to-left code point to be a right-to-left string, or (b) applying the
"Bidi Rule" from [RFC5893].
Mixed-direction strings are not directly supported by the PRECIS Mixed-direction strings are not directly supported by the PRECIS
framework itself, since there is currently no widely accepted and framework itself, since there is currently no widely accepted and
implemented solution for the processing and safe display of mixed- implemented solution for the safe display of mixed-direction strings.
direction strings. An application protocol that uses the PRECIS An application protocol that uses the PRECIS framework (or an
framework (or an extension to the framework) could define methods for extension to the framework) could define better ways to present
handling mixed-direction strings; however, such methods are outside mixed-direction strings; however, that work is outside the scope of
the scope of the framework. this framework and would likely require a great deal of careful
research into the problems of displaying bidirectional text.
4.1.6. Exclusions 4.1.6. Exclusions
The exclusions rule of a profile specifies whether the profile The exclusions rule of a profile specifies whether the profile
excludes additional code points or character categories above and excludes additional code points or character categories above and
beyond those excluded by the string class being profiled. That is, a beyond those excluded by the string class being profiled. That is, a
profile MAY do either of the following: profile MAY do either of the following:
1. Exclude specific code points that are allowed by the relevant 1. Exclude specific code points that are allowed by the relevant
string class. string class.
skipping to change at page 16, line 30 skipping to change at page 16, line 44
UNASSIGNED Those code points that are not designated (i.e. are UNASSIGNED Those code points that are not designated (i.e. are
unassigned) in the Unicode Standard. unassigned) in the Unicode Standard.
The mechanisms described here allow determination of the value of the The mechanisms described here allow determination of the value of the
property for future versions of Unicode (including characters added property for future versions of Unicode (including characters added
after Unicode 5.2 or 6.3 depending on the category, since some after Unicode 5.2 or 6.3 depending on the category, since some
categories in this document are reused from IDNA2008 and therefore categories in this document are reused from IDNA2008 and therefore
were defined at the time of Unicode 5.2). Changes in Unicode were defined at the time of Unicode 5.2). Changes in Unicode
properties that do not affect the outcome of this process therefore properties that do not affect the outcome of this process therefore
do not affect this framework. For example, a character can have its do not affect this framework. For example, a character can have its
Unicode General_Category value [UNICODE] change from So to Sm, or Unicode General_Category value (see Chapter 4 of the Unicode Standard
from Lo to Ll, without affecting the algorithm results. Moreover, [Unicode6.3]) change from So to Sm, or from Lo to Ll, without
even if such changes were to result, the BackwardCompatible list affecting the algorithm results. Moreover, even if such changes were
(Section 7.7) can be adjusted to ensure the stability of the results. to result, the BackwardCompatible list (Section 7.7) can be adjusted
to ensure the stability of the results.
7. Category Definitions Used to Calculate Derived Property 7. Category Definitions Used to Calculate Derived Property
The derived property obtains its value based on a two-step procedure: The derived property obtains its value based on a two-step procedure:
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.
skipping to change at page 17, line 15 skipping to change at page 17, line 32
gc property. 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] to ease the
categories are reused in PRECIS and some of them are not; however, understanding of how PRECIS handles various characters. Some of
the lettering of categories is retained to prevent overlap and to these categories are reused in PRECIS and some of them are not;
ease implementation of both IDNA2008 and PRECIS in a single software however, the lettering of categories is retained to prevent overlap
application. The next eight categories (K-R) are specific to PRECIS. and to ease implementation of both IDNA2008 and PRECIS in a single
software application. The next eight categories (K-R) are specific
to PRECIS.
7.1. LetterDigits (A) 7.1. LetterDigits (A)
Note: This category is defined in [RFC5892] and copied here for use Note: This category is defined in [RFC5892] and copied here for use
in PRECIS. in PRECIS.
################## BEGIN DEFINITION FROM RFC 5892 ##################
A: General_Category(cp) is in {Ll, Lu, Lm, Lo, Mn, Mc, Nd} A: General_Category(cp) is in {Ll, Lu, Lm, Lo, Mn, Mc, Nd}
These rules identify characters commonly used in mnemonics and often These rules identify characters commonly used in mnemonics and often
informally described as "language characters". informally described as "language characters".
For more information, see Chapter 4 of the Unicode Standard For more information, see Chapter 4 of the Unicode Standard
[UNICODE]. [Unicode6.3].
The categories used in this rule are: The categories used in this rule are:
o Ll - Lowercase_Letter o Ll - Lowercase_Letter
o Lu - Uppercase_Letter o Lu - Uppercase_Letter
o Lm - Modifier_Letter o Lm - Modifier_Letter
o Lo - Other_Letter o Lo - Other_Letter
o Mn - Nonspacing_Mark o Mn - Nonspacing_Mark
o Mc - Spacing_Mark o Mc - Spacing_Mark
o Nd - Decimal_Number o Nd - Decimal_Number
################### END DEFINITION FROM RFC 5892 ###################
7.2. Unstable (B) 7.2. Unstable (B)
Note: This category is defined in [RFC5892] but not used in PRECIS. Note: This category is defined in [RFC5892] but not used in PRECIS.
7.3. IgnorableProperties (C) 7.3. IgnorableProperties (C)
Note: This category is defined in [RFC5892] but not used in PRECIS. Note: This category is defined in [RFC5892] but not used in PRECIS.
See the "PrecisIgnorableProperties (M)" category below for a more See the "PrecisIgnorableProperties (M)" category below for a more
inclusive category used in PRECIS identifiers. inclusive category used in PRECIS identifiers.
skipping to change at page 18, line 30 skipping to change at page 18, line 51
Note: This category is defined in [RFC5892] but not used in PRECIS. Note: This category is defined in [RFC5892] but not used in PRECIS.
See the "ASCII7 (K)" category below for a more inclusive category See the "ASCII7 (K)" category below for a more inclusive category
used in PRECIS identifiers. used in PRECIS identifiers.
7.6. Exceptions (F) 7.6. Exceptions (F)
Note: This category is defined in [RFC5892] and used in PRECIS to Note: This category is defined in [RFC5892] and used in PRECIS to
ensure consistent treatment of the relevant code points. ensure consistent treatment of the relevant code points.
################## BEGIN DEFINITION FROM RFC 5892 ##################
F: cp is in {00B7, 00DF, 0375, 03C2, 05F3, 05F4, 0640, 0660, F: cp is in {00B7, 00DF, 0375, 03C2, 05F3, 05F4, 0640, 0660,
0661, 0662, 0663, 0664, 0665, 0666, 0667, 0668, 0661, 0662, 0663, 0664, 0665, 0666, 0667, 0668,
0669, 06F0, 06F1, 06F2, 06F3, 06F4, 06F5, 06F6, 0669, 06F0, 06F1, 06F2, 06F3, 06F4, 06F5, 06F6,
06F7, 06F8, 06F9, 06FD, 06FE, 07FA, 0F0B, 3007, 06F7, 06F8, 06F9, 06FD, 06FE, 07FA, 0F0B, 3007,
302E, 302F, 3031, 3032, 3033, 3034, 3035, 303B, 302E, 302F, 3031, 3032, 3033, 3034, 3035, 303B,
30FB} 30FB}
This category explicitly lists code points for which the category This category explicitly lists code points for which the category
cannot be assigned using only the core property values that exist in cannot be assigned using only the core property values that exist in
the Unicode Standard. The values are according to the table below: the Unicode Standard. The values are according to the table below:
skipping to change at page 19, line 46 skipping to change at page 20, line 21
302E; DISALLOWED # HANGUL SINGLE DOT TONE MARK 302E; DISALLOWED # HANGUL SINGLE DOT TONE MARK
302F; DISALLOWED # HANGUL DOUBLE DOT TONE MARK 302F; DISALLOWED # HANGUL DOUBLE DOT TONE MARK
3031; DISALLOWED # VERTICAL KANA REPEAT MARK 3031; DISALLOWED # VERTICAL KANA REPEAT MARK
3032; DISALLOWED # VERTICAL KANA REPEAT WITH VOICED SOUND MARK 3032; DISALLOWED # VERTICAL KANA REPEAT WITH VOICED SOUND MARK
3033; DISALLOWED # VERTICAL KANA REPEAT MARK UPPER HALF 3033; DISALLOWED # VERTICAL KANA REPEAT MARK UPPER HALF
3034; DISALLOWED # VERTICAL KANA REPEAT WITH VOICED SOUND MARK 3034; DISALLOWED # VERTICAL KANA REPEAT WITH VOICED SOUND MARK
UPPER HA UPPER HA
3035; DISALLOWED # VERTICAL KANA REPEAT MARK LOWER HALF 3035; DISALLOWED # VERTICAL KANA REPEAT MARK LOWER HALF
303B; DISALLOWED # VERTICAL IDEOGRAPHIC ITERATION MARK 303B; DISALLOWED # VERTICAL IDEOGRAPHIC ITERATION MARK
################### END DEFINITION FROM RFC 5892 ###################
7.7. BackwardCompatible (G) 7.7. BackwardCompatible (G)
Note: This category is defined in [RFC5892] and copied here for use Note: This category is defined in [RFC5892] and copied here for use
in PRECIS. Because of how the PRECIS string classes are defined, in PRECIS. Because of how the PRECIS string classes are defined,
only changes that would result in code points being added to or only changes that would result in code points being added to or
removed from the LetterDigits ("A") category would result in removed from the LetterDigits ("A") category would result in
backward-incompatible modifications to code point assignments. backward-incompatible modifications to code point assignments.
Therefore, management of this category is handled via the processes Therefore, management of this category is handled via the processes
specified in [RFC5892]. specified in [RFC5892]. At the time of this writing (and also at the
time that RFC 5892 was published), this category consisted of the
empty set; however, that is subject to change as described in RFC
5892.
################## BEGIN DEFINITION FROM RFC 5892 ##################
G: cp is in {} G: cp is in {}
This category includes the code points for which property values in This category includes the code points for which property values in
versions of Unicode after 5.2 have changed in such a way that the versions of Unicode after 5.2 have changed in such a way that the
derived property value would no longer be PVALID or DISALLOWED. If derived property value would no longer be PVALID or DISALLOWED. If
changes are made to future versions of Unicode so that code points changes are made to future versions of Unicode so that code points
might change property value from PVALID or DISALLOWED, then this might change property value from PVALID or DISALLOWED, then this
table can be updated and keep special exception values so that the table can be updated and keep special exception values so that the
property values for code points stay stable. property values for code points stay stable.
################### END DEFINITION FROM RFC 5892 ###################
7.8. JoinControl (H) 7.8. JoinControl (H)
Note: This category is defined in [RFC5892] and copied here for use Note: This category is defined in [RFC5892] and copied here for use
in PRECIS. in PRECIS.
################## BEGIN DEFINITION FROM RFC 5892 ##################
H: Join_Control(cp) = True H: Join_Control(cp) = True
This category consists of Join Control characters (i.e., they are not This category consists of Join Control characters (i.e., they are not
in LetterDigits (Section 7.1) but are still required in strings under in LetterDigits (Section 7.1) but are still required in strings under
some circumstances). some circumstances).
################### END DEFINITION FROM RFC 5892 ###################
7.9. OldHangulJamo (I) 7.9. OldHangulJamo (I)
Note: This category is defined in [RFC5892] and copied here for use Note: This category is defined in [RFC5892] and copied here for use
in PRECIS. in PRECIS.
################## BEGIN DEFINITION FROM RFC 5892 ##################
I: Hangul_Syllable_Type(cp) is in {L, V, T} I: Hangul_Syllable_Type(cp) is in {L, V, T}
This category consists of all conjoining Hangul Jamo (Leading Jamo, This category consists of all conjoining Hangul Jamo (Leading Jamo,
Vowel Jamo, and Trailing Jamo). Vowel Jamo, and Trailing Jamo).
Elimination of conjoining Hangul Jamos from the set of PVALID Elimination of conjoining Hangul Jamos from the set of PVALID
characters results in restricting the set of Korean PVALID characters characters results in restricting the set of Korean PVALID characters
just to preformed, modern Hangul syllable characters. Old Hangul just to preformed, modern Hangul syllable characters. Old Hangul
syllables, which are spelled with sequences of conjoining Hangul syllables, which are spelled with sequences of conjoining Hangul
Jamos, are not PVALID for string classes. Jamos, are not PVALID for string classes.
################### END DEFINITION FROM RFC 5892 ###################
7.10. Unassigned (J) 7.10. Unassigned (J)
Note: This category is defined in [RFC5892] and copied here for use Note: This category is defined in [RFC5892] and copied here for use
in PRECIS. in PRECIS.
################## BEGIN DEFINITION FROM RFC 5892 ##################
J: General_Category(cp) is in {Cn} and J: General_Category(cp) is in {Cn} and
Noncharacter_Code_Point(cp) = False Noncharacter_Code_Point(cp) = False
This category consists of code points in the Unicode character set This category consists of code points in the Unicode character set
that are not (yet) designated. Implementers might want to keep in that are not (yet) designated. Implementers might want to keep in
mind that the Unicode Standard distinguishes between 'unassigned code mind that the Unicode Standard distinguishes between 'unassigned code
points' and 'unassigned characters'. The unassigned code points are points' and 'unassigned characters'. The unassigned code points are
all but (Cn - Noncharacters), whereas the unassigned characters are all but (Cn - Noncharacters), whereas the unassigned characters are
all but (Cn + Cs). all but (Cn + Cs).
################### END DEFINITION FROM RFC 5892 ###################
7.11. ASCII7 (K) 7.11. ASCII7 (K)
This PRECIS-specific category consists of all printable, non-space This PRECIS-specific category consists of all printable, non-space
characters from the 7-bit ASCII range. By applying this category, characters from the 7-bit ASCII range. By applying this category,
the algorithm specified under Section 8 exempts these characters from the algorithm specified under Section 8 exempts these characters from
other rules that might be applied during PRECIS processing, on the other rules that might be applied during PRECIS processing, on the
assumption that these code points are in such wide use that assumption that these code points are in such wide use that
disallowing them would be counter-productive. disallowing them would be counter-productive.
K: cp is in {0021..007E} K: cp is in {0021..007E}
skipping to change at page 22, line 23 skipping to change at page 23, line 23
This PRECIS-specific category is used to group code points that are This PRECIS-specific category is used to group code points that are
punctuation characters. punctuation characters.
P: General_Category(cp) is in {Pc, Pd, Ps, Pe, Pi, Pf, Po} P: General_Category(cp) is in {Pc, Pd, Ps, Pe, Pi, Pf, Po}
7.17. HasCompat (Q) 7.17. HasCompat (Q)
This PRECIS-specific category is used to group code points that have This PRECIS-specific category is used to group code points that have
compatibility equivalents as explained in Chapter 2 and Chapter 3 of compatibility equivalents as explained in Chapter 2 and Chapter 3 of
the Unicode Standard [UNICODE]. the Unicode Standard [Unicode6.3].
Q: toNFKC(cp) != cp Q: toNFKC(cp) != cp
The toNFKC() operation returns the code point in normalization form The toNFKC() operation returns the code point in normalization form
KC. For more information, see Section 5 of Unicode Standard Annex KC. For more information, see Section 5 of Unicode Standard Annex
#15 [UAX15]. #15 [UAX15].
7.18. OtherLetterDigits (R) 7.18. OtherLetterDigits (R)
This PRECIS-specific category is used to group code points that are This PRECIS-specific category is used to group code points that are
skipping to change at page 24, line 49 skipping to change at page 25, line 49
Base Class: FreeformClass. Base Class: FreeformClass.
Description: A sequence of letters, numbers, symbols, spaces, and Description: A sequence of letters, numbers, symbols, spaces, and
other code points that is used for free-form strings. other code points that is used for free-form strings.
Specification: Section 3.3 of this document. Specification: Section 3.3 of this document.
[Note to RFC Editor: please change "this document" [Note to RFC Editor: please change "this document"
to the RFC number issued for this specification.] to the RFC number issued for this specification.]
Base Class: IdentifierClass. Base Class: IdentifierClass.
Description: A sequence of letters, numbers, and symbols that is Description: A sequence of letters, numbers, and symbols that is
used to identify or address a network entity. used to identify or address a network entity.
Specification: Section 3.3 of this document. Specification: Section 3.2 of this document.
[Note to RFC Editor: please change "this document" [Note to RFC Editor: please change "this document"
to the RFC number issued for this specification.] to the RFC number issued for this specification.]
9.3. PRECIS Profiles Registry 9.3. PRECIS Profiles Registry
IANA is requested to create a registry of profiles that use the IANA is requested to create a registry of profiles that use the
PRECIS string classes. In accordance with [RFC5226], the PRECIS string classes. In accordance with [RFC5226], the
registration policy is "Expert Review". This policy was chosen in registration policy is "Expert Review". This policy was chosen in
order to ease the burden of registration while ensuring that order to ease the burden of registration while ensuring that
"customers" of PRECIS receive appropriate guidance regarding the "customers" of PRECIS receive appropriate guidance regarding the
skipping to change at page 26, line 47 skipping to change at page 27, line 47
least user surprise")? least user surprise")?
o Does the profile introduce any new security concerns such as those o Does the profile introduce any new security concerns such as those
described under Section 10 of this document (e.g., false positives described under Section 10 of this document (e.g., false positives
for authentication or authorization)? for authentication or authorization)?
10. Security Considerations 10. Security Considerations
10.1. General Issues 10.1. General Issues
If input strings that appear "the same" to users are programmatically
considered to be distinct in different systems, or if input strings
that appear distinct to users are programmatically considered to be
"the same" in different systems, then users can be confused. Such
confusion can have security implications, such as the false positives
and false negatieves discussed in [RFC6943]. One starting goal of
work on the PRECIS framework was to limit the number of times that
users are confused (consistent with the "principle of least
astonishment"). Unfortunately, this goal has been difficult to
achieve given the large number of application protocols already in
existence, each with its own conventions regarding allowable
characters (see for example [I-D.saintandre-username-interop] with
regard to various username constructs). Despite these difficulties,
profiles should not be multiplied beyond necessity. In particular,
application protocol designers should think long and hard before
defining a new profile instead of using one that has already been
defined, and if they decide to define a new profile then they should
clearly explain their reasons for doing so.
The security of applications that use this framework can depend in The security of applications that use this framework can depend in
part on the proper preparation and comparison of internationalized part on the proper preparation and comparison of internationalized
strings. For example, such strings can be used to make strings. For example, such strings can be used to make
authentication and authorization decisions, and the security of an authentication and authorization decisions, and the security of an
application could be compromised if an entity providing a given application could be compromised if an entity providing a given
string is connected to the wrong account or online resource based on string is connected to the wrong account or online resource based on
different interpretations of the string. different interpretations of the string.
Specifications of application protocols that use this framework are Specifications of application protocols that use this framework are
encouraged to describe how internationalized strings are used in the strongly encouraged to describe how internationalized strings are
protocol, including the security implications of any false positives used in the protocol, including the security implications of any
and false negatives that might result from various comparison false positives and false negatives that might result from various
operations. For some helpful guidelines, refer to [RFC6943], comparison operations. For some helpful guidelines, refer to
[RFC5890], [UTR36], and [UTS39]. [RFC6943], [RFC5890], [UTR36], and [UTS39].
10.2. Use of the IdentifierClass 10.2. Use of the IdentifierClass
Strings that conform to the IdentifierClass and any profile thereof Strings that conform to the IdentifierClass and any profile thereof
are intended to be relatively safe for use in a broad range of are intended to be relatively safe for use in a broad range of
applications, primarily because they include only letters, digits, applications, primarily because they include only letters, digits,
and "grandfathered" non-space characters from the ASCII range; thus and "grandfathered" non-space characters from the ASCII range; thus
they exclude spaces, characters with compatibility equivalents, and they exclude spaces, characters with compatibility equivalents, and
almost all symbols and punctuation marks. However, because such almost all symbols and punctuation marks. However, because such
strings can still include so-called confusable characters (see strings can still include so-called confusable characters (see
skipping to change at page 29, line 8 skipping to change at page 30, line 25
Considerations [UTR36] and the Unicode Security Mechanisms [UTS39], Considerations [UTR36] and the Unicode Security Mechanisms [UTS39],
it is also true (as noted in [RFC5890]) that "there are no it is also true (as noted in [RFC5890]) that "there are no
comprehensive technical solutions to the problems of confusable comprehensive technical solutions to the problems of confusable
characters". Because it is impossible to map visually similar characters". Because it is impossible to map visually similar
characters without a great deal of context (such as knowing the font characters without a great deal of context (such as knowing the font
families used), the PRECIS framework does nothing to map similar- families used), the PRECIS framework does nothing to map similar-
looking characters together, nor does it prohibit some characters looking characters together, nor does it prohibit some characters
because they look like others. because they look like others.
Nevertheless, specifications for application protocols that use this Nevertheless, specifications for application protocols that use this
framework MUST describe how confusable characters can be abused to framework are strongly encouraged to describe how confusable
compromise the security of systems that use the protocol in question, characters can be abused to compromise the security of systems that
along with any protocol-specific suggestions for overcoming those use the protocol in question, along with any protocol-specific
threats. In particular, software implementations and service suggestions for overcoming those threats. In particular, software
deployments that use PRECIS-based technologies are strongly implementations and service deployments that use PRECIS-based
encouraged to define and implement consistent policies regarding the technologies are strongly encouraged to define and implement
registration, storage, and presentation of visually similar consistent policies regarding the registration, storage, and
characters. The following recommendations are appropriate: presentation of visually similar characters. The following
recommendations are appropriate:
1. An application service SHOULD define a policy that specifies the 1. An application service SHOULD define a policy that specifies the
scripts or blocks of characters that the service will allow to be scripts or blocks of characters that the service will allow to be
registered (e.g., in an account name) or stored (e.g., in a file registered (e.g., in an account name) or stored (e.g., in a file
name). Such a policy SHOULD be informed by the languages and name). Such a policy SHOULD be informed by the languages and
scripts that are used to write registered account names; in scripts that are used to write registered account names; in
particular, to reduce confusion, the service SHOULD forbid particular, to reduce confusion, the service SHOULD forbid
registration or storage of strings that contain characters from registration or storage of strings that contain characters from
more than one script and SHOULD restrict registrations to more than one script and SHOULD restrict registrations to
characters drawn from a very small number of scripts (e.g., characters drawn from a very small number of scripts (e.g.,
skipping to change at page 30, line 39 skipping to change at page 32, line 8
reuse technologies that themselves process passwords (one example of reuse technologies that themselves process passwords (one example of
such a technology is the Simple Authentication and Security Layer such a technology is the Simple Authentication and Security Layer
[RFC4422]). Moreover, passwords are often carried by a sequence of [RFC4422]). Moreover, passwords are often carried by a sequence of
protocols with backend authentication systems or data storage systems protocols with backend authentication systems or data storage systems
such as RADIUS [RFC2865] and LDAP [RFC4510]. Developers of such as RADIUS [RFC2865] and LDAP [RFC4510]. Developers of
application protocols are encouraged to look into reusing these application protocols are encouraged to look into reusing these
profiles instead of defining new ones, so that end-user expectations profiles instead of defining new ones, so that end-user expectations
about passwords are consistent no matter which application protocol about passwords are consistent no matter which application protocol
is used. is used.
In protocols that provide passwords as input to a cryptographic
algorithm such as a hash function, the client will need to perform
proper preparation of the password before applying the algorithm,
since the password is not available to the server in plaintext form.
Further discussion of password handling can be found in Further discussion of password handling can be found in
[I-D.ietf-precis-saslprepbis]. [I-D.ietf-precis-saslprepbis].
11. Interoperability Considerations 11. Interoperability Considerations
Although strings that are consumed in PRECIS-based application Although strings that are consumed in PRECIS-based application
protocols are often encoded using UTF-8 [RFC3629], the exact encoding protocols are often encoded using UTF-8 [RFC3629], the exact encoding
is a matter for the application protocol that uses PRECIS, not for is a matter for the application protocol that uses PRECIS, not for
the PRECIS framework. the PRECIS framework.
skipping to change at page 31, line 29 skipping to change at page 33, line 5
[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, [Unicode6.3]
<http://www.unicode.org/versions/latest/>. The Unicode Consortium, "The Unicode Standard, Version
6.3.0", 2013,
<http://www.unicode.org/versions/Unicode6.3.0/>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-precis-mappings] [I-D.ietf-precis-mappings]
Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS
classes", draft-ietf-precis-mappings-07 (work in classes", draft-ietf-precis-mappings-07 (work in
progress), February 2014. 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
skipping to change at page 32, line 10 skipping to change at page 33, line 32
[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-07 Preparation Algorithms", draft-ietf-precis-saslprepbis-07
(work in progress), March 2014. (work in progress), March 2014.
[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-12 (work in progress), March 2014. 6122bis-12 (work in progress), March 2014.
[I-D.saintandre-username-interop]
Saint-Andre, P., "An Interoperable Subset of Characters
for Internationalized Usernames", draft-saintandre-
username-interop-03 (work in progress), March 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,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
skipping to change at page 33, line 47 skipping to change at page 35, line 28
<http://unicode.org/reports/tr9/>. <http://unicode.org/reports/tr9/>.
[UAX11] The Unicode Consortium, "Unicode Standard Annex #11: East [UAX11] The Unicode Consortium, "Unicode Standard Annex #11: East
Asian Width", September 2012, Asian Width", September 2012,
<http://unicode.org/reports/tr11/>. <http://unicode.org/reports/tr11/>.
[UAX15] The Unicode Consortium, "Unicode Standard Annex #15: [UAX15] The Unicode Consortium, "Unicode Standard Annex #15:
Unicode Normalization Forms", August 2012, Unicode Normalization Forms", August 2012,
<http://unicode.org/reports/tr15/>. <http://unicode.org/reports/tr15/>.
[UnicodeCurrent]
The Unicode Consortium, "The Unicode Standard",
2014-present, <http://www.unicode.org/versions/latest/>.
[UTR36] The Unicode Consortium, "Unicode Technical Report #36: [UTR36] The Unicode Consortium, "Unicode Technical Report #36:
Unicode Security Considerations", July 2012, Unicode Security Considerations", July 2012,
<http://unicode.org/reports/tr36/>. <http://unicode.org/reports/tr36/>.
[UTS39] The Unicode Consortium, "Unicode Technical Standard #39: [UTS39] The Unicode Consortium, "Unicode Technical Standard #39:
Unicode Security Mechanisms", July 2012, Unicode Security Mechanisms", July 2012,
<http://unicode.org/reports/tr39/>. <http://unicode.org/reports/tr39/>.
12.3. URIs 12.3. URIs
skipping to change at page 34, line 34 skipping to change at page 36, line 17
2. The assignment for the code point or range, where the value is 2. The assignment for the code point or range, where the value is
one of PVALID, DISALLOWED, UNASSIGNED, CONTEXTO, CONTEXTJ, or one of PVALID, DISALLOWED, UNASSIGNED, CONTEXTO, CONTEXTJ, or
FREE_PVAL (where the latter includes ID_DIS). FREE_PVAL (where the latter includes ID_DIS).
3. The name or names for the code point or range. 3. The name or names for the code point or range.
This table is non-normative, is included only for illustrative This table is non-normative, is included only for illustrative
purposes, and applies only to Unicode 6.3, not to past or future purposes, and applies only to Unicode 6.3, not to past or future
versions of Unicode. Please note that the strings displayed in the versions of Unicode. Please note that the strings displayed in the
third column are not necessarily the formal name of the code point third column are not necessarily the formal name of the code point
(as defined in [UNICODE]) because the fixed width of the RFC format (as defined in [Unicode6.3]) because the fixed width of the RFC
necessitated truncation of many names. format necessitated truncation of many names.
0000..001F ; DISALLOWED # <control> 0000..001F ; DISALLOWED # <control>
0020 ; FREE_PVAL # SPACE 0020 ; FREE_PVAL # SPACE
0021..007E ; PVALID # EXCLAM MARK..TILDE 0021..007E ; PVALID # EXCLAM MARK..TILDE
007F..009F ; DISALLOWED # <control> 007F..009F ; DISALLOWED # <control>
00A0..00AC ; FREE_PVAL # NO-BREAK SPACE..NOT SIGN 00A0..00AC ; FREE_PVAL # NO-BREAK SPACE..NOT SIGN
00AD ; DISALLOWED # SOFT HYPH 00AD ; DISALLOWED # SOFT HYPH
00AE..00B6 ; FREE_PVAL # REGISTERED SIGN..PILCROW SIGN 00AE..00B6 ; FREE_PVAL # REGISTERED SIGN..PILCROW SIGN
00B7 ; CONTEXTO # MIDDLE DOT 00B7 ; CONTEXTO # MIDDLE DOT
00B8..00BF ; FREE_PVAL # CEDILLA..INV QUEST IND 00B8..00BF ; FREE_PVAL # CEDILLA..INV QUEST IND
skipping to change at page 64, line 42 skipping to change at page 66, line 25
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors would like to acknowledge the comments and contributions The authors would like to acknowledge the comments and contributions
of the following individuals during working group discussion: David of the following individuals during working group discussion: David
Black, Mark Davis, Alan DeKok, Martin Duerst, Patrik Faltstrom, Ted Black, Mark Davis, Alan DeKok, Martin Duerst, Patrik Faltstrom, Ted
Hardie, Joe Hildebrand, Bjoern Hoehrmann, Paul Hoffman, Jeffrey Hardie, Joe Hildebrand, Bjoern Hoehrmann, Paul Hoffman, Jeffrey
Hutzelman, Simon Josefsson, John Klensin, Alexey Melnikov, Takahiro Hutzelman, Simon Josefsson, John Klensin, Alexey Melnikov, Takahiro
Nemoto, Yoav Nir, Mike Parker, Pete Resnick, Andrew Sullivan, Dave Nemoto, Yoav Nir, Mike Parker, Pete Resnick, Andrew Sullivan, Dave
Thaler, Yoshiro Yoneya, and Florian Zeitz. Thaler, Yoshiro Yoneya, and Florian Zeitz.
Charlie Kaufman performed a helpful review on behalf of the Security Charlie Kaufman, Tom Taylor, and Tim Wicinski reviewed the document
Directorate, and Tom Taylor reviewed the document on behalf of the on behalf of the Security Directorate, the General Area Review Team,
General Area Review Team. and the Operations and Management Directorate, respectively.
During IESG review, Alissa Cooper provided comments that led to During IESG review, Alissa Cooper, Stephen Farrell, and Barry Leiba
further improvements. provided comments that led to further improvements.
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], [I-D.ietf-precis-saslprepbis], 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
employing him during his work on earlier versions of this document. employing him during his work on earlier versions of this document.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
&yet &yet
Email: ietf@stpeter.im Email: ietf@stpeter.im
 End of changes. 47 change blocks. 
98 lines changed or deleted 190 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/