draft-ietf-precis-framework-04.txt   draft-ietf-precis-framework-05.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Obsoletes: 3454 (if approved) M. Blanchet Obsoletes: 3454 (if approved) M. Blanchet
Intended status: Standards Track Viagenie Intended status: Standards Track Viagenie
Expires: January 17, 2013 July 16, 2012 Expires: February 2, 2013 August 1, 2012
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-04 draft-ietf-precis-framework-05
Abstract Abstract
Application protocols using Unicode code points in protocol strings Application protocols using Unicode code points in protocol strings
need to prepare such strings in order to perform comparison need to prepare such strings in order to perform comparison
operations (e.g., for purposes of authentication or authorization). operations (e.g., for purposes of authentication or authorization).
This document defines a framework enabling application protocols to This document defines a framework enabling application protocols to
handle various classes of strings in a way that depends on the handle various classes of strings in a way that depends on the
properties of Unicode code points and that is agile with respect to properties of Unicode code points and that is agile with respect to
versions of Unicode; as a result, this framework provides a more versions of Unicode; as a result, this framework provides a more
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 17, 2013. This Internet-Draft will expire on February 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. String Classes . . . . . . . . . . . . . . . . . . . . . . . . 5 3. String Classes . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NameClass . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. NameClass . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4. Directionality . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 8
3.1.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 8 3.2.4. Directionality . . . . . . . . . . . . . . . . . . . . 8
3.1.6. Normalization . . . . . . . . . . . . . . . . . . . . 9 3.2.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 8
3.2. FreeClass . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.6. Normalization . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. FreeClass . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Valid . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Disallowed . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Directionality . . . . . . . . . . . . . . . . . . . . 10 3.3.3. Unassigned . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 10 3.3.4. Directionality . . . . . . . . . . . . . . . . . . . . 9
3.2.6. Normalization . . . . . . . . . . . . . . . . . . . . 10 3.3.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . 9
3.3.6. Normalization . . . . . . . . . . . . . . . . . . . . 10
4. Use of PRECIS String Classes . . . . . . . . . . . . . . . . . 10 4. Use of PRECIS String Classes . . . . . . . . . . . . . . . . . 10
4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Subclassing . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Subclassing . . . . . . . . . . . . . . . . . . . . . . . 10
5. Code Point Properties . . . . . . . . . . . . . . . . . . . . 11 4.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 11
5. Code Point Properties . . . . . . . . . . . . . . . . . . . . 12
6. Category Definitions Used to Calculate Derived Property 6. Category Definitions Used to Calculate Derived Property
Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . . 14 6.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . . 14
6.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 14 6.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 15
6.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 14 6.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 15
6.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . . 15 6.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . . 15
6.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . . 16 6.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . . 16
6.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 16 6.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 17
6.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 17 6.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 17
6.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . . 17 6.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . . 17
6.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . . 17 6.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . . 18
6.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . . 17 6.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . . 18
6.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 18 6.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 18
6.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . . 18 6.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . . 18
6.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 18 6.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 18
6.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 18 6.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 19
6.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 18 6.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 19
6.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 19 6.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 19
7. Calculation of the Derived Property . . . . . . . . . . . . . 19 7. Calculation of the Derived Property . . . . . . . . . . . . . 19
8. Code Points . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Code Points . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. PRECIS Derived Property Value Registry . . . . . . . . . . 20 9.1. PRECIS Derived Property Value Registry . . . . . . . . . . 20
9.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . . 21 9.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . . 21
9.3. PRECIS Subclasses Registry . . . . . . . . . . . . . . . . 21 9.3. PRECIS Subclasses Registry . . . . . . . . . . . . . . . . 21
9.4. PRECIS Usage Registry . . . . . . . . . . . . . . . . . . 22 9.4. PRECIS Usage Registry . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 22 10.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 5, line 41 skipping to change at page 5, line 41
[I-D.ietf-precis-problem-statement], [RFC6365], [RFC5890], and [I-D.ietf-precis-problem-statement], [RFC6365], [RFC5890], and
[UNICODE]. [UNICODE].
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
IDNA2008 essentially defines a base string class of internationalized IDNA2008 essentially defines a base string class of internationalized
domain name, although it does not use the term "string class". (This domain name, although it does not use the term "string class". (This
document does not define a string class for domain names, and document does not define a string class for domain names, and
application protocols are strongly encouraged to use IDNA2008 as the application protocols are strongly encouraged to use IDNA2008 as the
appropriate method to prepare domain names and hostnames.) Because appropriate method to prepare domain names and hostnames.) Because
the IDN string class is designed to meet the particular requirements the IDN string class is designed to meet the particular requirements
of the Domain Name System (DNS), additional string classes are needed of the Domain Name System (DNS), additional string classes are needed
for non-DNS applications. for non-DNS applications.
Starting in 2010, various "customers" of Stringprep began to discuss Starting in 2010, various "customers" of Stringprep began to discuss
skipping to change at page 6, line 35 skipping to change at page 6, line 37
providers, and end users might not understand or be able to enter providers, and end users might not understand or be able to enter
all of the characters that can be included in the FreeClass). all of the characters that can be included in the FreeClass).
Although members of the community discussed the possibility of Although members of the community discussed the possibility of
defining other bases string classes (e.g., a class falling somewhere defining other bases string classes (e.g., a class falling somewhere
between the NameClass and the FreeClass), they concluded that the between the NameClass and the FreeClass), they concluded that the
NameClass would be a safe choice meeting the needs of many or even NameClass would be a safe choice meeting the needs of many or even
most application protocols, and that protocols needing a wider range most application protocols, and that protocols needing a wider range
of Unicode characters could subclass the FreeClass. of Unicode characters could subclass the FreeClass.
OPEN ISSUE: As currently defined, the NameClass does not allow
spaces of any kind (even ASCII space, U+0020). This might be
counter-intuitive, given that spaces are included between family
names and personal names when representing the full names of
people (and full names might be used as usernames). The rough
sense of the PRECIS Working Group appears to be that spaces are
problematic for many reasons, for example because devices are
known to generate a character other than ASCII space (such as ZERO
WIDTH JOINER, U+200D) when a user does something like hit the
space bar on a keyboard. Working Group participants have also
raised concerns about the fact that spaces are not always visible,
and that many Unicode characters might be confusable with ASCII
space. However, it also appears that some protocols, such as the
Simple Authentication and Security Layer (SASL) [RFC4422], might
be used in ways that allow a username to include spaces. One
workaround might be to define a "CompoundName" class that allows
ASCII space but no other kind of space character; another might be
for protocols that need their protocol strings to potentially
contain compound names (such as the full names of people) to
define such strings as containing one or more space-separated
instances of the NameClass. This matter is not yet settled.
The following subsections discuss the NameClass and FreeClass in more The following subsections discuss the NameClass and FreeClass in more
detail, with reference to the dimensions described in Section 3 of detail, with reference to the dimensions described in Section 3 of
[I-D.ietf-precis-problem-statement]. In particular, each string [I-D.ietf-precis-problem-statement]. (Naturally, future documents
class is defined by the following behavioral rules: can define base string classes beyond the NameClass and FreeClass;
see Section 9.2.) In particular, each string class is defined by the
following behavioral rules:
Valid: defines which code points and character categories are Valid: defines which code points and character categories are
treated as valid input to preparation of the string. treated as valid input to preparation of the string.
Disallowed: defines which code points and character categories are Disallowed: defines which code points and character categories are
treated as disallowed during preparation of the string. treated as disallowed during preparation of the string.
Unassigned: defines application behavior in the presence of code Unassigned: defines application behavior in the presence of code
points that are unassigned, i.e. unknown for the version of points that are unassigned, i.e. unknown for the version of
Unicode the application is built upon. Unicode the application is built upon.
skipping to change at page 7, line 39 skipping to change at page 7, line 24
of case preservation), and how the mapping is done. of case preservation), and how the mapping is done.
Normalization: defines which Unicode normalization form (D, KD, C, Normalization: defines which Unicode normalization form (D, KD, C,
or KC) is to be applied (see [UAX15]). or KC) is to be applied (see [UAX15]).
This document defines the valid, disallowed, and unassigned rules for This document defines the valid, disallowed, and unassigned rules for
the NameClass and FreeClass. Application protocols that use these the NameClass and FreeClass. Application protocols that use these
string classes are responsible for defining the directionality, string classes are responsible for defining the directionality,
casemapping, and normalization rules. casemapping, and normalization rules.
Naturally, future documents can define base string classes beyond the Note well that in order to ensure proper comparison, any
NameClass and FreeClass; see Section 9.2. normalization MUST be completed before the application of additional
mappings or the process of checking whether a code point is valid,
disallowed, or unassigned.
3.1. NameClass 3.2. NameClass
Most application technologies need a special class of strings that Most application technologies need a special class of strings that
can be used to refer to, include, or communicate things like can be used to refer to, include, or communicate things like
usernames, file names, data feed names, and chatroom names. We group usernames, file names, data feed names, and chatroom names. We group
such things into a bucket called "NameClass" having the following such things into a bucket called "NameClass" having the following
features. features.
3.1.1. Valid 3.2.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 6.1. Section 6.1.
o Code points in the range U+0021 through U+007E, i.e., the ASCII7 o Code points in the range U+0021 through U+007E, i.e., the ASCII7
("K") rule defined under Section 6.11. These code points are ("K") rule defined under Section 6.11. These code points are
valid even if they would otherwise be disallowed according to the valid 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.
3.1.2. Disallowed 3.2.2. Disallowed
o Control characters, i.e., the Controls ("L") category defined o Control characters, i.e., the Controls ("L") category defined
under Section 6.12. under Section 6.12.
o Ignorable characters, i.e., the PrecisIgnorableProperties ("M") o Ignorable characters, i.e., the PrecisIgnorableProperties ("M")
category defined under Section 6.13. category defined under Section 6.13.
o Space characters, i.e., the Spaces ("N") category defined under o Space characters, i.e., the Spaces ("N") category defined under
Section 6.14. Section 6.14.
o Symbol characters, i.e., the Symbols ("O") category defined under o Symbol characters, i.e., the Symbols ("O") category defined under
Section 6.15. Section 6.15.
o Punctuation characters, i.e., the Punctuation ("P") category o Punctuation characters, i.e., the Punctuation ("P") category
defined under Section 6.16. defined under Section 6.16.
o Any character that has a compatibility equivalent, i.e., the o Any character that has a compatibility equivalent, i.e., the
HasCompat ("Q") category defined under Section 6.17. These code HasCompat ("Q") category defined under Section 6.17. These code
skipping to change at page 8, line 36 skipping to change at page 8, line 22
defined under Section 6.16. defined under Section 6.16.
o Any character that has a compatibility equivalent, i.e., the o Any character that has a compatibility equivalent, i.e., the
HasCompat ("Q") category defined under Section 6.17. These code HasCompat ("Q") category defined under Section 6.17. These code
points are disallowed even if they would otherwise be valid points are disallowed even if they would otherwise be valid
according to the property-based rules specified in the previous according to the property-based rules specified in the previous
section. section.
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 6.18. defined under Section 6.18.
3.1.3. Unassigned 3.2.3. Unassigned
Any code points that are not yet assigned in the Unicode character Any code points that are not yet assigned in the Unicode character
set SHALL be considered Unassigned for purposes of the NameClass. set SHALL be considered Unassigned for purposes of the NameClass.
3.1.4. Directionality 3.2.4. Directionality
The directionality rule MUST be specified by each application The directionality rule MUST be specified by each application
protocol that uses or subclasses the NameClass. protocol that uses or subclasses the NameClass.
3.1.5. Case Mapping 3.2.5. Case Mapping
The casemapping rule MUST be specified by each application protocol The casemapping rule MUST be specified by each application protocol
that uses or subclasses the NameClass. that uses or subclasses the NameClass.
3.1.6. Normalization 3.2.6. Normalization
The normalization form MUST be specified by each application protocol The normalization form MUST be specified by each application protocol
that uses or subclasses the NameClass. that uses or subclasses the NameClass.
However, in accordance with [RFC5198], normalization form C (NFC) is However, in accordance with [RFC5198], normalization form C (NFC) is
RECOMMENDED. RECOMMENDED.
3.2. FreeClass 3.3. FreeClass
Some application technologies need a special class of strings that Some application technologies need a special class of strings that
can be used in a free-form way, e.g., as a passphrase in an can be used in a free-form way, e.g., as a passphrase in an
authentication exchange (see [I-D.melnikov-precis-saslprepbis] or a authentication exchange (see [I-D.melnikov-precis-saslprepbis] or a
nickname in a chatroom (see [I-D.saintandre-precis-nickname]). We nickname in a chatroom (see [I-D.saintandre-precis-nickname]). We
group such things into a bucket called "FreeClass" having the group such things into a bucket called "FreeClass" having the
following features. following features.
NOTE: Consult Section 10.6 for relevant security considerations when NOTE: Consult Section 10.6 for relevant security considerations when
strings conforming to the FreeClass, or a subclass thereof, are used strings conforming to the FreeClass, or a subclass thereof, are used
as passwords or passphrases. as passwords or passphrases.
3.2.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 6.1. Section 6.1.
o Additional letters and numbers, i.e., the OtherLetterDigits ("R") o Additional letters and numbers, i.e., the OtherLetterDigits ("R")
category defined under Section 6.18. category defined under Section 6.18.
o Code points in the range U+0021 through U+007E, i.e., the ASCII7 o Code points in the range U+0021 through U+007E, i.e., the ASCII7
("K") rule defined under Section 6.11. ("K") rule defined under Section 6.11.
o Any character that has a compatibility equivalent, i.e., the o Any character that has a compatibility equivalent, i.e., the
HasCompat ("Q") category defined under Section 6.17. HasCompat ("Q") category defined under Section 6.17.
o Space characters, i.e., the Spaces ("N") category defined under o Space characters, i.e., the Spaces ("N") category defined under
Section 6.14. Section 6.14.
o Symbol characters, i.e., the Symbols ("O") category defined under o Symbol characters, i.e., the Symbols ("O") category defined under
Section 6.15. Section 6.15.
o Punctuation characters, i.e., the Punctuation ("P") category o Punctuation characters, i.e., the Punctuation ("P") category
defined under Section 6.16. defined under Section 6.16.
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 6.18. defined under Section 6.18.
3.2.2. Disallowed 3.3.2. Disallowed
o Control characters, i.e., the Controls ("L") category defined o Control characters, i.e., the Controls ("L") category defined
under Section 6.12. under Section 6.12.
o Ignorable characters, i.e., the PrecisIgnorableProperties ("M") o Ignorable characters, i.e., the PrecisIgnorableProperties ("M")
category defined under Section 6.13. category defined under Section 6.13.
3.2.3. Unassigned 3.3.3. Unassigned
Any code points that are not yet assigned in the Unicode character Any code points that are not yet assigned in the Unicode character
set SHALL be considered Unassigned for purposes of the FreeClass. set SHALL be considered Unassigned for purposes of the FreeClass.
3.2.4. Directionality 3.3.4. Directionality
The directionality rule MUST be specified by each application The directionality rule MUST be specified by each application
protocol that uses or subclasses the FreeClass. protocol that uses or subclasses the FreeClass.
3.2.5. Case Mapping 3.3.5. Case Mapping
The casemapping rule MUST be specified by each application protocol The casemapping rule MUST be specified by each application protocol
that uses or subclasses the FreeClass. that uses or subclasses the FreeClass.
In general, case preservation is NOT RECOMMENDED for application In general, case preservation is NOT RECOMMENDED for application
protocols that perform case-insensitive comparison of protocols that perform case-insensitive comparison of
internationalized strings; instead, application protocols SHOULD internationalized strings; instead, application protocols SHOULD
either (a) not preserve case but perform case-insensitive matching or either (a) not preserve case but perform case-insensitive matching or
(b) preserve case but perform case-sensitive comparison. (b) preserve case but perform case-sensitive comparison.
In order to maximize entropy, it is NOT RECOMMENDED for application In order to maximize entropy, it is NOT RECOMMENDED for application
protocols to map uppercase and titlecase code points to their protocols to map uppercase and titlecase code points to their
lowercase equivalents when strings conforming to the FreeClass, or a lowercase equivalents when strings conforming to the FreeClass, or a
subclass thereof, are used in passwords or passphrases; instead, it subclass thereof, are used in passwords or passphrases; instead, it
is RECOMMENDED to preserve the case of all code points contained in is RECOMMENDED to preserve the case of all code points contained in
such strings. such strings.
3.2.6. Normalization 3.3.6. Normalization
The normalization form MUST be specified by each application protocol The normalization form MUST be specified by each application protocol
that uses or subclasses the FreeClass. that uses or subclasses the FreeClass.
However, in accordance with [RFC5198], normalization form C (NFC) is However, in accordance with [RFC5198], normalization form C (NFC) is
RECOMMENDED. RECOMMENDED.
4. Use of PRECIS String Classes 4. Use of PRECIS String Classes
4.1. Principles 4.1. Principles
skipping to change at page 11, line 40 skipping to change at page 11, line 21
Application protocols that subclass the PRECIS string classes MUST Application protocols that subclass the PRECIS string classes MUST
register with the IANA as described under Section 9.3. register with the IANA as described under Section 9.3.
It is RECOMMENDED for subclass names to be of the form It is RECOMMENDED for subclass names to be of the form
"SubclassBaseClass", where the "Subclass" string is a differentiator "SubclassBaseClass", where the "Subclass" string is a differentiator
and "BaseClass" is the name of the base class being subclassed; for and "BaseClass" is the name of the base class being subclassed; for
example, the subclass of the NameClass used for localparts in the example, the subclass of the NameClass used for localparts in the
Extensible Messaging and Presence Protocol (XMPP) would be Extensible Messaging and Presence Protocol (XMPP) would be
"LocalpartNameClass" [I-D.ietf-xmpp-6122bis]. "LocalpartNameClass" [I-D.ietf-xmpp-6122bis].
4.3. A Note about Spaces
The NameClass does not allow spaces of any kind (even ASCII space,
U+0020). This might be counter-intuitive, given that spaces are
included between family names and personal names when representing
the full names of people (and full names might be used as usernames).
The consensus of the PRECIS Working Group is that spaces are
problematic for many reasons, for example because in some locales
some devices are known to generate a character other than ASCII space
(such as ZERO WIDTH JOINER, U+200D) when a user performs an action
like hit the space bar on a keyboard. Working Group participants
also raised concerns about the fact that spaces are not always
visible, and that many Unicode characters might be confusable with
ASCII space.
Although some existing protocols, such as the Simple Authentication
and Security Layer (SASL) [RFC4422], might be used in ways that allow
a username to include spaces, the sense of the Working Group was that
such protocols could define an application-layer construct that
consists of instances of the PRECIS NameClass separated from each
other by instances of the ASCII space character (U+0020). One
consequence of this approach might be to effectively discourage the
use of ASCII space (or, even more problematically, non-ASCII space
characters) in newer application protocols; given the challenges
involved in properly handling space characters in usernames,
identifiers, and other protocol strings, the Working Group considered
this to be a feature, not a bug.
5. Code Point Properties 5. 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,
which can vary depending on the string class being used by the which can vary depending on the string class being used by the
skipping to change at page 27, line 11 skipping to change at page 27, line 13
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.1", 2012, 6.1", 2012,
<http://www.unicode.org/versions/Unicode6.1.0/>. <http://www.unicode.org/versions/Unicode6.1.0/>.
12.2. Informative References 12.2. Informative References
[I-D.iab-identifier-comparison] [I-D.iab-identifier-comparison]
Thaler, D., "Issues in Identifier Comparison for Security Thaler, D., "Issues in Identifier Comparison for Security
Purposes", draft-iab-identifier-comparison-02 (work in Purposes", draft-iab-identifier-comparison-03 (work in
progress), May 2012. progress), July 2012.
[I-D.ietf-precis-problem-statement] [I-D.ietf-precis-problem-statement]
Sullivan, A. and M. Blanchet, "Stringprep Revision Problem Sullivan, A. and M. Blanchet, "Stringprep Revision Problem
Statement", draft-ietf-precis-problem-statement-06 (work Statement", draft-ietf-precis-problem-statement-06 (work
in progress), July 2012. in progress), July 2012.
[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", Protocol (XMPP): Address Format",
draft-ietf-xmpp-6122bis-02 (work in progress), April 2012. draft-ietf-xmpp-6122bis-02 (work in progress), April 2012.
 End of changes. 31 change blocks. 
70 lines changed or deleted 84 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/