< draft-ietf-precis-7700bis-08.txt   draft-ietf-precis-7700bis-09.txt >
PRECIS P. Saint-Andre PRECIS P. Saint-Andre
Internet-Draft Filament Internet-Draft Filament
Obsoletes: 7700 (if approved) June 27, 2017 Obsoletes: 7700 (if approved) July 16, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: December 29, 2017 Expires: January 17, 2018
Preparation, Enforcement, and Comparison of Internationalized Strings Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Nicknames Representing Nicknames
draft-ietf-precis-7700bis-08 draft-ietf-precis-7700bis-09
Abstract Abstract
This document describes methods for handling Unicode strings This document describes methods for handling Unicode strings
representing memorable, human-friendly names (called "nicknames", representing memorable, human-friendly names (called "nicknames",
"display names", or "petnames") for people, devices, accounts, "display names", or "petnames") for people, devices, accounts,
websites, and other entities. This document obsoletes RFC 7700. websites, and other entities. This document obsoletes RFC 7700.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 29, 2017. This Internet-Draft will expire on January 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Nickname Profile . . . . . . . . . . . . . . . . . . . . . . 3 2. Nickname Profile . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 5
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use in Application Protocols . . . . . . . . . . . . . . . . 6 4. Use in Application Protocols . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 8 6.1. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 8
6.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 8 6.2. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 8
6.3. Visually Similar Characters . . . . . . . . . . . . . . . 8 6.3. Visually Similar Characters . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from RFC 7700 . . . . . . . . . . . . . . . 11 Appendix A. Changes from RFC 7700 . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
A number of technologies and applications provide the ability for a A number of technologies and applications provide the ability for a
person to choose a memorable, human-friendly name in a communications person to choose a memorable, human-friendly name in a communications
skipping to change at page 5, line 7 skipping to change at page 5, line 7
and inapplicable to nicknames, because it is perfectly acceptable and inapplicable to nicknames, because it is perfectly acceptable
for a given nickname to be presented differently in different for a given nickname to be presented differently in different
layout systems (e.g., a user interface that is configured to layout systems (e.g., a user interface that is configured to
handle primarily a right-to-left script versus an interface that handle primarily a right-to-left script versus an interface that
is configured to handle primarily a left-to-right script), as is configured to handle primarily a left-to-right script), as
long as the presentation is consistent in any given layout long as the presentation is consistent in any given layout
system. system.
2.2. Preparation 2.2. Preparation
An entity that prepares a string for subsequent enforcement according An entity that prepares an input string for subsequent enforcement
to this profile MUST ensure that the string consists only of Unicode according to this profile MUST ensure that the string consists only
code points that conform to the FreeformClass string class defined in of Unicode code points that conform to the FreeformClass string class
[I-D.ietf-precis-7564bis]. defined in [I-D.ietf-precis-7564bis].
2.3. Enforcement 2.3. Enforcement
An entity that performs enforcement according to this profile MUST An entity that performs enforcement according to this profile MUST
prepare a string as described in Section 2.2 and MUST also apply the prepare an input string as described in Section 2.2 and MUST also
following rules specified in Section 2.1 in the order shown: apply the following rules specified in Section 2.1 in the order
shown:
1. Additional Mapping Rule 1. Additional Mapping Rule
2. Normalization Rule 2. Normalization Rule
Note: An entity SHOULD apply the Case Mapping Rule only during Note: An entity SHOULD apply the Case Mapping Rule only during
comparison. comparison.
After all of the foregoing rules have been enforced, the entity MUST After all of the foregoing rules have been enforced, the entity MUST
ensure that the nickname is not zero bytes in length (this is done ensure that the nickname is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly after enforcing the rules to prevent applications from mistakenly
omitting a nickname entirely, because when internationalized strings omitting a nickname entirely, because when internationalized strings
are accepted, a non-empty sequence of characters can result in a are accepted, a non-empty sequence of characters can result in a
zero-length nickname after canonicalization). zero-length nickname after canonicalization).
The result of the foregoing operations is an output string that
conforms to the Nickname profile. Until an implementation produces
such an output string, it MUST NOT treat the string as conforming (in
particular, it MUST NOT assume that an input string is conforming
before the enforcement operation has been completed).
2.4. Comparison 2.4. Comparison
An entity that performs comparison of two strings according to this An entity that performs comparison of two strings according to this
profile MUST prepare each string as specified in Section 2.2 and MUST profile MUST prepare each input string as specified in Section 2.2
apply the following rules specified in Section 2.1 in the order and MUST apply the following rules specified in Section 2.1 in the
shown: order shown:
1. Additional Mapping Rule 1. Additional Mapping Rule
2. Case Mapping Rule 2. Case Mapping Rule
3. Normalization Rule 3. Normalization Rule
The two strings are to be considered equivalent if and only if they The two strings are to be considered equivalent if and only if they
are an exact octet-for-octet match (sometimes called "bit-string are an exact octet-for-octet match (sometimes called "bit-string
identity"). identity").
Until an implementation determines whether two strings are to be
considered equivalent, it MUST NOT treat them as equivalent (in
particular, it MUST NOT assume that an input string conforms to the
rules before the comparison operation has been completed).
3. Examples 3. Examples
The following examples illustrate a small number of nicknames that The following examples illustrate a small number of nicknames that
are consistent with the format defined above, along with the output are consistent with the format defined above, along with the output
string resulting from application of the PRECIS rules (note that the string resulting from application of the PRECIS rules (note that the
characters < and > are used to delineate the actual nickname and are characters < and > are used to delineate the actual nickname and are
not part of the nickname strings). not part of the nickname strings).
Table 1: A Sample of Legal Nicknames Table 1: A Sample of Legal Nicknames
skipping to change at page 7, line 35 skipping to change at page 7, line 47
1. Where possible, map characters (e.g, through width mapping, 1. Where possible, map characters (e.g, through width mapping,
additional mapping, case mapping, or normalization) and accept additional mapping, case mapping, or normalization) and accept
the mapped string. the mapped string.
2. If mapping is not possible (e.g., because a character is 2. If mapping is not possible (e.g., because a character is
disallowed in the FreeformClass), reject the string. disallowed in the FreeformClass), reject the string.
Implementation experience has shown that applying the rules for the Implementation experience has shown that applying the rules for the
Nickname profile is not an idempotent procedure for all code points. Nickname profile is not an idempotent procedure for all code points.
Therefore, implementations might need to apply the rules more than Therefore, an implementation SHOULD apply the rules repeatedly until
once to a nickname string. the output string is stable; if the output string does not stabilize
within a reasonable number of iterations, the implementation SHOULD
terminate application of the rules and reject the input string as
invalid.
5. IANA Considerations 5. IANA Considerations
The IANA shall add the following entry to the PRECIS Profiles The IANA shall add the following entry to the PRECIS Profiles
Registry: Registry:
Name: Nickname Name: Nickname
Base Class: FreeformClass Base Class: FreeformClass
skipping to change at page 9, line 4 skipping to change at page 9, line 19
"confusable characters" or "confusables", and provides some examples "confusable characters" or "confusables", and provides some examples
of such characters. of such characters.
Although the mapping rules defined in Section 2 of this document are Although the mapping rules defined in Section 2 of this document are
designed, in part, to reduce the possibility of confusion about designed, in part, to reduce the possibility of confusion about
nicknames, this document does not provide more-detailed nicknames, this document does not provide more-detailed
recommendations regarding the handling of visually similar recommendations regarding the handling of visually similar
characters, such as those provided in [UTS39]. characters, such as those provided in [UTS39].
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-precis-7564bis] [I-D.ietf-precis-7564bis]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Internationalized Strings in Application Protocols",
draft-ietf-precis-7564bis-08 (work in progress), June draft-ietf-precis-7564bis-09 (work in progress), July
2017. 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
 End of changes. 15 change blocks. 
22 lines changed or deleted 38 lines changed or added

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