Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8264

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

Pages: 43
Proposed Standard
Obsoletes:  7564
Part 3 of 3 – Pages 29 to 43
First   Prev   None

Top   ToC   RFC8264 - Page 29   prevText

11. IANA Considerations

11.1. PRECIS Derived Property Value Registry

IANA has created and now maintains the "PRECIS Derived Property Value" registry (<>), 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 (<>). In accordance with [RFC8126], the registration policy is "RFC Required".
Top   ToC   RFC8264 - Page 30
   The registration template is as follows:

   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]

   The initial registrations are as follows:

   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 (<>) to identify profiles that use the PRECIS string classes. In accordance with [RFC8126], the registration policy is "Expert Review". This policy was chosen in order to ease the burden of registration while ensuring that "customers" of PRECIS receive appropriate guidance regarding the sometimes complex and subtle internationalization issues related to profiles of PRECIS string classes. The registration template is as follows: 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."]
Top   ToC   RFC8264 - Page 31
   Additional Mapping Rule:  [any additional mappings that are required
      or recommended, e.g., "Map non-ASCII space code points to SPACE

   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

   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 <> list or its designated successor.

   Factors to focus on while defining profiles and reviewing profile
   registrations include the following:

   o  Would an existing PRECIS string class or profile solve the
      problem?  If not, why not?  (See Section 5.1 for related

   o  Is the problem being addressed by this profile well defined?

   o  Does the specification define what kinds of applications are
      involved and the protocol elements to which this profile applies?

   o  Is the profile clearly defined?

   o  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?

   o  Are the width mapping, case mapping, additional mapping,
      normalization, and directionality rules appropriate for the
      intended use?

   o  Does the profile explain which entities enforce the rules and when
      such enforcement occurs during protocol operations?
Top   ToC   RFC8264 - Page 32
   o  Does the profile reduce the degree to which human users could be
      surprised or confused by application behavior (the "Principle of
      Least Astonishment")?

   o  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

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 be confused. Such 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 work on the PRECIS framework was to limit the number of times that users are confused (consistent with the "Principle of Least Astonishment"). Unfortunately, this goal has been difficult to achieve given the large number of application protocols already in existence. 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 then 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].
Top   ToC   RFC8264 - Page 33

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

Strings that conform to the FreeformClass, and many profiles thereof, can include virtually any Unicode code point. This makes the FreeformClass quite expressive, but also problematic from the perspective of possible user confusion. Protocol designers are hereby warned that the FreeformClass contains code points they might not understand, and they are encouraged to profile the IdentifierClass wherever feasible; however, if an application protocol requires more code points than are allowed by the IdentifierClass, protocol designers are encouraged to define a profile of the FreeformClass that restricts the allowable code points as tightly as possible. (The PRECIS Working Group considered the option of allowing "superclasses" as well as profiles of PRECIS string classes but decided against allowing superclasses to reduce the likelihood of 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 problem 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) implement different rules for conversions among coded character sets, they could interpret the same name differently and contact different application servers or other network entities. This problem is not solved by security protocols, such as Transport Layer Security (TLS) [RFC5246] and SASL [RFC4422], that do not take local character sets into account.

12.5. Visually Similar Characters

Some code points are visually similar and thus can cause confusion among humans. Such characters are often called "confusable characters" or "confusables".
Top   ToC   RFC8264 - Page 34
   The problem of confusable characters is not necessarily caused by the
   use of Unicode code points outside the ASCII range.  For example, in
   some presentations and to some individuals the string "ju1iet"
   (spelled with DIGIT ONE (U+0031) as the third character) might appear
   to be the same as "juliet" (spelled with LATIN SMALL LETTER L
   (U+006C)), especially on casual visual inspection.  This phenomenon
   is sometimes called "typejacking".

   However, the problem is made more serious by introducing the full
   range of Unicode code points into protocol strings.  A well-known
   example is confusion between "а" CYRILLIC SMALL LETTER A (U+0430) and
   "a" LATIN SMALL LETTER A (U+0061).  As another example, the
   characters "ᏚᎢᎵᎬᎢᎬᏒ" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC
   U+13D2) from the Cherokee block look similar to the ASCII code points
   representing "STPETER" as they might appear when presented using a
   "creative" font family.  Confusion among such characters is perhaps
   not unexpected, given that the alphabetic writing systems involved
   all bear a family resemblance or historical lineage.  Perhaps more
   surprising is confusion among characters from disparate writing
   systems, such as "O" (LATIN CAPITAL LETTER O, U+004F), "0" (DIGIT
   PHARYNGEAL A, U+12D0), and other graphemes that have the appearance
   of open circles.  And the reader needs to be aware that the foregoing
   represent merely a small sample of characters that are confusable in

   In some instances of confusable characters, it is unlikely that the
   average human could tell the difference between the real string and
   the fake string.  (Indeed, there is no programmatic way to
   distinguish with full certainty which is the fake string and which is
   the real string; in some contexts, the string formed of Cherokee code
   points might be the real string and the string formed of ASCII code
   points might be the fake string.)  Because PRECIS-compliant strings
   can contain almost any properly encoded Unicode code point, it can be
   relatively easy to fake or mimic some strings in systems that use the
   PRECIS framework.  The fact that some strings are easily confused
   introduces security vulnerabilities of the kind that have also
   plagued the World Wide Web, specifically the phenomenon known as

   Despite the fact that some specific suggestions about identification
   and handling of confusable characters appear in the Unicode Security
   Considerations [UTR36] and the Unicode Security Mechanisms [UTS39],
   it is also true (as noted in [RFC5890]) that "there are no
   comprehensive technical solutions to the problems of confusable
   characters."  Because it is impossible to map visually similar
   characters without a great deal of context (such as knowing the font
   families used), the PRECIS framework does nothing to map similar-
Top   ToC   RFC8264 - Page 35
   looking characters together, nor does it prohibit some characters
   because they look like others.

   Nevertheless, 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 that
   use the protocol in question, along with any protocol-specific
   suggestions for overcoming those threats.  In particular, software
   implementations and service deployments that use PRECIS-based
   technologies are strongly encouraged to define and implement
   consistent policies regarding the registration, storage, and
   presentation of 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 that are used to write registered account names; in
       particular, 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

   The challenges inherent in supporting the full range of Unicode code
   points have in the past led some to hope for a way to
   programmatically negotiate more restrictive ranges based on locale,
   script, or other relevant factors; to tag the locale associated with
   a particular string; etc.  As a general-purpose internationalization
   technology, the PRECIS framework does not include such mechanisms.

12.6. Security of Passwords

Two goals of passwords are to maximize the amount of entropy and to minimize the potential for false accepts. These goals can be achieved in part by allowing a wide range of code points and by ensuring that passwords are handled in such a way that code points are not compared aggressively. Therefore, it is NOT RECOMMENDED for
Top   ToC   RFC8264 - Page 36
   application protocols to profile the FreeformClass for use in
   passwords in a way that removes entire categories (e.g., by
   disallowing symbols or punctuation).  Furthermore, it is
   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
   contained in such strings and to compare them in a case-sensitive

   That said, software implementers need to be aware that there exist
   trade-offs between entropy and usability.  For example, allowing a
   user to establish a password containing "uncommon" code points might
   make it difficult for the user to access a service when using an
   unfamiliar or constrained input device.

   Some application protocols use passwords directly, whereas others
   reuse technologies that themselves process passwords (one example of
   such a technology is SASL [RFC4422]).  Moreover, passwords are often
   carried by a sequence of protocols with backend authentication
   systems or data storage systems such as RADIUS [RFC2865] and the
   Lightweight Directory Access Protocol (LDAP) [RFC4510].  Developers
   of application protocols are encouraged to look into reusing these
   profiles instead of defining new ones, so that end-user expectations
   about passwords are consistent no matter which application protocol
   is used.

   In protocols that provide passwords as input to a cryptographic
   algorithm such as a hash function, the client will need to perform
   proper preparation of the password before applying the algorithm,
   because the password is not available to the server in plaintext

   Further discussion of password handling can be found in [RFC8265].

13. Interoperability Considerations

13.1. Coded Character Sets

It is known that some existing applications and systems do not 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., for the purpose of authenticating the combination of a username and password), naturally they will need to have in common at least one coded character set and the repertoire of characters being exchanged (see [RFC6365] for definitions of these terms). Establishing such a baseline is a matter for the application or system that uses PRECIS, not for the PRECIS framework.
Top   ToC   RFC8264 - Page 37

