draft-ietf-precis-framework-22.txt   draft-ietf-precis-framework-23.txt 
PRECIS P. Saint-Andre PRECIS P. Saint-Andre
Internet-Draft &yet Internet-Draft &yet
Obsoletes: 3454 (if approved) M. Blanchet Obsoletes: 3454 (if approved) M. Blanchet
Intended status: Standards Track Viagenie Intended status: Standards Track Viagenie
Expires: August 9, 2015 February 5, 2015 Expires: August 23, 2015 February 19, 2015
PRECIS Framework: Preparation, Enforcement, and Comparison of PRECIS Framework: Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols Internationalized Strings in Application Protocols
draft-ietf-precis-framework-22 draft-ietf-precis-framework-23
Abstract Abstract
Application protocols using Unicode characters in protocol strings Application protocols using Unicode characters in protocol strings
need to properly handle such strings in order to enforce need to properly handle such strings in order to enforce
internationalization rules for strings placed in various protocol internationalization rules for strings placed in various protocol
slots (such as addresses and identifiers) and to perform valid slots (such as addresses and identifiers) and 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, enforcement, and application protocols to perform the preparation, enforcement, and
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 9, 2015. This Internet-Draft will expire on August 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 12 4.3.4. Unassigned . . . . . . . . . . . . . . . . . . . . . 12
4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12 4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 12
5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Profiles Must Not Be Multiplied Beyond Necessity . . . . 13 5.1. Profiles Must Not Be Multiplied Beyond Necessity . . . . 13
5.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Width Mapping Rule . . . . . . . . . . . . . . . . . 13 5.2.1. Width Mapping Rule . . . . . . . . . . . . . . . . . 13
5.2.2. Additional Mapping Rule . . . . . . . . . . . . . . . 14 5.2.2. Additional Mapping Rule . . . . . . . . . . . . . . . 14
5.2.3. Case Mapping Rule . . . . . . . . . . . . . . . . . . 14 5.2.3. Case Mapping Rule . . . . . . . . . . . . . . . . . . 14
5.2.4. Normalization Rule . . . . . . . . . . . . . . . . . 15 5.2.4. Normalization Rule . . . . . . . . . . . . . . . . . 15
5.2.5. Directionality Rule . . . . . . . . . . . . . . . . . 15 5.2.5. Directionality Rule . . . . . . . . . . . . . . . . . 15
5.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 15 5.3. A Note about Spaces . . . . . . . . . . . . . . . . . . . 16
6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. How to Use PRECIS in Applications . . . . . . . . . . . . 16 6.1. How to Use PRECIS in Applications . . . . . . . . . . . . 17
6.2. Further Excluded Characters . . . . . . . . . . . . . . . 17 6.2. Further Excluded Characters . . . . . . . . . . . . . . . 17
6.3. Building Application-Layer Constructs . . . . . . . . . . 17 6.3. Building Application-Layer Constructs . . . . . . . . . . 18
7. Order of Operations . . . . . . . . . . . . . . . . . . . . . 18 7. Order of Operations . . . . . . . . . . . . . . . . . . . . . 19
8. Code Point Properties . . . . . . . . . . . . . . . . . . . . 18 8. Code Point Properties . . . . . . . . . . . . . . . . . . . . 19
9. Category Definitions Used to Calculate Derived Property . . . 21 9. Category Definitions Used to Calculate Derived Property . . . 22
9.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 21 9.1. LetterDigits (A) . . . . . . . . . . . . . . . . . . . . 22
9.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Unstable (B) . . . . . . . . . . . . . . . . . . . . . . 22
9.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 22 9.3. IgnorableProperties (C) . . . . . . . . . . . . . . . . . 23
9.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 22 9.4. IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . . 23
9.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.5. LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 22 9.6. Exceptions (F) . . . . . . . . . . . . . . . . . . . . . 23
9.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 22 9.7. BackwardCompatible (G) . . . . . . . . . . . . . . . . . 23
9.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 22 9.8. JoinControl (H) . . . . . . . . . . . . . . . . . . . . . 23
9.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 22 9.9. OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . . 23
9.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 23 9.10. Unassigned (J) . . . . . . . . . . . . . . . . . . . . . 24
9.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 23 9.11. ASCII7 (K) . . . . . . . . . . . . . . . . . . . . . . . 24
9.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 23 9.12. Controls (L) . . . . . . . . . . . . . . . . . . . . . . 24
9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 23 9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . . 24
9.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 23 9.14. Spaces (N) . . . . . . . . . . . . . . . . . . . . . . . 24
9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 23 9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . . 24
9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 24 9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . . 25
9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 24 9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . . 25
9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 24 9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . . 25
10. Guidelines for Designated Experts . . . . . . . . . . . . . . 24 10. Guidelines for Designated Experts . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. PRECIS Derived Property Value Registry . . . . . . . . . 25 11.1. PRECIS Derived Property Value Registry . . . . . . . . . 26
11.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 25 11.2. PRECIS Base Classes Registry . . . . . . . . . . . . . . 26
11.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 26 11.3. PRECIS Profiles Registry . . . . . . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12.1. General Issues . . . . . . . . . . . . . . . . . . . . . 28 12.1. General Issues . . . . . . . . . . . . . . . . . . . . . 29
12.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 29 12.2. Use of the IdentifierClass . . . . . . . . . . . . . . . 30
12.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 29 12.3. Use of the FreeformClass . . . . . . . . . . . . . . . . 30
12.4. Local Character Set Issues . . . . . . . . . . . . . . . 29 12.4. Local Character Set Issues . . . . . . . . . . . . . . . 30
12.5. Visually Similar Characters . . . . . . . . . . . . . . 29 12.5. Visually Similar Characters . . . . . . . . . . . . . . 30
12.6. Security of Passwords . . . . . . . . . . . . . . . . . 31 12.6. Security of Passwords . . . . . . . . . . . . . . . . . 32
13. Interoperability Considerations . . . . . . . . . . . . . . . 32 13. Interoperability Considerations . . . . . . . . . . . . . . . 33
13.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 32 13.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 33
13.2. Character Sets . . . . . . . . . . . . . . . . . . . . . 32 13.2. Character Sets . . . . . . . . . . . . . . . . . . . . . 33
13.3. Unicode Versions . . . . . . . . . . . . . . . . . . . . 33 13.3. Unicode Versions . . . . . . . . . . . . . . . . . . . . 34
13.4. Potential Changes to Handling of Certain Unicode Code 13.4. Potential Changes to Handling of Certain Unicode Code
Points . . . . . . . . . . . . . . . . . . . . . . . . . 33 Points . . . . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . 34 14.2. Informative References . . . . . . . . . . . . . . . . . 35
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Application protocols using Unicode characters [Unicode7.0] in Application protocols using Unicode characters [Unicode7.0] in
protocol strings need to properly handle such strings in order to protocol strings need to properly handle such strings in order to
enforce internationalization rules for strings placed in various enforce internationalization rules for strings placed in various
protocol slots (such as addresses and identifiers) and to perform protocol slots (such as addresses and identifiers) and to perform
valid comparison operations (e.g., for purposes of authentication or valid 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, enforcement, and application protocols to perform the preparation, enforcement, and
skipping to change at page 6, line 6 skipping to change at page 6, line 6
mapping of certain characters to other characters or to nothing, and mapping of certain characters to other characters or to nothing, and
mapping of full-width and half-width characters. mapping of full-width and half-width characters.
When an application applies a profile of a PRECIS string class, it When an application applies a profile of a PRECIS string class, it
transforms an input string (which might or might not be conforming) transforms an input string (which might or might not be conforming)
into an output string that definitively conforms to the profile. In into an output string that definitively conforms to the profile. In
particular, this document focuses on the resulting ability to achieve particular, this document focuses on the resulting ability to achieve
the following objectives: the following objectives:
a. Enforcing all the the rules of a profile for a single output a. Enforcing all the the rules of a profile for a single output
string (e.g., to determine if a string can be included protocol string (e.g., to determine if a string can be included in a
slot, communicated to another entity within a protocol, stored in protocol slot, communicated to another entity within a protocol,
a retrieval system, etc.). stored in a retrieval system, etc.).
b. Comparing two output strings to determine if they equivalent, b. Comparing two output strings to determine if they are equivalent,
typically through octet-for-octet matching to test for "bit- typically through octet-for-octet matching to test for "bit-
string identity" (e.g., to make an access decision for purposes string identity" (e.g., to make an access decision for purposes
of authentication or authorization as further described in of authentication or authorization as further described in
[RFC6943]). [RFC6943]).
The opportunity to define profiles naturally introduces the The opportunity to define profiles naturally introduces the
possibility of a proliferation of profiles, thus potentially possibility of a proliferation of profiles, thus potentially
mitigating the benefits of common code and violating user mitigating the benefits of common code and violating user
expectations. See Section 5 for a discussion of this important expectations. See Section 5 for a discussion of this important
topic. topic.
skipping to change at page 15, line 17 skipping to change at page 15, line 17
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.
5.2.5. Directionality Rule 5.2.5. Directionality Rule
The directionality rule of a profile specifies how to treat strings The directionality rule of a profile specifies how to treat strings
that contain right-to-left (RTL) characters (see Unicode Standard containing what are often called "right-to-left" (RTL) characters
Annex #9 [UAX9]). In general this document recommends applying the (see Unicode Standard Annex #9 [UAX9]). RTL characters come from
"Bidi Rule" from [RFC5893] to strings that contain RTL characters. scripts that are normally written from right to left and are
considered by Unicode to, themselves, have right-to-left
directionality. Some strings containing RTL characters also contain
"left-to-right" (LTR) characters, such as numerals, as well as
characters without directional properties. Consequently, such
strings are known as "bidirectional strings".
Mixed-direction strings (that is, strings containing some portions Presenting bidirectional strings in different layout systems (e.g., a
that are left-to-right and other portions that are right-to-left) are user interface that is configured to handle primarily an RTL script
not directly supported by the PRECIS framework itself, since there is vs. an interface that is configured to handle primarily an LTR
currently no widely accepted and implemented solution for the safe script) can yield display results that, while predictable to those
display of mixed-direction strings. An application protocol that who understand the display rules, are counter-intuitive to casual
uses the PRECIS framework (or an extension to the framework) could users. In particular, the same bidirectional string (in PRECIS
define better ways to present mixed-direction strings; however, that terms) might not be presented in the same way to users of those
work is outside the scope of this framework and would likely require different layout systems, even though the presentation is consistent
a great deal of careful research into the problems of displaying within any particular layout system. In some applications, these
bidirectional text. presentation differences might be considered problematic and thus the
application designers might wish to restrict the use of bidirectional
strings by specifying a directionality rule. In other applications,
these presentation differences might not be considered problematic
(this especially tends to be true of more "free-form" strings) and
thus no directionality rule is needed.
The PRECIS framework does not directly address how to deal with
bidirectional strings across all string classes and profiles, and
does not define any new directionality rules, since at present there
is no widely accepted and implemented solution for the safe display
of arbitrary bidirectional strings beyond the Unicode bidirectional
algorithm [UAX9]. Although rules for management and display of
bidirectional strings have been defined for domain name labels and
similar identifiers through the "Bidi Rule" specified in the IDNA2008
specification on right-to-left scripts [RFC5893], those rules are
quite restrictive and are not necessarily applicable to all
bidirectional strings.
The authors of a PRECIS profile might believe that they need to
define a new directionality rule of their own. Because of the
complexity of the issues involved, such a belief is almost always
misguided, even if the authors have done a great deal of careful
research into the challenges of displaying bidirectional strings.
This document strongly suggests that profile authors who are thinking
about defining a new directionality rule think again, and instead
consider using the "Bidi Rule" [RFC5893] (for profiles based on the
IdentifierClass) or following the Unicode bidirectional algorithm
[UAX9] (for profiles based on the FreeformClass or in situations
where the IdentifierClass is not appropriate).
5.3. A Note about Spaces 5.3. A Note about Spaces
With regard to the IdentiferClass, the consensus of the PRECIS With regard to the IdentiferClass, the consensus of the PRECIS
Working Group was that spaces are problematic for many reasons, Working Group was that spaces are problematic for many reasons,
including: including:
o Many Unicode characters are confusable with ASCII space. o Many Unicode characters are confusable with ASCII space.
o Even if non-ASCII space characters are mapped to ASCII space o Even if non-ASCII space characters are mapped to ASCII space
 End of changes. 10 change blocks. 
68 lines changed or deleted 102 lines changed or added

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