RFC 8264

PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols 🎀

okay bestie, this is RFC 8264 and it's giving main character energy 💅 It's a Standards Track document from the IETF (Internet Engineering Task Force), published as Request for Comments 8264 in October 2017. The ISSN is 2070-1721. The authors are P. Saint-Andre from Jabber.org and M. Blanchet from Viagenie 🫶 It obsoletes RFC 7564, which means that older doc is officially replaced by this one. It doesn't update anything else.

---

Abstract ✨

okay so, application protocols that use Unicode code points in their strings have to handle those strings properly 😭 They need to enforce internationalization rules for strings that go into protocol slots like addresses and identifiers, and they need to do valid comparisons, for example when doing authentication or authorization 🔐 This document defines a framework for exactly that: the preparation, enforcement, and comparison of internationalized strings, which the document calls "PRECIS" 🌸 The vibe is that it depends on the properties of Unicode code points, so it stays agile across different versions of Unicode, which is so smart 🧠 That makes it a more sustainable way to handle internationalized strings than the old framework, Stringprep (RFC 3454). And again, this document obsoletes RFC 7564 💖

---

Status of This Memo 📜

this one is an Internet Standards Track document 🦋

It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG), so it's legit 👑 If you want more info on Internet Standards, check out Section 2 of RFC 7841.

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8264. 🍓

---

Copyright Notice 🌈

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can see at https://trustee.ietf.org/license-info as they were in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document 🙈 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License. Not a vibe to skip 💀

---

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
3.  Preparation, Enforcement, and Comparison  . . . . . . . . . .   6
4.  String Classes  . . . . . . . . . . . . . . . . . . . . . . .   8
  4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
  4.2.  IdentifierClass . . . . . . . . . . . . . . . . . . . . .   9
    4.2.1.  Valid . . . . . . . . . . . . . . . . . . . . . . . .   9
    4.2.2.  Contextual Rule Required  . . . . . . . . . . . . . .  10
    4.2.3.  Disallowed  . . . . . . . . . . . . . . . . . . . . .  10
    4.2.4.  Unassigned  . . . . . . . . . . . . . . . . . . . . .  10
    4.2.5.  Examples  . . . . . . . . . . . . . . . . . . . . . .  11
  4.3.  FreeformClass . . . . . . . . . . . . . . . . . . . . . .  11
    4.3.1.  Valid . . . . . . . . . . . . . . . . . . . . . . . .  11
    4.3.2.  Contextual Rule Required  . . . . . . . . . . . . . .  12
    4.3.3.  Disallowed  . . . . . . . . . . . . . . . . . . . . .  12
    4.3.4.  Unassigned  . . . . . . . . . . . . . . . . . . . . .  12
    4.3.5.  Examples  . . . . . . . . . . . . . . . . . . . . . .  12
  4.4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  12
5.  Profiles  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
  5.1.  Profiles Must Not Be Multiplied beyond Necessity  . . . .  14
  5.2.  Rules . . . . . . . . . . . . . . . . . . . . . . . . . .  15
    5.2.1.  Width Mapping Rule  . . . . . . . . . . . . . . . . .  15
    5.2.2.  Additional Mapping Rule . . . . . . . . . . . . . . .  15
    5.2.3.  Case Mapping Rule . . . . . . . . . . . . . . . . . .  16
    5.2.4.  Normalization Rule  . . . . . . . . . . . . . . . . .  16
    5.2.5.  Directionality Rule . . . . . . . . . . . . . . . . .  17
  5.3.  A Note about Spaces . . . . . . . . . . . . . . . . . . .  18
6.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .  18
  6.1.  How to Use PRECIS in Applications . . . . . . . . . . . .  18
  6.2.  Further Excluded Characters . . . . . . . . . . . . . . .  20
  6.3.  Building Application-Layer Constructs . . . . . . . . . .  20
7.  Order of Operations . . . . . . . . . . . . . . . . . . . . .  21
8.  Code Point Properties . . . . . . . . . . . . . . . . . . . .  21
9.  Category Definitions Used to Calculate Derived Property . . .  24
  9.1.  LetterDigits (A)  . . . . . . . . . . . . . . . . . . . .  25
  9.2.  Unstable (B)  . . . . . . . . . . . . . . . . . . . . . .  25
  9.3.  IgnorableProperties (C) . . . . . . . . . . . . . . . . .  25
  9.4.  IgnorableBlocks (D) . . . . . . . . . . . . . . . . . . .  25
  9.5.  LDH (E) . . . . . . . . . . . . . . . . . . . . . . . . .  25
  9.6.  Exceptions (F)  . . . . . . . . . . . . . . . . . . . . .  25
  9.7.  BackwardCompatible (G)  . . . . . . . . . . . . . . . . .  25
  9.8.  JoinControl (H) . . . . . . . . . . . . . . . . . . . . .  26
  9.9.  OldHangulJamo (I) . . . . . . . . . . . . . . . . . . . .  26
  9.10. Unassigned (J)  . . . . . . . . . . . . . . . . . . . . .  26
  9.11. ASCII7 (K)  . . . . . . . . . . . . . . . . . . . . . . .  26
  9.12. Controls (L)  . . . . . . . . . . . . . . . . . . . . . .  27
  9.13. PrecisIgnorableProperties (M) . . . . . . . . . . . . . .  27
  9.14. Spaces (N)  . . . . . . . . . . . . . . . . . . . . . . .  27
  9.15. Symbols (O) . . . . . . . . . . . . . . . . . . . . . . .  27
  9.16. Punctuation (P) . . . . . . . . . . . . . . . . . . . . .  27
  9.17. HasCompat (Q) . . . . . . . . . . . . . . . . . . . . . .  28
  9.18. OtherLetterDigits (R) . . . . . . . . . . . . . . . . . .  28
10. Guidelines for Designated Experts . . . . . . . . . . . . . .  28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
  11.1.  PRECIS Derived Property Value Registry . . . . . . . . .  29
  11.2.  PRECIS Base Classes Registry . . . . . . . . . . . . . .  29
  11.3.  PRECIS Profiles Registry . . . . . . . . . . . . . . . .  30
12. Security Considerations . . . . . . . . . . . . . . . . . . .  32
  12.1.  General Issues . . . . . . . . . . . . . . . . . . . . .  32
  12.2.  Use of the IdentifierClass . . . . . . . . . . . . . . .  33
  12.3.  Use of the FreeformClass . . . . . . . . . . . . . . . .  33
  12.4.  Local Character Set Issues . . . . . . . . . . . . . . .  33
  12.5.  Visually Similar Characters  . . . . . . . . . . . . . .  33
  12.6.  Security of Passwords  . . . . . . . . . . . . . . . . .  35
13. Interoperability Considerations . . . . . . . . . . . . . . .  36
  13.1.  Coded Character Sets . . . . . . . . . . . . . . . . . .  36
  13.2.  Dependency on Unicode  . . . . . . . . . . . . . . . . .  37
  13.3.  Encoding . . . . . . . . . . . . . . . . . . . . . . . .  37
  13.4.  Unicode Versions . . . . . . . . . . . . . . . . . . . .  37
  13.5.  Potential Changes to Handling of Certain Unicode Code
         Points . . . . . . . . . . . . . . . . . . . . . . . . .  37
14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
  14.1.  Normative References . . . . . . . . . . . . . . . . . .  38
  14.2.  Informative References . . . . . . . . . . . . . . . . .  39
Appendix A.  Changes from RFC 7564  . . . . . . . . . . . . . . .  43
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  43
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43

okay that's the whole map of the doc 🗺️✨ Part 2 is next, bestie 🦋💖

1. Introduction ✨

okay bestie, so application protocols that use Unicode code points [Unicode] in protocol strings have to handle those strings really carefully 💅. They need to enforce internationalization rules on strings placed in protocol slots (like addresses and identifiers 🎀) and run valid comparisons (for example, for authentication or authorization 🔐). This document defines a framework that lets apps do the preparation, enforcement, and comparison of internationalized strings ("PRECIS") based on the properties of Unicode code points, so it stays agile across Unicode versions 🦋. (Note: PRECIS is restricted to Unicode and does not support any other coded character set [RFC6365].)

As the PRECIS problem statement [RFC6885] explains, lots of IETF protocols have used the Stringprep framework [RFC3454] to prep, enforce, and compare protocol strings with Unicode code points, especially ones outside the ASCII range [RFC20] 🌸. Stringprep was built during the original work on internationalized domain names (IDNs), which this document calls "IDNA2003" [RFC3490]. Nameprep [RFC3491] was the Stringprep profile for IDNs. Stringprep was designed as a general framework, so other application protocols could write their own Stringprep profiles, and a bunch of them did 💖.

After [RFC3454] came out in 2002, some big issues showed up with using Stringprep for IDNs, as the IAB's recommendations regarding IDNs [RFC4690] document. The biggest one was that Stringprep was tied to Unicode version 3.2 😬. So the newer IDNA specifications, which this document calls "IDNA2008" [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894], no longer use Stringprep or Nameprep. This move away from Stringprep for IDNs made other "customers" of Stringprep look for new approaches to preparing, enforcing, and comparing internationalized strings, as [RFC6885] describes ✨.

This document sets up a framework for a post-Stringprep approach to preparing, enforcing, and comparing internationalized strings in application protocols. It's built on several principles:

1. Define a small set of string classes that specify the Unicode code points appropriate for common application-protocol constructs (where possible, staying compatible with IDNA2008 so users get a more consistent experience 🫶).
2. Define each PRECIS string class in terms of Unicode code points and their properties, so an algorithm can decide whether each code point or character category is (a) valid, (b) allowed in certain contexts, (c) disallowed, or (d) unassigned.
3. Use an "inclusion model", so a string class only includes code points that are explicitly allowed. That means any code point not explicitly allowed is forbidden 🚫.
4. Let application protocols define profiles of the PRECIS string classes when needed (covering things like width mapping, case mapping, Unicode normalization, and directionality), but strongly discourage making more profiles than necessary, to avoid breaking the "Principle of Least Astonishment" 😭.

This framework is expected to bring these benefits:

• Application protocols will be more agile with regard to Unicode versions (recognizing that complete agility cannot be realized in practice) 🌈.
• Implementers will be able to share code point tables and software code across application protocols, most likely through software libraries 📚.
• End users will get more accurate expectations about the code points that are acceptable in various contexts. With this more uniform set of string classes, copy/paste operations between software implementing different application protocols are also expected to be more predictable and coherent 💅.

The string classes set the "baseline" code points for a range of applications, and profiling lets application protocols use those classes in ways that suit common constructs like usernames [RFC8265], opaque strings such as passwords [RFC8265], and nicknames [RFC8266] 🍓. Profiles are responsible for handling right-to-left code points, plus the various mapping operations also discussed for IDNs in [RFC5895]. Those include case preservation or lowercasing, Unicode normalization, mapping certain code points to other code points (or to nothing), and mapping fullwidth and halfwidth code points 🧚.

When an application applies a profile of a PRECIS string class, it transforms an input string (which might or might not be conforming) into an output string that definitively conforms to the profile. This document focuses on two objectives that this makes possible ⭐:

a. Enforcing all the rules of a profile for a single output string, to check whether the output string conforms to the profile's rules. This decides whether a string can go into a protocol slot, be communicated to another entity within a protocol, be stored in a retrieval system, and so on.

b. Comparing two output strings to determine if they are equivalent, typically through octet-for-octet matching to test for "bit-string identity" (for example, to make an access decision for authentication or authorization, as further described in [RFC6943]) 🔐.

Defining profiles naturally opens the door to a proliferation of profiles, which could undo the benefits of common code and go against user expectations. See Section 5 for a discussion of this important topic 👀.

It's also super important for protocol designers and application developers to know that turning an input string into an output string is rarely reversible 🙈. For a simple example, case mapping would turn the input string "StPeter" into the output string "stpeter", losing the information about capitalization of the first and third characters. Similar considerations apply to other forms of mapping and normalization.

This framework is similar to IDNA2008 and includes by reference some of the character categories defined in [RFC5892]. It also defines additional character categories to meet the needs of common application protocols other than DNS 🎀.

The character categories and calculation rules defined under Sections 8 and 9 are normative and apply to all Unicode code points 💜. The code point table that results from applying the character categories and calculation rules to the latest version of Unicode can be found in an IANA registry (see Section 11).

2. Terminology ✨

Many important terms used in this document are defined in [RFC5890], [RFC6365], [RFC6885], and [Unicode]. The terms "left-to-right" (LTR) and "right-to-left" (RTL) are defined in Unicode Standard Annex #9 [UAX9] 🌸.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖.

3. Preparation, Enforcement, and Comparison 💖

This document distinguishes between three different actions that an entity can take with regard to a string:

• Enforcement entails applying all of the rules specified for a particular string class, or profile thereof, to a single input string. The goal is to check whether the string conforms to all of the rules, so it can be decided whether the string can be used in a given protocol slot 🔍.
• Comparison entails applying all of the rules specified for a particular string class, or profile thereof, to two separate input strings. The goal is to determine if the two strings are equivalent 🧐.
• Preparation primarily entails ensuring that the code points in a single input string are allowed by the underlying PRECIS string class. Sometimes it also entails applying one or more of the rules specified for a particular string class or profile thereof. Preparation can be appropriate for constrained devices that can restrict the code points in a string to a limited repertoire of characters, but that don't have the processing power or onboard memory to do things like Unicode normalization 🔋. However, preparation does not ensure that an input string conforms to all of the rules for a string class or profile thereof 🚫.

Note: The term "preparation" as used in this specification and related documents has a much more limited scope than it did in Stringprep. It essentially refers to a kind of preprocessing of an input string, not the actual operations that apply internationalization rules to produce an output string (here termed "enforcement") or to compare two output strings (here termed "comparison").

In most cases, authoritative entities such as servers are responsible for enforcement, whereas subsidiary entities such as clients are responsible only for preparation 🏰. The reason for this split is that clients might not have the device memory and processing power to enforce all the rules for internationalized strings (like width mapping and Unicode normalization), although they can more easily limit the repertoire of characters they offer to an end user 💅. Servers are assumed to have more capacity to enforce the rules. A server also acts as the authority on allowable strings in protocol slots like addresses and endpoint identifiers 👑. On top of that, a client cannot necessarily be trusted to properly generate such strings, especially in security-sensitive contexts like authentication and authorization 😤.

4. String Classes ✨

4.1. Overview ✨

Okay so, starting in 2010, a bunch of "customers" of Stringprep started saying they needed a post-Stringprep way to prep and compare internationalized strings that aren't IDNs. 💅 That community looked at the existing Stringprep profiles, then weighed two options: a relatively small set of Unicode code points that would keep user confusion down from visually similar characters (so relatively "safe"), or a much bigger set that would let users get creative (so relatively "expressive"). 🦋 In the end they concluded that most existing uses could be covered by two string classes:

• IdentifierClass: a sequence of letters, numbers, and some symbols used to identify or address a network entity, like a user account, a venue (e.g., a chat room), an information source (e.g., a data feed), or a collection of data (e.g., a file). The goal is to minimize user confusion across a wide variety of application protocols, so safety won out over expressiveness for this class. 🔐
• FreeformClass: a sequence of letters, numbers, symbols, spaces, and other code points used for free-form strings, including passwords and display stuff like human-friendly nicknames for devices or chat participants. This class is meant to allow nearly any Unicode code point, so expressiveness was prioritized over safety here. 🌈 Note well that protocol designers, application developers, service providers, and end users might not understand or be able to enter every code point the FreeformClass can include (see Section 12.3 for details).

Future specifications might define more PRECIS string classes, like one that lands somewhere between the IdentifierClass and the FreeformClass. 🧚 Right now it isn't clear how useful that would be. Either way, application developers can define profiles of PRECIS string classes, so a protocol that needs something in between could define a restricted profile of the FreeformClass if it wants.

The next subsections dig into the IdentifierClass and FreeformClass, using the dimensions described in Section 5 of [RFC6885]. Each string class is defined by these behavioral rules:

• Valid: which code points are treated as valid for the string.
• Contextual Rule Required: which code points are treated as allowed only if the requirements of a contextual rule are met (i.e., either CONTEXTJ or CONTEXTO as originally defined in the IDNA2008 specifications). ✨
• Disallowed: which code points need to be excluded from the string. 🙈
• Unassigned: how an application should behave when it runs into code points that are unknown (i.e., not yet designated) for the version of Unicode it uses. 🍓

This document defines the valid, contextual rule required, disallowed, and unassigned rules for both the IdentifierClass and FreeformClass. As described under Section 5, profiles of these string classes are responsible for defining the width mapping, additional mapping, case mapping, normalization, and directionality rules. 💜

---

4.2. IdentifierClass 🔐

Most application technologies need strings that can refer to, include, or communicate protocol strings like usernames, filenames, data feed identifiers, and chat room names. We group these strings into a class called "IdentifierClass" with the following features. 🎀

4.2.1. Valid

• Code points traditionally used as letters and numbers in writing systems, i.e., the LetterDigits ("A") category first defined in [RFC5892] and listed here under Section 9.1.
• Code points in the range U+0021 through U+007E, i.e., the (printable) ASCII7 ("K") category defined under Section 9.11. These code points are "grandfathered" into PRECIS, so they stay valid even if the property-based rules in the next section would otherwise disallow them. 🫶

Note: Although the PRECIS IdentifierClass reuses the LetterDigits category from IDNA2008, the range of code points allowed in the IdentifierClass is wider than the range allowed in IDNA2008. The main reason is that IDNA2008 applies the Unstable ("B") category (Section 9.2) before the LetterDigits category, which disallows uppercase code points, whereas the IdentifierClass does not apply the Unstable category. 😭

4.2.2. Contextual Rule Required

• A number of code points from the Exceptions ("F") category defined under Section 9.6.
• Joining code points, i.e., the JoinControl ("H") category defined under Section 9.8.

4.2.3. Disallowed

• Old Hangul Jamo code points, i.e., the OldHangulJamo ("I") category defined under Section 9.9.
• Control code points, i.e., the Controls ("L") category defined under Section 9.12.
• Ignorable code points, i.e., the PrecisIgnorableProperties ("M") category defined under Section 9.13.
• Space code points, i.e., the Spaces ("N") category defined under Section 9.14.
• Symbol code points, i.e., the Symbols ("O") category defined under Section 9.15.
• Punctuation code points, i.e., the Punctuation ("P") category defined under Section 9.16.
• Any code point that is decomposed and recomposed into something other than itself under Unicode Normalization Form KC, i.e., the HasCompat ("Q") category defined under Section 9.17. These are disallowed even if the property-based rules in the previous section would otherwise make them valid. 💀
• Letters and digits other than the "traditional" letters and digits allowed in IDNs, i.e., the OtherLetterDigits ("R") category defined under Section 9.18.

4.2.4. Unassigned

Any code points that are not yet designated in the Unicode coded character set are considered unassigned for the purposes of the IdentifierClass, and such code points are to be treated as disallowed. See Section 9.10. 🌸

4.2.5. Examples

As described in the Introduction to this document, the string classes don't handle every issue related to string preparation and comparison (such as case mapping). Those issues are handled at the level of profiles instead. 🧚 Examples of profiles for the IdentifierClass can be found in [RFC8265] (the UsernameCaseMapped and UsernameCasePreserved profiles).

---

4.3. FreeformClass 🌈

Some application technologies need strings that can be used in a free-form way, e.g., as a password in an authentication exchange (see [RFC8265]) or a nickname in a chat room (see [RFC8266]). We group these things into a class called "FreeformClass" with the following features. 🍓

Security Warning: As mentioned, the FreeformClass prioritizes expressiveness over safety. Section 12.3 describes some of the security hazards involved with using or profiling the FreeformClass. 🙈

Security Warning: Consult Section 12.6 for relevant security considerations when strings conforming to the FreeformClass, or a profile thereof, are used as passwords. 🔥

4.3.1. Valid

• Traditional letters and numbers, i.e., the LetterDigits ("A") category first defined in [RFC5892] and listed here under Section 9.1.
• Code points in the range U+0021 through U+007E, i.e., the (printable) ASCII7 ("K") category defined under Section 9.11.
• Space code points, i.e., the Spaces ("N") category defined under Section 9.14.
• Symbol code points, i.e., the Symbols ("O") category defined under Section 9.15.
• Punctuation code points, i.e., the Punctuation ("P") category defined under Section 9.16.
• Any code point that is decomposed and recomposed into something other than itself under Unicode Normalization Form KC, i.e., the HasCompat ("Q") category defined under Section 9.17.
• Letters and digits other than the "traditional" letters and digits allowed in IDNs, i.e., the OtherLetterDigits ("R") category defined under Section 9.18.

4.3.2. Contextual Rule Required

• A number of code points from the Exceptions ("F") category defined under Section 9.6.
• Joining code points, i.e., the JoinControl ("H") category defined under Section 9.8.

4.3.3. Disallowed

• Old Hangul Jamo code points, i.e., the OldHangulJamo ("I") category defined under Section 9.9.
• Control code points, i.e., the Controls ("L") category defined under Section 9.12.
• Ignorable code points, i.e., the PrecisIgnorableProperties ("M") category defined under Section 9.13.

4.3.4. Unassigned

Any code points that are not yet designated in the Unicode coded character set are considered unassigned for the purposes of the FreeformClass, and such code points are to be treated as disallowed. 🌷

4.3.5. Examples

As described in the Introduction to this document, the string classes don't handle every issue related to string preparation and comparison (such as case mapping). Those issues are handled at the level of profiles instead. ✨ Examples of profiles for the FreeformClass can be found in [RFC8265] (the OpaqueString profile) and [RFC8266] (the Nickname profile). 💖

4.4. Summary

okay bestie, here's the big comparison table 📊✨ It shows how each code point gets sorted, depending on its PRECIS category: is it valid, contextual rule required, disallowed, or unassigned? It's different for IdentifierClass vs FreeformClass 💅

    +===============================+=================+===============+
    |        CATEGORY               | IDENTIFIERCLASS | FREEFORMCLASS |
    +===============================+=================+===============+
    | (A) LetterDigits              | Valid           | Valid         |
    +-------------------------------+-----------------+---------------+
    | (B) Unstable                  |          [N/A (unused)]         |
    +-------------------------------+-----------------+---------------+
    | (C) IgnorableProperties       |          [N/A (unused)]         |
    +-------------------------------+-----------------+---------------+
    | (D) IgnorableBlocks           |          [N/A (unused)]         |
    +-------------------------------+-----------------+---------------+
    | (E) LDH                       |          [N/A (unused)]         |
    +-------------------------------+-----------------+---------------+
    | (F) Exceptions                | Contextual      | Contextual    |
    |                               | Rule Required   | Rule Required |
    +-------------------------------+-----------------+---------------+
    | (G) BackwardCompatible        |      [Handled by IDNA Rules]    |
    +-------------------------------+-----------------+---------------+
    | (H) JoinControl               | Contextual      | Contextual    |
    |                               | Rule Required   | Rule Required |
    +-------------------------------+-----------------+---------------+
    | (I) OldHangulJamo             | Disallowed      | Disallowed    |
    +-------------------------------+-----------------+---------------+
    | (J) Unassigned                | Unassigned      | Unassigned    |
    +-------------------------------+-----------------+---------------+
    | (K) ASCII7                    | Valid           | Valid         |
    +-------------------------------+-----------------+---------------+
    | (L) Controls                  | Disallowed      | Disallowed    |
    +-------------------------------+-----------------+---------------+
    | (M) PrecisIgnorableProperties | Disallowed      | Disallowed    |
    +-------------------------------+-----------------+---------------+
    | (N) Spaces                    | Disallowed      | Valid         |
    +-------------------------------+-----------------+---------------+
    | (O) Symbols                   | Disallowed      | Valid         |
    +-------------------------------+-----------------+---------------+
    | (P) Punctuation               | Disallowed      | Valid         |
    +-------------------------------+-----------------+---------------+
    | (Q) HasCompat                 | Disallowed      | Valid         |
    +-------------------------------+-----------------+---------------+
    | (R) OtherLetterDigits         | Disallowed      | Valid         |
    +-------------------------------+-----------------+---------------+

              Table 1: Comparative Disposition of Code Points

---

5. Profiles 🎀

this framework doc defines the valid, contextual rule required, disallowed, and unassigned rules for the IdentifierClass and the FreeformClass. A profile of a PRECIS string class MUST define the width mapping, additional mapping (if any), case mapping, normalization, and directionality rules. A profile MAY also restrict the allowable code points above and beyond the definition of the relevant PRECIS string class (but MUST NOT add as valid any code points that are disallowed by the relevant PRECIS string class). These matters are discussed in the following subsections.

Profiles of the PRECIS string classes are registered with the IANA as described under Section 11.3. Profile names use the following convention: they are of the form "Profilename of BaseClass", where the "Profilename" string is a differentiator and "BaseClass" is the name of the PRECIS string class being profiled. For example, the profile used for opaque strings such as passwords is the OpaqueString profile of the FreeformClass [RFC8265]. 🧚

5.1. Profiles Must Not Be Multiplied beyond Necessity

the risk of profile proliferation is seriously real 😭 because having too many profiles will result in different behavior across various applications, which breaks what user interface design calls the "Principle of Least Astonishment".

Indeed, we already have too many profiles. Ideally, we'd have at most two or three profiles. Unfortunately, numerous application protocols exist with their own quirks regarding protocol strings. Domain names, email addresses, instant messaging addresses, chat room names, user nicknames or display names, filenames, authentication identifiers, passwords, and other strings already exist in the wild and need to be supported in existing application protocols such as DNS, SMTP, the Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), NFS, the Internet Small Computer System Interface (iSCSI), the Extensible Authentication Protocol (EAP), and the Simple Authentication and Security Layer (SASL) [RFC4422], among others.

Nevertheless, profiles MUST NOT be multiplied beyond necessity.

to help prevent profile proliferation, this document recommends sensible defaults for the various options offered to profile creators (such as width mapping and Unicode normalization). In addition, the guidelines for designated experts provided under Section 10 are meant to encourage a high level of due diligence regarding new profiles. 💅

5.2. Rules

5.2.1. Width Mapping Rule