13.2. Dependency on Unicode

The only coded character set supported by PRECIS is Unicode. If an application or system does not support Unicode or uses a different coded character set [RFC6365], then the PRECIS rules cannot be applied to that application or system.

13.3. Encoding

Although strings that are consumed in PRECIS-based application protocols are often encoded using UTF-8 [RFC3629], the exact encoding is a matter for the application protocol that uses PRECIS, not for the PRECIS framework or for specifications that define PRECIS string classes or profiles thereof.

13.4. Unicode Versions

It is extremely important for protocol designers and application developers to understand that various changes can occur across versions of the Unicode Standard, and such changes can result in instability of PRECIS categories. The following are merely a few examples: o As described in [RFC6452], between Unicode 5.2 (current at the time IDNA2008 was originally published) and Unicode 6.0, three code points underwent changes in their GeneralCategory, resulting in modified handling, depending on which version of Unicode is available on the underlying system. o 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. o The East Asian width property, which is used in many PRECIS width mapping rules, is not guaranteed to be stable across Unicode versions.

13.5. Potential Changes to Handling of Certain Unicode Code Points

As part of the review of Unicode 7.0 for IDNA, a question was raised about a newly added code point that led to a re-analysis of the normalization rules used by IDNA and inherited by this document (Section 5.2.4). Some of the general issues are described in [IAB-Statement] and pursued in more detail in [IDNA-Unicode]. At the time of this writing, these issues have yet to be settled. However, implementers need to be aware that this specification is
Top   ToC   RFC8264 - Page 38
   likely to be updated in the future to address these issues.  The
   potential changes include but might not be limited to the following:

   o  The range of code points in the LetterDigits category
      (Sections 4.2.1 and 9.1) might be narrowed.

   o  Some code points with special properties that are now allowed
      might be excluded.

   o  More additional mapping rules (Section 5.2.2) might be defined.

   o  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
   <>: that is, to not make
   further updates to the registry.

   Nevertheless, implementations and deployments are unlikely to
   encounter significant problems as a consequence of these issues or
   potential changes if they follow the advice given in this
   specification to use the more restrictive IdentifierClass whenever
   possible or, if using the FreeformClass, to allow only a restricted
   set of code points, particularly avoiding code points whose
   implications they do not 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, <>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <>.
