RFC 6452

RFC 6452: The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 💖

okay bestie, this is RFC 6452 🎀 It's a Standards Track doc from the IETF, dated November 2011, with ISSN 2070-1721. The editors are Patrik Faltstrom (Cisco) and Paul Hoffman (VPN Consortium). The title block doesn't list anything it obsoletes or updates 🦋

---

Abstract

this doc writes down the IETF consensus on the IDNA-derived character properties for three code points that already existed in Unicode 5.2 but changed property values when Unicode 6.0 came out 🌸 the verdict is that no update is needed to [RFC5892] because of the Unicode 6.0 changes ✨

Status of This Memo

this is an Internet Standards Track document 🎀

this is a product of the Internet Engineering Task Force (IETF) 💅 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). for more on Internet Standards, check Section 2 of RFC 5741 📚

info about the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6452 🌈

Copyright Notice

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶

Table of Contents

1. Introduction ....................................................2
   1.1. U+0CF1 KANNADA SIGN JIHVAMULIYA ............................2
   1.2. U+0CF2 KANNADA SIGN UPADHMANIYA ............................2
   1.3. U+19DA NEW TAI LUE THAM DIGIT ONE ..........................2
2. IETF Consensus ..................................................2
3. IANA Considerations .............................................3
4. Security Considerations .........................................3
5. Acknowledgements ................................................3
6. Normative References ............................................3

1. Introduction ✨

okay so [RFC5892] specifies an algorithm that was written when version 5.0 (later updated to 5.2) [Unicode5.2] was the current Unicode 🧚 it also defines a derived property value based on that algorithm. then Unicode 6.0 [Unicode6] changed the GeneralCategory of three code points that were allocated in Unicode 5.2 or earlier 😭 that means the derived property value is different depending on whether you use the property definitions from Unicode 5.2 or from 6.0. these are non-backward-compatible changes, as described in Section 5.1 of RFC 5892 💀

the three code points are:

1.1. U+0CF1 KANNADA SIGN JIHVAMULIYA

the GeneralCategory for this character changes from So to Lo 🍓 that means the derived property value changes from DISALLOWED to PVALID 💜

1.2. U+0CF2 KANNADA SIGN UPADHMANIYA

same glow-up here: the GeneralCategory changes from So to Lo ✨ so the derived property value changes from DISALLOWED to PVALID 🌸

1.3. U+19DA NEW TAI LUE THAM DIGIT ONE

this one goes the other way 🙈 the GeneralCategory changes from Nd to No, so the derived property value changes from PVALID to DISALLOWED 😭

2. IETF Consensus 🎀

no change to [RFC5892] is needed based on the changes made in Unicode 6.0 🦋

this consensus does not mean that no changes will ever be made to RFC 5892 for future updates of The Unicode Standard. bestie, plans can change 💅

this RFC exists because 6.0 is the first version of Unicode released since IDNA2008 was published 🌈

3. IANA Considerations 📚

IANA has updated the derived property value registry according to RFC 5892 and the property values defined in The Unicode Standard version 6.0 🫶

4. Security Considerations 💀

okay this part is important 🚨 when the algorithm from RFC 5892 runs with the property definitions of Unicode Standard version 6.0, the result will be different from running it with the property definitions of Unicode 5.2, for the three code points discussed in this document. the good news is that these three code points are unlikely to show up in internationalized domain names, so the security implications of the changes are minor 🛡️✨

5. Acknowledgements 👑

the main contributors, in alphabetical order, are Eric Brunner-Williams, Vint Cerf, Tina Dam, Mark Davis, Martin Duerst, John Klensin, Pete Resnick, Markus Scherer, Andrew Sullivan, Kenneth Whistler, and Nicholas Williams 🫶🌸

not every contributor thinks the solution for the issues in this document is optimal, and that's okay 🦋

6. Normative References 🎀

• [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
• [Unicode5.2] The Unicode Consortium, "The Unicode Standard, Version 5.2.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN 0-321-48091-0, as amended by Unicode 5.2.0, October 2009, http://www.unicode.org/versions/Unicode5.2.0/.
• [Unicode6] The Unicode Consortium, "The Unicode Standard, Version 6.0.0", October 2010, http://www.unicode.org/versions/Unicode6.0.0/.

Authors' Addresses 🧚

Patrik Faltstrom (editor), Cisco, EMail: paf@cisco.com 💖

Paul Hoffman (editor), VPN Consortium, EMail: paul.hoffman@vpnc.org 💜