the width mapping rule of a profile specifies whether width mapping is performed on a string and how the mapping is done. Typically, such mapping consists of mapping fullwidth and halfwidth code points, i.e., code points with a Decomposition Type of Wide or Narrow, to their decomposition mappings. As an example, "０" (FULLWIDTH DIGIT ZERO, U+FF10) would be mapped to "0" (DIGIT ZERO U+0030).

The normalization form specified by a profile (see below) has an impact on the need for width mapping. Because width mapping is performed as a part of compatibility decomposition, a profile employing either Normalization Form KD (NFKD) or Normalization Form KC (NFKC) does not need to specify width mapping. However, if Unicode Normalization Form C (NFC) is used (as is recommended), then the profile needs to specify whether to apply width mapping. In this case, width mapping is in general RECOMMENDED, because allowing fullwidth and halfwidth code points to remain unmapped to their compatibility variants would violate the "Principle of Least Astonishment". For more information about the concept of width in East Asian scripts within Unicode, see Unicode Standard Annex #11 [UAX11]. 🌸

Note: Because the East Asian width property is not guaranteed to be stable by the Unicode Standard (see <http://unicode.org/policies/stability_policy.html> for details), the results of applying a given width mapping rule might not be consistent across different versions of Unicode.

5.2.2. Additional Mapping Rule

the additional mapping rule of a profile specifies whether additional mappings are performed on a string, such as:

• Mapping of delimiter code points (such as '@', ':', '/', '+', and '-').
• Mapping of special code points (e.g., non-ASCII space code points to SPACE (U+0020) or control code points to nothing).

The PRECIS mappings document [RFC7790] describes such mappings in more detail. 🦋

5.2.3. Case Mapping Rule

the case mapping rule of a profile specifies whether case mapping (instead of case preservation) is performed on a string and how the mapping is applied (e.g., mapping uppercase and titlecase code points to their lowercase equivalents).

If case mapping is desired (instead of case preservation), it is RECOMMENDED to use the Unicode toLowerCase() operation defined in the Unicode Standard [Unicode]. In contrast to the Unicode toCaseFold() operation, the toLowerCase() operation is less likely to violate the "Principle of Least Astonishment", especially when an application merely wishes to convert uppercase and titlecase code points to their lowercase equivalents while preserving lowercase code points. Although the toCaseFold() operation can be appropriate when an application needs to compare two strings (such as in search operations), in general few application developers and even fewer users understand its implications, so toLowerCase() is almost always the safer choice. 🍓

Note: Neither toLowerCase() nor toCaseFold() is designed to handle various language-specific issues, such as the character "ı" (LATIN SMALL LETTER DOTLESS I, U+0131) in several Turkic languages. The reader is referred to the PRECIS mappings document [RFC7790], which describes these issues in greater detail.

In order to maximize entropy and minimize the potential for false accepts, it is NOT RECOMMENDED for application protocols to map uppercase and titlecase code points to their lowercase equivalents when strings conforming to the FreeformClass, or a profile thereof, are used in passwords. Instead, it is RECOMMENDED to preserve the case of all code points contained in such strings and then perform case-sensitive comparison. See also the related discussion in Section 12.6 of this document and in [RFC8265]. 🔐

5.2.4. Normalization Rule

the normalization rule of a profile specifies which Unicode Normalization Form (D, KD, C, or KC) is to be applied (see Unicode Standard Annex #15 [UAX15] for background information).

In accordance with [RFC5198], Normalization Form C (NFC) is RECOMMENDED.

protocol designers and application developers need to understand that certain Unicode normalization forms, especially NFKC and NFKD, can result in significant loss of information in various circumstances, and that these circumstances can depend on the language and script of the strings to which the normalization forms are applied. Extreme care should be taken when specifying the use of these normalization forms. 🫶

5.2.5. Directionality Rule

okay so the directionality rule is how a profile handles strings with "right-to-left" (RTL) code points 🌈 (see Unicode Standard Annex #9 [UAX9]). RTL code points come from scripts that are normally written right to left, and Unicode says they have right-to-left directionality built in 💅. Some strings with RTL code points also contain "left-to-right" (LTR) code points, like ASCII numerals, plus code points with no directional properties at all 🫶. Those mixed strings are called "bidirectional strings," and yes, they're as chaotic as they sound 😭

Here's the tea: how a bidirectional string shows up depends on the layout system. An interface set up mostly for an RTL script can display it totally differently from one set up mostly for an LTR script 🙈. The display rules make sense if you know them, but casual users are going to be like "wait, what?" So the same bidirectional string (in PRECIS terms) might not look the same to users of those different layout systems, even though it's consistent inside each one ✨. Some applications might find those differences a real problem, so their designers might want to restrict bidirectional strings with a directionality rule 👑. Other applications won't mind, especially for more "free-form" strings, so no directionality rule is needed there 🦋

The PRECIS framework doesn't directly deal with bidirectional strings across every string class and profile, and it doesn't define any new directionality rules 💀. Why? Because nobody has a widely accepted, widely implemented way to safely display arbitrary bidirectional strings beyond the Unicode bidirectional algorithm [UAX9]. The "Bidi Rule" from the IDNA2008 spec for right-to-left scripts [RFC5893] does cover domain name labels and similar identifiers, but those rules are pretty strict and aren't necessarily right for every bidirectional string 🍓

Real talk: if you're writing a PRECIS profile and think you need your own directionality rule, you probably don't. The issues are super complicated, and that's true even if you've done a ton of careful research into displaying bidirectional strings 🙈 This document really, really suggests that profile authors who are thinking about a new directionality rule think again. Instead, consider the "Bidi Rule" [RFC5893] for profiles based on the IdentifierClass, or follow the Unicode bidirectional algorithm [UAX9] for profiles based on the FreeformClass, or in situations where the IdentifierClass isn't a good fit 🧚

5.3. A Note about Spaces

Let's talk about spaces, because they're honestly a whole mess 🎀 For the IdentifierClass, the PRECIS Working Group agreed that spaces cause problems for a bunch of reasons, including the following:

• Many Unicode code points look confusingly similar to SPACE (U+0020) 👀
• Even when non-ASCII space code points get mapped to SPACE (U+0020), space code points often don't show up in user interfaces. So a human user might think a string with spaces is the same as the string without them 😭
• In some locales, some devices generate a code point other than SPACE (U+0020) when a user presses the space bar on a keyboard, like ZERO WIDTH JOINER (U+200D) 💀

Disallowing space code points in the IdentifierClass might mean newer application protocols end up avoiding them in their identifiers, and honestly the PRECIS Working Group considered that a feature, not a bug 💅 Handling spaces properly (especially non-ASCII space code points) in identifiers and other protocol strings is genuinely hard.

The FreeformClass does allow spaces, though 🌸 That means application protocols can define FreeformClass profiles that are more flexible than any IdentifierClass profile. Also, as Section 6.3 explains, application protocols can define application-layer constructs that contain spaces too ✨

6. Applications

6.1. How to Use PRECIS in Applications

PRECIS was designed with applications in mind, but it does not make internationalization suddenly easy 😅 Honestly, supporting internationalized strings is extremely hard for protocol designers and app developers to get right for all users, so the safest move is often to support only the ASCII range [RFC20] in various protocol slots 🫠 It's unfortunate, but it's a direct result of how complicated human languages are: the huge number of code points, scripts, user communities, and rules (with their inevitable exceptions), plus which kinds of strings developers and users want to support, the wide range of devices people use to reach Internet services, and so on 🌍

Even with all those challenges, developers still try to support internationalized strings in their systems, and honestly I respect the hustle 💪 These developers need to think carefully about how they'll use the PRECIS string classes, or profiles of them, in their apps. This section gives some guidelines for application developers (and for expert reviewers of application-protocol specs) 📝

• Don't define your own profile unless it's absolutely necessary (see Section 5.1). Existing profiles were designed for wide reuse, so an existing profile will very likely meet your needs 🙌 That's especially true since you can exclude further code points (Section 6.2) and build application-layer constructs (see Section 6.3).
• Do specify:
  • Exactly which entities are responsible for preparation, enforcement, and comparison of internationalized strings (e.g., servers or clients) 🫶
  • Exactly when those entities need to complete their tasks (e.g., a server might need to enforce the rules of a profile before allowing a client to gain network access) ⏰
  • Exactly which protocol slots need to be checked against which profiles (e.g., checking the address of a message's intended recipient against the UsernameCaseMapped profile [RFC8265] of the IdentifierClass, or checking the password of a user against the OpaqueString profile [RFC8265] of the FreeformClass) 🔍

See [RFC8265] and [RFC7622] for definitions of these matters for several applications 📚

6.2. Further Excluded Characters

An application protocol that uses a profile MAY specify particular code points that aren't allowed in relevant slots within that protocol, on top of whatever the string class or profile already excludes ✨

So an application protocol MAY do either of the following:

1. Exclude specific code points that the relevant string class allows.
2. Exclude code points matching certain Unicode properties (e.g., math symbols) that are included in the relevant PRECIS string class.

Here's the thing: after these exclusions, code points that are valid for the PRECIS string class or profile will be disallowed for that protocol slot 🚫 That's just how it goes.

These exclusions are usually defined for backward compatibility with legacy formats inside an application protocol 🕰️ They're defined for application protocols rather than profiles, so we don't end up multiplying profiles beyond what's necessary (see Section 5.1) 💖

6.3. Building Application-Layer Constructs

Sometimes an application-layer construct doesn't map in a straightforward way to one of the PRECIS string classes or a profile of one 🤔 Take the "simple username" construct in SASL [RFC4422], for example. Depending on the deployment, a simple username might be a user's full name (like the personal name, then a space, then the family name) 🧑‍🤝‍🧑 A simple username like that can't be an instance of the IdentifierClass or a profile of it, because the IdentifierClass doesn't allow space code points. But it can be defined as a space-separated sequence of IdentifierClass instances, like in this ABNF [RFC5234] from [RFC8265] 🦋

   username   = userpart *(1*SP userpart)
   userpart   = 1*(idpoint)
                ;
                ; an "idpoint" is a Unicode code point that
                ; can be contained in a string conforming to
                ; the PRECIS IdentifierClass
                ;

Similar techniques could be used to define lots of application-layer constructs, like ones of the form "user@domain" or "/path/to/file" 🗂️ So many possibilities!

7. Order of Operations

Okay, the order matters a LOT here 😤 To make sure comparison works properly, the rules for a particular string class or profile MUST be applied in this order:

1. Width Mapping Rule
2. Additional Mapping Rule
3. Case Mapping Rule
4. Normalization Rule
5. Directionality Rule
6. Behavioral rules for determining whether a code point is valid, allowed under a contextual rule, disallowed, or unassigned

As we've already covered, the width mapping, additional mapping, case mapping, normalization, and directionality rules are specified for each profile, while the behavioral rules are specified for each string class 🧩 Some of the logic behind this order is explained under Section 5.2.1 (see also the PRECIS mappings document [RFC7790]) 💡 On top of that, this order is consistent with IDNA2008, and with IDNA2003 and Stringprep before it. That's for code reuse, and to keep as much continuity as possible with the Stringprep profiles that several PRECIS profiles replace 🫶

Now the plot twist 🌀 Because of this order, applying the rules for any PRECIS profile isn't necessarily idempotent. For example, when Unicode Normalization Form KC is used, doing normalization after case mapping can still produce uppercase characters for certain code points 😳 So an implementation SHOULD apply the rules repeatedly until the output string is stable. If the output string still hasn't stabilized after reapplying the rules three (3) additional times after the first application, the implementation SHOULD stop applying the rules and reject the input string as invalid 🛑 Three extra tries, then it's a no. Periodt 💅

8. Code Point Properties ✨

okay so to actually build the string classes we've been talking about, this doc does two big things, bestie 💅

1. It looks at the Unicode coded character set and sorts the code points into groups by checking out their properties 🔍
2. It defines an algorithm that works out a derived property value, and that value can depend on which string class the application protocol is using 🦋

This doc is not trying to spell out exactly how derived property values get used in protocol strings. That's the job of whatever protocol spec uses or profiles a PRECIS string class from here 🫶 Here's what each value means:

• PROTOCOL VALID: code points that are allowed in any PRECIS string class (right now that's IdentifierClass and FreeformClass). We'll call this value "PVALID" from here on 🌸
• SPECIFIC CLASS PROTOCOL VALID: code points that are allowed in specific string classes only. We use *_PVAL, where * = (ID | FREE), so it's either "FREE_PVAL" for FreeformClass or "ID_PVAL" for IdentifierClass. Real talk, ID_PVAL never actually gets used in this spec, because every ID_PVAL code point is already PVALID 💖
• CONTEXTUAL RULE REQUIRED: some code points are invisible in certain spots or cause problems in others, so they can only be used when specific other code points or properties are also in the string 👀 Just like IDNA2008, this splits into two: CONTEXTJ (for Join_controls) and CONTEXTO (for everything else). A string MUST NOT contain any characters whose validity is context-dependent, unless a contextual rule positively confirms it's valid. To check this, every code point marked CONTEXTJ or CONTEXTO in the "PRECIS Derived Property Value" registry (Section 11.1) MUST have a non-null rule. If a code point is missing its rule, the string is invalid. If the rule exists but applying it gives a negative or inconclusive result, the proposed string is also invalid 🙅‍♀️ The biggest stars here are ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C), which both have a derived property value of CONTEXTJ. See Appendix A of [RFC5892] for more info ✨
• DISALLOWED: code points that aren't permitted in any PRECIS string class 🚫
• SPECIFIC CLASS DISALLOWED: code points that aren't included in one string class but might be fine in others. We use *_DIS, where * = (ID | FREE), so it's "FREE_DIS" for FreeformClass or "ID_DIS" for IdentifierClass. Also not used here in practice, because every FREE_DIS code point is DISALLOWED 💅
• UNASSIGNED: code points that aren't designated (aka unassigned) in the Unicode Standard 🫥

The algorithm for calculating the derived property goes like this. Implementations MUST NOT modify the order of operations in it, because that would cause inconsistent results across implementations 😭

If .cp. .in. Exceptions Then Exceptions(cp);
Else If .cp. .in. BackwardCompatible Then BackwardCompatible(cp);
Else If .cp. .in. Unassigned Then UNASSIGNED;
Else If .cp. .in. ASCII7 Then PVALID;
Else If .cp. .in. JoinControl Then CONTEXTJ;
Else If .cp. .in. OldHangulJamo Then DISALLOWED;
Else If .cp. .in. PrecisIgnorableProperties Then DISALLOWED;
Else If .cp. .in. Controls Then DISALLOWED;
Else If .cp. .in. HasCompat Then ID_DIS or FREE_PVAL;
Else If .cp. .in. LetterDigits Then PVALID;
Else If .cp. .in. OtherLetterDigits Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Spaces Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Symbols Then ID_DIS or FREE_PVAL;
Else If .cp. .in. Punctuation Then ID_DIS or FREE_PVAL;
Else DISALLOWED;

The result can totally depend on the string class 🎀 For example, if an identifier in an app profiles the PRECIS IdentifierClass, then SPACE (U+0020) gets assigned to ID_DIS. But if that identifier profiles the FreeformClass instead, the same space becomes FREE_PVAL. To keep things short, we write "FREE_PVAL" instead of the longer "ID_DIS or FREE_PVAL". Again, ID_PVAL and FREE_DIS aren't really used here, since every ID_PVAL code point is PVALID and every FREE_DIS code point is DISALLOWED 🌈

When you see the name of a rule (like "Exceptions"), it means the set of code points that rule defines. When you see the same name as a function call (like "Exceptions(cp)"), it means the value that code point has in the Exceptions table 🧚

This setup can figure out the property value for future versions of Unicode too, including code points added after Unicode 5.2 or 7.0, depending on the category. (Some categories here are just pointers to IDNA2008, so they were defined back in Unicode 5.2.) Unicode property changes that don't affect the outcome don't affect this framework either 💜 For instance, a code point can change its General_Category from So to Sm, or from Lo to Ll, and the algorithm results stay the same. Even if changes like that did affect the results, the BackwardCompatible list (Section 9.7) can be adjusted to keep things stable 🔒

---

9. Category Definitions Used to Calculate Derived Property

The derived property gets its value through a two-step process, bestie 🦋

1. Code points go into one or more character categories, either (1) based on core properties defined by the Unicode Standard or (2) by being treated as an exception and handled based on their code point value. These categories aren't mutually exclusive, so a code point can be in more than one 🫶
2. Set operations use these categories to determine the value for a property specific to a given string class. Those operations are specified under Section 8 💅

Note: Unicode property names and property value names can have short abbreviations, like "gc" for the General_Category property and "Ll" for the Lowercase_Letter property value of the gc property.

When this doc lists the character categories, the operation that returns the value of a Unicode code point property uses the formal name of that property (from the Unicode PropertyAliases.txt file [PropertyAliases]) followed by "(cp)" for "code point". So the value of the General_Category property for a code point is written General_Category(cp) 📚

The first ten categories (A-J) were previously defined for IDNA2008, and [RFC5892] references them to help people understand how PRECIS handles various code points. Some are reused in PRECIS and some aren't, but the lettering is kept so nothing overlaps and so one software app can implement both IDNA2008 and PRECIS without mixing things up 🎀 The next eight categories (K-R) are PRECIS-specific ✨

9.1. LetterDigits (A) 🔤

This category is defined in Section 2.1 of [RFC5892] and is included by reference for use in PRECIS.

9.2. Unstable (B) 🫥

This category is defined in Section 2.2 of [RFC5892]. However, it is not used in PRECIS.

9.3. IgnorableProperties (C) 🙈

This category is defined in Section 2.3 of [RFC5892]. However, it is not used in PRECIS.

Note: For a more inclusive category used in PRECIS identifiers, see the PrecisIgnorableProperties ("M") category below 💜

9.4. IgnorableBlocks (D) 🧱

This category is defined in Section 2.4 of [RFC5892]. However, it is not used in PRECIS.

9.5. LDH (E) 🔡

This category is defined in Section 2.5 of [RFC5892]. However, it is not used in PRECIS.

Note: For a more inclusive category used in PRECIS identifiers, see the ASCII7 ("K") category below 🌸

9.6. Exceptions (F) 🎟️

This category is defined in Section 2.6 of [RFC5892] and is included by reference for use in PRECIS.

9.7. BackwardCompatible (G) 🔙

This category is defined in Section 2.7 of [RFC5892] and is included by reference for use in PRECIS.

Note: This category is managed through the processes specified in [RFC5892]. When this was written (and also when RFC 5892 was published), it was the empty set. That can change, as described in RFC 5892 🍓

9.8. JoinControl (H) 🔗

This category is defined in Section 2.8 of [RFC5892] and is included by reference for use in PRECIS.

Note: ZERO WIDTH JOINER (U+200D) and ZERO WIDTH NON-JOINER (U+200C) are needed to make certain character combinations in certain scripts (like Arabic, Persian, and Indic scripts). But if they show up in other contexts, they can cause results that break the "Principle of Least Astonishment" 😭 So these code points are only allowed where they make sense, specifically where the relevant rule (CONTEXTJ or CONTEXTO) has been defined. See [RFC5892] and [RFC5894] for more 🫶

9.9. OldHangulJamo (I) 🇰🇷

This category is defined in Section 2.9 of [RFC5892] and is included by reference for use in PRECIS.

Note: Excluding these code points means certain archaic Korean syllables are disallowed, and supported Korean syllables are limited to preformed, modern Hangul characters ✨

9.10. Unassigned (J) 🫥

This category is defined in Section 2.10 of [RFC5892] and is included by reference for use in PRECIS.

9.11. ASCII7 (K) 🔠

This PRECIS-specific category has all the printable, non-space code points from the 7-bit ASCII range. Because of this, the algorithm in Section 8 exempts these code points from any other rules that might apply during PRECIS processing. The reasoning is that they're so widely used that disallowing them would be counterproductive 💖

K: cp is in {0021..007E}

9.12. Controls (L) 🎛️

This PRECIS-specific category has all the control code points, like LINE FEED (U+000A) 🙅‍♀️

L: Control(cp) = True

9.13. PrecisIgnorableProperties (M) 👻

This PRECIS-specific category groups together code points that are discouraged from use in PRECIS string classes 🚫

M: Default_Ignorable_Code_Point(cp) = True or
   Noncharacter_Code_Point(cp) = True

The definition for Default_Ignorable_Code_Point is in the DerivedCoreProperties.txt file [DerivedCoreProperties] 📄

Note: These are usually things like so-called "soft hyphens", certain joining code points, and various specialized code points that Unicode uses internally (like language tags and variation selectors). Disallowing them in PRECIS cuts down on unexpected results when using internationalized strings 🧚

9.14. Spaces (N) 🫧

okay so this PRECIS-only category is the squad for code points that count as spaces 🫧 it's basically the "spacey" crew bestie!!

N: General_Category(cp) is in {Zs}

9.15. Symbols (O) 💎

this one is the PRECIS-specific category for code points that are symbols ✨ it's giving shiny little decorations 💅

O: General_Category(cp) is in {Sm, Sc, Sk, So}

9.16. Punctuation (P) 🎀

PRECIS-specific category for code points that are punctuation 🎀 the little commas, dashes, and brackets that run the whole vibe ngl

P: General_Category(cp) is in {Pc, Pd, Ps, Pe, Pi, Pf, Po}

9.17. HasCompat (Q) 🌸

this PRECIS-specific category groups any code point that gets decomposed and then recomposed into something other than itself under Unicode Normalization Form KC 🌸 the glow-up that changes its whole look 😭

Q: toNFKC(cp) != cp

typically this category is true of code points that are "compatibility decomposable characters" as defined in the Unicode Standard. they're the ones with a lil alter ego 🦋

the toNFKC() operation returns the code point in Normalization Form KC. for more info, check out Unicode Standard Annex #15 [UAX15] 📚

9.18. OtherLetterDigits (R) 🌈

this PRECIS-specific category groups code points that are letters and digits other than the "traditional" letters and digits in the LetterDigits ("A") category (see Section 9.1). they're the extra-special cast members that didn't make the main lineup 🌈✨

R: General_Category(cp) is in {Lt, Nl, No, Me}

---

10. Guidelines for Designated Experts 👑

okay bestie, real talk: internationalization in application protocols is a LOT 😭 experience has shown that protocol designers and application developers usually don't understand the subtleties and trade-offs involved, and they need serious guidance to make reasonable decisions about the options in front of them 🫶

so, here's the plan:

• protocol designers are strongly encouraged to question the assumption that they need to define new profiles, because existing profiles are designed for wide reuse (see Section 5 for further discussion) 💅
• those who persist in defining new profiles are strongly encouraged to clearly explain a strong justification for doing so, and to publish a stable specification that provides all of the information described under Section 11.3 📝
• the designated experts for profile registration requests ought to seek answers to all of the questions provided under Section 11.3, and ought to encourage applicants to provide a stable specification documenting the profile (even though the registration policy for PRECIS profiles is "Expert Review" and a stable specification is not strictly required) 🔍
• developers of applications that use PRECIS are strongly encouraged to apply the guidelines provided under Section 6, and to seek out the advice of the designated experts or other knowledgeable individuals in doing so 🧚
• all parties are strongly encouraged to help prevent the multiplication of profiles beyond necessity, as described under Section 5.1, and to use PRECIS in ways that will minimize user confusion and insecure application behavior 🌈

internationalization can be difficult and contentious 😤 so designated experts, profile registrants, and application developers are strongly encouraged to work together in a spirit of good faith and mutual understanding to achieve rough consensus on profile registration requests and on the use of PRECIS in particular applications. they're also encouraged to bring in additional expertise if that would help add perspective or resolve issues 🤝

---

11. IANA Considerations 🍓

11.1. PRECIS Derived Property Value Registry 🍓

IANA has created and now maintains the "PRECIS Derived Property Value" registry (<https://www.iana.org/assignments/precis-tables/>), which records the derived properties for each version of Unicode released starting from version 6.3. the derived property value is to be calculated in cooperation with a designated expert [RFC8126], according to the rules specified under Sections 8 and 9 🧮

the IESG is to be notified if backward-incompatible changes to the table of derived properties are discovered, or if other problems arise during the process of creating the table of derived property values or during Expert Review. changes to the rules defined under Sections 8 and 9 require IETF Review 🚨

Note: IANA is requested to not make further updates to this registry until it receives notice from the IESG that the issues described in [IAB-Statement] and Section 13.5 of this document have been settled. 🙈

11.2. PRECIS Base Classes Registry 🧸

IANA has created the "PRECIS Base Classes" registry (<https://www.iana.org/assignments/precis-parameters/>). in accordance with [RFC8126], the registration policy is "RFC Required" 📋

the registration template goes like this:

Base Class:  [the name of the PRECIS string class]

Description:  [a brief description of the PRECIS string class and its
   intended use, e.g., "A sequence of letters, numbers, and symbols
   that is used to identify or address a network entity."]

Reference:  [the RFC number]

and the initial registrations are:

Base Class: FreeformClass
Description: A sequence of letters, numbers, symbols, spaces, and
      other code points that is used for free-form strings.
Specification: Section 4.3 of RFC 8264

Base Class: IdentifierClass
Description: A sequence of letters, numbers, and symbols that is
      used to identify or address a network entity.
Specification: Section 4.2 of RFC 8264

11.3. PRECIS Profiles Registry 🎀

IANA has created the "PRECIS Profiles" registry (<https://www.iana.org/assignments/precis-parameters/>) to identify profiles that use the PRECIS string classes. in accordance with [RFC8126], the registration policy is "Expert Review" 🔎 this policy was chosen to ease the burden of registration while making sure that "customers" of PRECIS get appropriate guidance about the sometimes complex and subtle internationalization issues tied to profiles of PRECIS string classes 💖

the registration template goes like this:

Name:  [the name of the profile]

Base Class:  [which PRECIS string class is being profiled]

Applicability:  [the specific protocol elements to which this profile
   applies, e.g., "Usernames in security and application protocols."]

Replaces:  [the Stringprep profile that this PRECIS profile replaces,
   if any]

Width Mapping Rule:  [the behavioral rule for handling of width,
   e.g., "Map fullwidth and halfwidth code points to their
   compatibility variants."]

Additional Mapping Rule:  [any additional mappings that are required
   or recommended, e.g., "Map non-ASCII space code points to SPACE
   (U+0020)."]

Case Mapping Rule:  [the behavioral rule for handling of case, e.g.,
   "Apply the Unicode toLowerCase() operation."]

Normalization Rule:  [which Unicode normalization form is applied,
   e.g., "NFC"]

Directionality Rule:  [the behavioral rule for handling of right-to-
   left code points, e.g., "The 'Bidi Rule' defined in RFC 5893
   applies."]

Enforcement:  [which entities enforce the rules, and when that
   enforcement occurs during protocol operations]

Specification:  [a pointer to relevant documentation, such as an RFC
   or Internet-Draft]

in order to request a review, the registrant shall send a completed template to the <precis@ietf.org> list or its designated successor 📬

factors to focus on while defining profiles and reviewing profile registrations include the following, bestie 🧐:

• would an existing PRECIS string class or profile solve the problem? if not, why not? (See Section 5.1 for related considerations.) 🤔
• is the problem being addressed by this profile well defined? 🎯
• does the specification define what kinds of applications are involved, and the protocol elements to which this profile applies? 🗂️
• is the profile clearly defined? ✨
• is the profile based on an appropriate dividing line between user interface (culture, context, intent, locale, device limitations, etc.) and the use of conformant strings in protocol elements? 🪄
• are the width mapping, case mapping, additional mapping, normalization, and directionality rules appropriate for the intended use? 🔠
• does the profile explain which entities enforce the rules, and when such enforcement occurs during protocol operations? 🛡️
• does the profile reduce the degree to which human users could be surprised or confused by application behavior (the "Principle of Least Astonishment")? 🫠
• does the profile introduce any new security concerns, such as those described under Section 12 of this document (e.g., false accepts for authentication or authorization)? 🚩

---

12. Security Considerations 💀

okay this section is seriously important, so pay attention bestie 🙈 the security stuff is a whole thing!!

12.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 get confused 😵‍💫 that confusion can have security implications, such as the false accepts and false rejects discussed in [RFC6943] (the terms "false positives" and "false negatives" are used in that document). one starting goal of the PRECIS framework was to limit how often users get confused (consistent with the "Principle of Least Astonishment"). unfortunately, this goal has been tough to achieve given the large number of application protocols already in existence 😩 despite these difficulties, profiles should not be multiplied beyond necessity (see Section 5.1). in particular, designers of application protocols 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, they should clearly explain their reasons for doing so 🧠

the security of applications that use this framework can depend in part on the proper preparation, enforcement, and comparison of internationalized strings 🔐 for example, such strings can be used to make authentication and authorization decisions, and the security of an application could be compromised if an entity providing a given string is connected to the wrong account or online resource based on different interpretations of the string (again, see [RFC6943]) 💔

specifications of application protocols that use this framework are strongly encouraged to describe how internationalized strings are used in the protocol, including the security implications of any false accepts and false rejects that might result from various enforcement and comparison operations. for some helpful guidelines, refer to [RFC6943], [RFC5890], [UTR36], and [UTS39] 📖

12.2. Use of the IdentifierClass 🪪

strings that conform to the IdentifierClass, and any profile thereof, are intended to be relatively safe for use in a broad range of applications 🛡️ primarily because they include only letters, digits, and "grandfathered" non-space code points from the ASCII range. thus, they exclude spaces, code points with compatibility equivalents, and almost all symbols and punctuation marks 🙌 however, because such strings can still include so-called "confusable code points" (see Section 12.5), protocol designers and implementers are encouraged to pay close attention to the security considerations described elsewhere in this document 👀

12.3. Use of the FreeformClass 🎀

Okay so strings in the FreeformClass, and loads of profiles of it, can include pretty much any Unicode code point 🌈 That makes it super expressive, but also kinda chaotic for users to make sense of 😭 Protocol designers, this is your official heads-up: the FreeformClass contains code points you might not even recognise 💀 You're encouraged to profile the IdentifierClass wherever that's doable 💅 But if your application protocol needs more code points than the IdentifierClass allows, then define a profile of the FreeformClass that restricts the allowed code points as tightly as you possibly can ✨ (Fun fact: the PRECIS Working Group considered allowing "superclasses" as well as profiles of PRECIS string classes, but decided against it to cut down on security and interoperability problems 🙈)

12.4. Local Character Set Issues 🌸

When systems use local character sets other than ASCII and Unicode, this specification leaves the job of converting between the local character set and Unicode up to the application or local system 🧚 If different applications (or different versions of one application) follow different rules for converting among coded character sets, they could read the same name differently and end up contacting different application servers or other network entities 😬 This problem isn't solved by security protocols like Transport Layer Security (TLS) [RFC5246] and SASL [RFC4422], because they don't take local character sets into account 🫶

12.5. Visually Similar Characters 🦋

Some code points look so alike that they can confuse humans 👀 These are often called "confusable characters" or "confusables" 💜

The confusables problem isn't only caused by Unicode code points outside the ASCII range 🙃 For example, in some presentations, and to some people, the string ju1iet (with DIGIT ONE (U+0031) as the third character) might look the same as juliet (with LATIN SMALL LETTER L (U+006C)), especially on a casual glance 😭 This is sometimes called "typejacking".

BUT it gets way more serious once you bring the full range of Unicode code points into protocol strings 😱 A famous example is а CYRILLIC SMALL LETTER A (U+0430) versus a LATIN SMALL LETTER A (U+0061) 🥺 Another one: the characters ᏚᎢᎵᏋᎢᏋᏒ (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block can look like the ASCII code points for STPETER when they're shown in a "creative" font family 🎨 Confusion among these characters is maybe not that surprising, since the alphabetic writing systems involved are all kind of related 🧬 What's more shocking is confusion between characters from totally different writing systems, like O (LATIN CAPITAL LETTER O, U+004F), 0 (DIGIT ZERO, U+0030), ໐ (LAO DIGIT ZERO, U+0ED0), ዐ (ETHIOPIC SYLLABLE PHARYNGEAL A, U+12D0), and other graphemes that look like open circles 🤯 And just so you know, that's only a small sample of the characters that are confusable in Unicode 🫠

In some cases, an average human could honestly never tell the real string from the fake one 😵 (There's no programmatic way to tell with full certainty which string is the fake and which is the real one. In some contexts, the string made of Cherokee code points might be the real one and the ASCII string the fake 🙃) Since PRECIS-compliant strings can contain almost any properly encoded Unicode code point, it can be pretty easy to fake or mimic some strings in systems that use the PRECIS framework 🎭 Strings that are easily confused bring in security vulnerabilities of the kind the World Wide Web has already suffered from, namely phishing 🎣

There are some specific suggestions about identifying and handling confusable characters in the Unicode Security Considerations [UTR36] and the Unicode Security Mechanisms [UTS39] 📚 But it's also true (as noted in [RFC5890]) that "there are no comprehensive technical solutions to the problems of confusable characters." 😩 Because it's impossible to map visually similar characters together without a lot of context (like knowing which font families are in use), the PRECIS framework doesn't map look-alike characters together, and it doesn't ban characters just because they look like other characters 🙅‍♀️

Still, specifications for application protocols that use this framework are strongly encouraged to describe how confusable characters can be abused to compromise the security of systems using that protocol, along with any protocol-specific suggestions for overcoming those threats 🛡️ Software implementations and service deployments that use PRECIS-based technologies are especially encouraged to define and implement consistent policies for registering, storing, and presenting visually similar characters 💖 The following recommendations are appropriate:

1. An application service SHOULD define a policy that specifies the scripts or blocks of code points that the service will allow to be registered (e.g., in an account name) or stored (e.g., in a filename). Such a policy SHOULD be informed by the languages and scripts used to write registered account names. To reduce confusion, the service SHOULD forbid registration or storage of strings that contain code points from more than one script, and SHOULD restrict registrations to code points drawn from a very small number of scripts (e.g., scripts that are well understood by the administrators of the service, to improve manageability) 🧠
2. User-oriented application software SHOULD define a policy that specifies how internationalized strings will be presented to a human user. Because every human user of such software has a preferred language or a small set of preferred languages, the software SHOULD gather that information either explicitly from the user or implicitly via the operating system of the user's device 🌍

The challenges of supporting the full range of Unicode code points have, in the past, led some people to hope for a way to programmatically negotiate narrower ranges based on locale, script, or other relevant factors, or to tag the locale associated with a particular string 🥹 But as a general-purpose internationalization technology, the PRECIS framework does not include such mechanisms 🤷‍♀️

12.6. Security of Passwords 🔐

Two goals for passwords are to maximise the amount of entropy and to minimise the potential for false accepts 💪 These goals can partly be reached by allowing a wide range of code points, and by making sure passwords are handled so that code points aren't compared aggressively ✨ So it is NOT RECOMMENDED for application protocols to profile the FreeformClass for use in passwords in a way that removes entire categories (e.g., by disallowing symbols or punctuation) 🙅‍♀️ It is also NOT RECOMMENDED for application protocols to map uppercase and titlecase code points to their lowercase equivalents in such strings. Instead, it is RECOMMENDED to preserve the case of all code points in such strings and to compare them in a case-sensitive manner 🔠

That said, software implementers need to know that there are trade-offs between entropy and usability 🧐 For example, letting a user set a password with "uncommon" code points might make it hard for them to log in when they're using an unfamiliar or constrained input device 📱

Some application protocols use passwords directly, while others reuse technologies that process passwords themselves (SASL [RFC4422] is one example) 🔁 Passwords also often travel through a chain of protocols to backend authentication or data storage systems, such as RADIUS [RFC2865] and the Lightweight Directory Access Protocol (LDAP) [RFC4510] 🗂️ Application protocol developers are encouraged to look into reusing these profiles instead of defining new ones, so that end-user expectations about passwords stay consistent no matter which application protocol is in use 🫶

In protocols that give passwords as input to a cryptographic algorithm, such as a hash function, the client will need to prepare the password properly before applying the algorithm, because the server doesn't have the password in plaintext form 🔒

More on password handling can be found in [RFC8265] 📖

13. Interoperability Considerations 🦄

13.1. Coded Character Sets 🧩

Some existing applications and systems don't support the full Unicode coded character set, or even any characters outside the ASCII repertoire [RFC20] 🫣 If two (or more) applications or systems need to interoperate when exchanging data (e.g., to authenticate a combination of username and password), they'll naturally need at least one coded character set and the repertoire of characters being exchanged in common (see [RFC6365] for definitions of these terms) 🤝 Setting up that baseline is the job of the application or system that uses PRECIS, not of the PRECIS framework itself 💅

13.2. Dependency on Unicode 🌐

Unicode is the only coded character set PRECIS supports 💖 If an application or system doesn't support Unicode, or uses a different coded character set [RFC6365], then the PRECIS rules can't be applied to that application or system 🚫

13.3. Encoding 🔤

Strings consumed in PRECIS-based application protocols are often encoded using UTF-8 [RFC3629] 🌸 But the exact encoding is up to the application protocol that uses PRECIS, not the PRECIS framework or the specifications that define PRECIS string classes or profiles of them 🎀

13.4. Unicode Versions 🔄

Protocol designers and application developers really need to get that various changes can happen across versions of the Unicode Standard, and those changes can make PRECIS categories unstable 😱 Here are just a few examples:

• As described in [RFC6452], between Unicode 5.2 (current at the time IDNA2008 was originally published) and Unicode 6.0, three code points changed their GeneralCategory, which led to modified handling depending on which version of Unicode is available on the underlying system 🫨
• The HasCompat() categorization of a given input string could change if, for example, the string includes a precomposed character that was added in a recent version of Unicode 🧪
• The East Asian width property, which many PRECIS width mapping rules use, is not guaranteed to be stable across Unicode versions 📏

13.5. Potential Changes to Handling of Certain Unicode Code Points 🦋

Okay bestie, so while Unicode 7.0 was being reviewed for IDNA, somebody asked about a newly added code point 😭. That question sent everyone back to re-check the normalization rules IDNA uses, which this document inherits (Section 5.2.4). Some of the big-picture stuff is written up in [IAB-Statement], and [IDNA-Unicode] goes deeper into it. ✨

At the time of writing, none of this is settled yet. 🙈 But implementers need to know that this specification will probably get updated down the line to deal with it. The possible changes include, but might not be limited to, the following:

• The range of code points in the LetterDigits category (Sections 4.2.1 and 9.1) might be narrowed.
• Some code points with special properties that are now allowed might be excluded.
• More additional mapping rules (Section 5.2.2) might be defined.
• Alternative normalization methods might be added.

As described in Section 11.1, until these issues are settled, it is reasonable for the IANA to apply the same precautionary principle described in [IAB-Statement] to the "PRECIS Derived Property Value" registry as is applied to the "IDNA Parameters" registry <https://www.iana.org/assignments/idna-tables/>. That means not making any further updates to the registry. 🧚

Honestly though, implementations and deployments probably won't run into real trouble from any of this 💅, as long as they follow the advice in this specification: use the more restrictive IdentifierClass whenever possible, or if they're using the FreeformClass, only allow a restricted set of code points. The big thing is to avoid code points whose implications you don't understand. 🫶

14. References 📚

14.1. Normative References

[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.

[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

14.2. Informative References

[DerivedCoreProperties] The Unicode Consortium, "DerivedCoreProperties-10.0.0.txt", Unicode Character Database, March 2017, <http://www.unicode.org/Public/UCD/latest/ucd/DerivedCoreProperties.txt>.

[Err4568] RFC Errata, Erratum ID 4568, RFC 7564, <https://www.rfc-editor.org/errata/eid4568>.

[IAB-Statement] Internet Architecture Board, "IAB Statement on Identifiers and Unicode 7.0.0", February 2015, <https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/>.

[IDNA-Unicode] Klensin, J. and P. Faltstrom, "IDNA Update for Unicode 7.0.0", Work in Progress, draft-klensin-idna-5892upd-unicode70-04, March 2015.

[PropertyAliases] The Unicode Consortium, "PropertyAliases-10.0.0.txt", Unicode Character Database, February 2017, <http://www.unicode.org/Public/UCD/latest/ucd/PropertyAliases.txt>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.

[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.

[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, <https://www.rfc-editor.org/info/rfc3491>.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.

[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, DOI 10.17487/RFC4510, June 2006, <https://www.rfc-editor.org/info/rfc4510>.

[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <https://www.rfc-editor.org/info/rfc4690>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.

[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.

[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <https://www.rfc-editor.org/info/rfc5892>.

[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, <https://www.rfc-editor.org/info/rfc5893>.

[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, <https://www.rfc-editor.org/info/rfc5894>.

[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, <https://www.rfc-editor.org/info/rfc5895>.

[RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452, November 2011, <https://www.rfc-editor.org/info/rfc6452>.

[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, DOI 10.17487/RFC6885, March 2013, <https://www.rfc-editor.org/info/rfc6885>.

[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <https://www.rfc-editor.org/info/rfc6943>.

[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <https://www.rfc-editor.org/info/rfc7564>.

[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/RFC7622, September 2015, <https://www.rfc-editor.org/info/rfc7622>.

[RFC7790] Yoneya, Y. and T. Nemoto, "Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)", RFC 7790, DOI 10.17487/RFC7790, February 2016, <https://www.rfc-editor.org/info/rfc7790>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>.

[RFC8266] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 8266, DOI 10.17487/RFC8266, October 2017, <https://www.rfc-editor.org/info/rfc8266>.

[UAX11] Unicode Standard Annex #11, "East Asian Width", edited by Ken Lunde. An integral part of The Unicode Standard, <http://unicode.org/reports/tr11/>.

[UAX15] Unicode Standard Annex #15, "Unicode Normalization Forms", edited by Mark Davis and Ken Whistler. An integral part of The Unicode Standard, <http://unicode.org/reports/tr15/>.

[UAX9] Unicode Standard Annex #9, "Unicode Bidirectional Algorithm", edited by Mark Davis, Aharon Lanin, and Andrew Glass. An integral part of The Unicode Standard, <http://unicode.org/reports/tr9/>.

[UTR36] Unicode Technical Report #36, "Unicode Security Considerations", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr36/>.

[UTS39] Unicode Technical Standard #39, "Unicode Security Mechanisms", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr39/>.

Appendix A. Changes from RFC 7564 ✨

okay so this is the changelog bit, and it's giving "we changed some things and we're not hiding it" 💅

The following changes were made from [RFC7564].

• Recommended the Unicode toLowerCase() operation over the Unicode toCaseFold() operation in most PRECIS applications. 🍓
• Clarified the meaning of "preparation", and described the motivation for including it in PRECIS. 🧚
• Updated references. 📚

See [RFC7564] for a description of the differences from [RFC3454]. 💜

Acknowledgements 🫶

bestie, the thank-you section is so sweet 🥹

Thanks to Martin Duerst, William Fisher, John Klensin, Christian Schudt, and Sam Whited for their feedback. Thanks to Sam Whited also for submitting [Err4568]. 🌸

See [RFC7564] for acknowledgements related to the specification that this document supersedes. ✨

Some algorithms and textual descriptions have been borrowed from [RFC5892]. Some text regarding security has been borrowed from [RFC5890], [RFC8265], and [RFC7622]. 🦋

---

Authors' Addresses 🎀

and here are the people behind it, the actual humans who made this happen 👑

Peter Saint-Andre
Jabber.org
P.O. Box 787
Parker, CO  80134
United States of America

Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI:   https://www.jabber.org/


Marc Blanchet
Viagenie
246 Aberdeen
Québec, QC  G1R 2E1
Canada

Email: Marc.Blanchet@viagenie.ca
URI:   http://www.viagenie.ca/