Top   ToC   RFC8264 - Page 39
   [RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
              Internationalization in the IETF", BCP 166, RFC 6365,
              DOI 10.17487/RFC6365, September 2011,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [Unicode]  The Unicode Consortium, "The Unicode Standard",

14.2. Informative References

[DerivedCoreProperties] The Unicode Consortium, "DerivedCoreProperties- 10.0.0.txt", Unicode Character Database, March 2017, < DerivedCoreProperties.txt>. [Err4568] RFC Errata, Erratum ID 4568, RFC 7564, <>. [IAB-Statement] Internet Architecture Board, "IAB Statement on Identifiers and Unicode 7.0.0", February 2015, < 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, < 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, <>.
Top   ToC   RFC8264 - Page 40
   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              DOI 10.17487/RFC3454, December 2002,

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, DOI 10.17487/RFC3490, March 2003,

   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, DOI 10.17487/RFC3491, March 2003,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510,
              DOI 10.17487/RFC4510, June 2006,

   [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,

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
Top   ToC   RFC8264 - Page 41
   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,

   [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,

   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,

   [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
              Internationalized Domain Names in Applications (IDNA)
              2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,

   [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, <>.

   [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,

   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <>.

   [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,
Top   ToC   RFC8264 - Page 42
   [RFC7622]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Address Format", RFC 7622,
              DOI 10.17487/RFC7622, September 2015,

   [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,

   [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,

   [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,

   [RFC8266]  Saint-Andre, P., "Preparation, Enforcement, and Comparison
              of Internationalized Strings Representing Nicknames",
              RFC 8266, DOI 10.17487/RFC8266, October 2017,

   [UAX11]    Unicode Standard Annex #11, "East Asian Width", edited by
              Ken Lunde.  An integral part of The Unicode Standard,

   [UAX15]    Unicode Standard Annex #15, "Unicode Normalization Forms",
              edited by Mark Davis and Ken Whistler.  An integral part
              of The Unicode Standard,

   [UAX9]     Unicode Standard Annex #9, "Unicode Bidirectional
              Algorithm", edited by Mark Davis, Aharon Lanin, and Andrew
              Glass.  An integral part of The Unicode Standard,

   [UTR36]    Unicode Technical Report #36, "Unicode Security
              Considerations", edited by Mark Davis and Michel Suignard,

   [UTS39]    Unicode Technical Standard #39, "Unicode Security
              Mechanisms", edited by Mark Davis and Michel Suignard,
Top   ToC   RFC8264 - Page 43

Appendix A. Changes from RFC 7564

The following changes were made from [RFC7564]. o Recommended the Unicode toLowerCase() operation over the Unicode toCaseFold() operation in most PRECIS applications. o Clarified the meaning of "preparation", and described the motivation for including it in PRECIS. o Updated references. See [RFC7564] for a description of the differences from [RFC3454].


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

Peter Saint-Andre P.O. Box 787 Parker, CO 80134 United States of America Phone: +1 720 256 6756 Email: URI: Marc Blanchet Viagenie 246 Aberdeen Québec, QC G1R 2E1 Canada Email: URI: