RFC 5893

Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)

📅 published August 2010, from ietf

Internet Engineering Task Force (IETF) 💖 Request for Comments: 5893 🎀 Authors: H. Alvestrand, Ed. (Google) and C. Karp (Swedish Museum of Natural History) 🫶 Category: Standards Track ✨ ISSN: 2070-1721 Date: August 2010 📅 Obsoletes / Updates: this title block doesn't list anything it obsoletes or updates 🦋

Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) 🌈

Abstract

okay so the whole point here is that right-to-left scripts in Internationalized Domain Names (IDNs) have been giving everyone a hard time 😭 this memo adds a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels. it's based on the problems people hit with some scripts, and on the shortcomings of the 2003 IDNA Bidi criterion 💅

Status of This Memo

this is an Internet Standards Track document 🌸

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

for the current status of this document, any errata, and how to give feedback on it, check out http://www.rfc-editor.org/info/rfc5893 🔥

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) as they stand on the date this document was published. please read these carefully, because they spell out your rights and restrictions for this document. code components extracted 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.  Purpose and Applicability  . . . . . . . . . . . . . . . .  2
  1.2.  Background and History . . . . . . . . . . . . . . . . . .  3
  1.3.  Structure of the Rest of This Document . . . . . . . . . .  3
  1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
2.  The Bidi Rule  . . . . . . . . . . . . . . . . . . . . . . . .  6
3.  The Requirement Set for the Bidi Rule  . . . . . . . . . . . .  6
4.  Examples of Issues Found with RFC 3454 . . . . . . . . . . . .  9
  4.1.  Dhivehi  . . . . . . . . . . . . . . . . . . . . . . . . .  9
  4.2.  Yiddish  . . . . . . . . . . . . . . . . . . . . . . . . . 10
  4.3.  Strings with Numbers . . . . . . . . . . . . . . . . . . . 12
5.  Troublesome Situations and Guidelines  . . . . . . . . . . . . 12
6.  Other Issues in Need of Resolution . . . . . . . . . . . . . . 13
7.  Compatibility Considerations . . . . . . . . . . . . . . . . . 14
  7.1.  Backwards Compatibility Considerations . . . . . . . . . . 14
  7.2.  Forward Compatibility Considerations . . . . . . . . . . . 15
8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
  10.2. Informative References . . . . . . . . . . . . . . . . . . 17

1. Introduction ✨

1.1. Purpose and Applicability

the goal here is to set up a rule that can be applied to Internationalized Domain Name (IDN) labels in Unicode form (U-labels) that contain characters from scripts written right to left 🔄 it's part of the revised IDNA protocol [RFC5891] 💜

when labels satisfy the rule, and certain other conditions are also met, there's only a minimal chance that the Unicode bidirectional display algorithm will show them in a confusing way 👑

the other normative documents in the IDNA2008 document set set the criteria for valid labels, including the list of permitted characters. this document adds extra validity criteria for labels in scripts that are normally written right to left 🌸

this specification isn't meant to put any requirements on domain names that don't contain characters from those scripts 🙈

1.2. Background and History

the "Stringprep" specification [RFC3454], which is part of IDNA2003, said the following in its Section 6 about the Bidi algorithm 🧐

   3) If a string contains any RandALCat character, a RandALCat
      character MUST be the first character of the string, and a
      RandALCat character MUST be the last character of the string.

(a RandALCat character is a character with unambiguously right-to-left directionality 🍓)

the reasoning behind this ban was to make sure every component of a displayed domain name has one clear preferred direction. but it made certain words in languages written with right-to-left scripts invalid as IDN labels. in at least one case (Dhivehi), it meant that every word in an entire language was forbidden as an IDN label 😭

this is illustrated below with examples from the Dhivehi and Yiddish languages, written in the Thaana and Hebrew scripts, respectively 🧚

RFC 3454 didn't explicitly state the requirement it was trying to fulfill. so it's impossible to tell whether a simple relaxation of the rule would still fulfill that requirement 🤷‍♀️

this document specifies rules that are quite different from RFC 3454, but most reasonable labels that were allowed under RFC 3454 will still be allowed under this specification 🎀 the most important examples of labels that are still not permitted are labels that mix Arabic and European digits (AN and EN) inside an RTL label, and labels that use AN in an LTR label (see Section 1.4 for terminology). so the operational impact of using the new rule in the updated IDNA specification is limited 💅

1.3. Structure of the Rest of This Document

Section 2 defines a rule, the "Bidi rule", which can be used on a domain name label to check how safe it is to use in a domain name of possibly mixed directionality. its primary initial use is as part of the IDNA2008 protocol [RFC5891] 🦋

Section 3 sets out the requirements for defining the Bidi rule 📝

Section 4 gives detailed examples that justify the new rule 🔍

Section 5 to Section 8 describe various situations that can come up when dealing with domain names containing characters of different directionality 🌈

only Section 1.4 and Section 2 are normative 👑

1.4. Terminology

the terminology used to describe IDNA concepts is defined in the Definitions document [RFC5890] 📖

the terminology for the Bidi properties of Unicode characters is taken from the Unicode Standard [Unicode52] 🌷

the Unicode Standard gives every character a Bidi property. that property controls how the character behaves in the Unicode bidirectional algorithm [Unicode-UAX9]. for reference, these are the values the Unicode Bidi property can have 🫧

  • L - Left to right - most letters in LTR scripts
  • R - Right to left - most letters in non-Arabic RTL scripts
  • AL - Arabic letters - most letters in the Arabic script
  • EN - European Number (0-9, and Extended Arabic-Indic numbers)
  • ES - European Number Separator (+ and -)
  • ET - European Number Terminator (currency symbols, the hash sign, the percent sign and so on)
  • AN - Arabic Number; this encompasses the Arabic-Indic numbers, but not the Extended Arabic-Indic numbers
  • CS - Common Number Separator (. , / : et al)
  • NSM - Nonspacing Mark - most combining accents
  • BN - Boundary Neutral - control characters (ZWNJ, ZWJ, and others)
  • B - Paragraph Separator
  • S - Segment Separator
  • WS - Whitespace, including the SPACE character
  • ON - Other Neutrals, including @, &, parentheses, MIDDLE DOT
  • LRE, LRO, RLE, RLO, PDF - these are "directional control characters" and are not used in IDNA labels

in this memo, "network order" describes the sequence of characters as transmitted on the wire or stored in a file. the terms "first", "next", "previous", "beginning", "end", "before", and "after" refer to how characters and labels relate in network order. "display order" is the sequence of characters as shown on a display medium, and the terms "left" and "right" refer to how characters and labels relate in display order 🖥️

most of the time, the examples use the abbreviations for the Unicode Bidi classes to show the directionality of characters. for example, the string CS L has one character of class CS and one character of class L. in some examples, uppercase characters are class R or AL, and lowercase characters are class L. so ABC.abc would be three right-to-left characters followed by three left-to-right characters 🌸

the directionality of these examples is decided by context. for instance, in the sentence "ABC.abc is displayed as CBA.abc", the first example string is in network order and the second is in display order 🙃

the term "paragraph" follows the sense used in the Unicode Bidi specification [Unicode-UAX9]. it means "a block of text that has an overall direction, either left to right or right to left", roughly speaking. see the "Unicode Bidirectional Algorithm" [Unicode-UAX9] for the details 📜

"RTL" and "LTR" are short for "right to left" and "left to right", respectively 🍭

an RTL label is a label that contains at least one character of type R, AL, or AN 🔥

an LTR label is any label that isn't an RTL label 🩵

a "Bidi domain name" is a domain name that contains at least one RTL label. (note: this definition includes domain names containing only dots and right-to-left characters. a separate category of "RTL domain names" wouldn't make this specification any simpler, so it wasn't added 💀)

2. The Bidi Rule ✨

okay so this is the big one, bestie 🎀 there are six conditions, and a label in a Bidi domain name has to pass all of them to count as okay. The requirements it's built to satisfy are in Section 3, so hold that thought 🧚

  1. The first character has to have Bidi property L, R, or AL. If it's R or AL, it's an RTL label. If it's L, it's an LTR label. 🌈
  2. In an RTL label, only characters with the Bidi properties R, AL, AN, EN, ES, CS, ET, ON, BN, or NSM are allowed. 💅
  3. In an RTL label, the end of the label has to be a character with Bidi property R, AL, EN, or AN, followed by zero or more characters with Bidi property NSM. 🫶
  4. In an RTL label, if an EN is present, no AN may be present, and vice versa. not a vibe 💀
  5. In an LTR label, only characters with the Bidi properties L, EN, ES, CS, ET, ON, BN, or NSM are allowed. 🍓
  6. In an LTR label, the end of the label has to be a character with Bidi property L or EN, followed by zero or more characters with Bidi property NSM. 👑

so what does passing actually guarantee? two things, iykyk 🦋

  • In a domain name made up only of labels that pass the rule, the Section 3 requirements are satisfied. And this includes LTR labels and pure ASCII labels too, so they have to be tested as well. no one gets a free pass 😭
  • In a domain name made up only of LDH labels (as defined in the Definitions document [RFC5890]) and labels that pass the rule, the Section 3 requirements are satisfied, as long as a label starting with an ASCII digit doesn't come after a right-to-left label. 🙈

and no guarantee is given for other combinations. 🫠

3. The Requirement Set for the Bidi Rule 🌸

okay so unlike RFC 3454 [RFC3454], this document actually explains why the Bidi rule exists, and it lists requirements you can really test against the modified rule. the way that's giving clarity 🧠

All the text in this document assumes that text containing the labels under consideration will be displayed using the Unicode bidirectional algorithm [Unicode-UAX9].

here are the requirements being proposed:

  • Label Uniqueness: No two labels, when shown in display order in the same paragraph, should have the same sequence of characters without also having the same sequence of characters in network order. This needs to hold both when the paragraph is LTR and when it's RTL. (This is the criterion that's explicit in RFC 3454.) (Note that a label displayed in an RTL paragraph may look the same as a different label displayed in an LTR paragraph and still pass this criterion. the lookalikes are a whole thing 👀)
  • Character Grouping: When you display a string of labels and use the Unicode Bidi algorithm to reorder the characters, the characters of each label should stay grouped between the characters that delimit the labels. This has to work both when the string sits in an LTR paragraph and when it sits in an RTL paragraph. 🎀

Several stronger statements were considered and then rejected, because they seem impossible to fulfill within the constraints of the Unicode bidirectional algorithm. bestie, it's giving "we tried" 💔 These include:

  • The appearance of a label should be unaffected by its embedding context. This turned out to be impossible even for ASCII labels. For example, the label 123-A has a different display order in an RTL context than in an LTR context. (This particular example is, however, disallowed anyway. thank goodness 🙏)
  • The sequence of labels should be consistent with network order. This also proved impossible. A domain name made of the labels (in network order) L1.R2.R3.L4 gets displayed as L1.R3.R2.L4 in an LTR context. (In an RTL context, it gets displayed as L4.R3.R2.L1.) 😵‍💫
  • No two domain names should display the same, even under differing directionality. This was shown to be unsound. The domain name (in network order) ABC.abc has display order CBA.abc in an LTR context and abc.CBA in an RTL context, while the domain name (network) abc.ABC has display order abc.CBA in an LTR context and CBA.abc in an RTL context. two different names, same vibes, chaos 🌀

One possible requirement was thought to be problematic, but it turned out to be satisfied by a string that obeys the proposed rules. ✨ The requirement is:

  • The Character Grouping requirement should be satisfied when directional controls (LRE, RLE, RLO, LRO, PDF) are used in the same paragraph (outside of the labels). These controls affect presentation order in non-obvious ways, by affecting the "sor" and "eor" properties of the Unicode Bidi algorithm. So the conditions above need extra testing to figure out whether they influence the display of the domain name. Testing found that, for the strings allowed under the rule presented in this document, directional controls do not influence the display of the domain name. 🦋

This still isn't stated as a requirement, since it didn't seem as important as the stated ones. But it's useful to know that Bidi domain names where the labels satisfy the rule have this property. 💜

In the descriptions below, first-level bullets are used to show rules or normative statements, and second-level bullets are commentary. 🍓

The Character Grouping requirement can be more formally stated as:

  • Let "Delimiterchars" be a set of characters with the Unicode Bidi properties CS, WS, ON. (These are commonly used to delimit labels. Both the FULL STOP and the space are included. They are not allowed in domain labels.)
    • ET, even though it commonly shows up next to domain names in practice, is problematic. The context R CS L EN ET (for instance A.a1%) makes the label L EN fail the character grouping requirement. 😬
    • ES commonly occurs in labels as HYPHEN-MINUS, but it could also be used as a delimiter (for instance, the plus sign). It's left out here. 🙃
  • Let "unproblematic label" be a label that either satisfies the requirements, or does not contain any character with the Bidi properties R, AL, or AN and does not begin with a character with the Bidi property EN. (Informally, "it does not start with a number".) 🧚

A label X satisfies the Character Grouping requirement when, for any Delimiter Character D1 and D2, and for any label S1 and S2 that is an unproblematic label or an empty string, the following holds true:

If the string formed by concatenating S1, D1, X, D2, and S2 is reordered according to the Bidi algorithm, then all the characters of X in the reordered string are between D1 and D2, and no other characters are between D1 and D2. This has to be true both if the overall paragraph direction is LTR and if it is RTL. 💅

Note that the definition is self-referential, since S1 and S2 are constrained to be "legal" by this definition. This makes testing changes to proposed rules a little complex, but it doesn't create problems for testing whether a given proposed rule satisfies the criterion. 🤓

The "zero-length" case represents the situation where a domain name sits next to something that isn't a domain name, separated by a delimiter character. 🌙

Note about the position of BN: The Unicode bidirectional algorithm specifies that a BN has an effect on the adjoining characters in network order, not in display order. So BN characters are treated as if they were removed during Bidi processing ([Unicode-UAX9], Section 3.3.2, rule X9 and Section 5.3). Because of that, the question of "what position does a BN have after reordering" isn't meaningful. It was ignored while developing the rules here. 🫠

The Label Uniqueness requirement can be formally stated as:

If two non-identical labels X and Y, embedded as in the test above and displayed in paragraphs with the same directionality, are reordered by the Bidi algorithm into the same sequence of code points, then the labels X and Y cannot both be legal. 🔐

4. Examples of Issues Found with RFC 3454 💖

these examples are the receipts 🧾 showing why RFC 3454 needed a fix. they're kinda wild, not gonna lie 😭

4.1. Dhivehi 🌺

Dhivehi, the official language of the Maldives, is written with the Thaana script. This script shares some characteristics with the Arabic script, including its directional properties, and the way it marks vowels with diacritics on consonantal base characters. That marking is obligatory. Both two consecutive vowels and syllable-final consonants are indicated with unvoiced combining marks. So every Dhivehi word ends with a combining mark. ✨

The word for "computer", which is romanized as konpeetaru, is written with the following sequence of Unicode code points:

U+0786 THAANA LETTER KAAFU (AL)

U+07AE THAANA OBOFILI (NSM)

U+0782 THAANA LETTER NOONU (AL)

U+07B0 THAANA SUKUN (NSM)

U+0795 THAANA LETTER PAVIYANI (AL)

U+07A9 THAANA LETTER EEBEEFILI (AL)

U+0793 THAANA LETTER TAVIYANI (AL)

U+07A6 THAANA ABAFILI (NSM)

U+0783 THAANA LETTER RAA (AL)

U+07AA THAANA UBUFILI (NSM)

The directionality class of U+07AA in the Unicode database [Unicode52] is NSM (Nonspacing Mark), which is not R or AL. So a conformant implementation of the IDNA2003 algorithm will say that "this is not in RandALCat" and refuse to encode the string. 🙅‍♀️ that's a whole plot twist, bestie 😭🔥

4.2. Yiddish 🌸

Okay so Yiddish is one of a few languages written with the Hebrew script 🧚 (the others are Hebrew and Ladino). It's basically a consonantal alphabet (aka an "abjad"), but Yiddish uses an extended form that is fully vocalic 💖. The vowels get shown in a few different ways. One way is by repurposing letters that are consonants in Hebrew. Other letters work as both vowels and consonants, and little marks called "points" tell you which one it is ✨. Some base characters can stand for several different vowels too, and combining marks are what sort those out. Pointed characters can show up at the end of a word, so they may also be needed at the end of labels. This isn't a fixed rule for every Yiddish string, so there's a bit more wiggle room here than there is with Dhivehi 🫶.

The organization now known as the "YIVO Institute for Jewish Research" wrote orthographic rules for modern Standard Yiddish in the 1930s 📚. They were built on work done in several places since earlier in that century. You'll find them in "The Standardized Yiddish Orthography: Rules of Yiddish Spelling" [SYO]. They're treated as the normative description of modern Standard Yiddish in any context where that matters. Every formal Yiddish dictionary published since they came out has used them exclusively, and they're just as dominant in academic and bibliographic work 👑.

So it makes sense for this repertoire to be fully supported by IDNA 🎀. There's no trouble with characters in initial and medial positions, but pointed characters are regularly used in final position as well 🙈. Every character in the SYO repertoire shows up in both marked and unmarked form, with one exception: the HEBREW LETTER PE (U+05E4) 💅. The SYO only allows it with a HEBREW POINT DAGESH (U+05BC), which gives the Yiddish version of the Latin letter "p". It can also take a HEBREW POINT RAFE (U+05BF), which is equivalent to the Latin letter "f". There's a separate unpointed allograph for the "f" version when it's in final position, the HEBREW LETTER FINAL PE (U+05E3) 🦋. So the limit that comes from banning combining marks at the end of RTL strings boils down to exactly this: a string of Latin characters can't end with the letter "p" 😭. It's also worth knowing that the HEBREW LETTER PE with the HEBREW POINT DAGESH shows up in almost all traditional Yiddish orthographies that came before the SYO (or are still used alongside it). It was the first pointed character to appear in any of them 🌈.

A more general version of the same problem shows up in how the YIVO acronym is represented 💜. The acronym is written with the Hebrew letters YOD YOD HIRIQ VAV VAV ALEF QAMATS, where HIRIQ and QAMATS are combining points. The Unicode code points are:

U+05D9 HEBREW LETTER YOD (R)

U+05B4 HEBREW POINT HIRIQ (NSM)

U+05D5 HEBREW LETTER VAV (R)

U+05D0 HEBREW LETTER ALEF (R)

U+05B8 HEBREW POINT QAMATS (NSM)

The directionality class of U+05B8 HEBREW POINT QAMATS in the Unicode database is NSM. That's why the IDNA2003 algorithm rejects the string again 🙅‍♀️.

It's also worth noting that all of the combined characters above exist in precomposed form at separate positions in the Unicode chart 🍓. But because Stringprep gets invoked, the IDNA2003 algorithm rejects those code points too. The reasons aren't discussed here 🤷‍♀️.

4.3. Strings with Numbers 🔢

Stringprep [RFC3454] required that the first or last character of a string be a member of category R or AL. Because of that, a string containing right-to-left characters couldn't end with a number 😤.

Let's look at ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE) and 5 ALEF. In an LTR context, the first one shows up from left to right as 5 ALEF. The 5 counts as right to left because of the leading ALEF. The second one, 5 ALEF, is displayed in exactly the same order, since the 5 takes its direction from context 🌸. Clearly only one of those should be allowed as a registered label. But barring both of them seems like overkill 💀.

5. Troublesome Situations and Guidelines ⚠️

There are situations where labels that follow the rule above still get displayed in a surprising way 😳. The most important one is when a label ending in a character with Bidi property AL, AN, or R comes right before a label beginning with a character of Bidi property EN. In that case the number seems to jump into the label with the right-to-left character, which breaks the Character Grouping requirement 🙀.

If the label after the right-to-left label satisfies the Bidi criterion itself, the requirements are met in every case. That's the reason the criterion talks about strings containing L in some cases ✨. Even so, the IDNABIS WG concluded that this couldn't be required, and they had several reasons:

  • There is a large current deployment of ASCII domain names starting with digits. These cannot possibly be invalidated. 🙅‍♀️
  • Domain names are often built piece by piece, for instance by combining a string with the content of a search list. This may happen after IDNA processing, so it can be in code that isn't IDNA-aware. That makes it impossible to detect the undesirable combination 🫠.
  • Even if a label is registered under a "safe" label, there may be a DNAME [RFC2672] with an "unsafe" label that points to the "safe" label. That creates seemingly valid names that wouldn't satisfy the criterion 🌀.
  • Wildcards create the odd situation where a label is "valid" (can be looked up successfully) without the zone owner knowing that the label exists. So an owner of a zone whose name starts with a digit and contains a wildcard has no way of controlling whether names with RTL labels in them get looked up in their zone 😵‍💫.

Rather than trying to suggest rules that block all of these undesirable situations, this document just warns about the possibility. It leaves application developers to take whatever measures they deem appropriate to avoid problematic situations 🎀.

6. Other Issues in Need of Resolution 🧩

This document only deals with the rules needed when handling domain names with characters that have differing Bidi properties. It considers characters only in terms of their Bidi properties 💅. All other issues with scripts written from right to left must be considered in other contexts 📝.

One of those issues is keeping numbers separate 🔢. Several scripts are used with multiple sets of numbers. Most commonly they use Latin numbers plus a script-specific set of numbers. But with Arabic, there are two sets of "Arabic-Indic" digits involved 🌙.

The algorithm in this document disallows AN-class characters ("Arabic-Indic digits", U+0660 to U+0669) occurring together with EN-class characters. EN-class characters include "European" digits (U+0030 to U+0039) and "extended Arabic-Indic digits" (U+06F0 to U+06F9) 💫. It doesn't help prevent mixing of, for instance, Bengali digits (U+09E6 to U+09EF) and Gujarati digits (U+0AE6 to U+0AEF). Both of those have Bidi class L 😬. A registry or script community that wants to restrict mixing digits in a label can specify those restrictions at the registry level 🏳️‍🌈. Some rules are also specified at the protocol level ✨.

Another set of issues is about properly displaying IDNs that mix LTR and RTL labels, or that have only RTL labels 🌊.

It's unrealistic to expect applications to display domain names using embedded formatting codes between their labels. For one thing, no reliable algorithms for spotting domain names in running text exist 🙃. So the display order gets decided by the Bidi algorithm. That means a sequence (in network order) of R1.R2.ltr gets displayed in the order 2R.1R.ltr in an LTR context. That might surprise someone who expects labels to show up in hierarchical order 👀. People used to working with text that mixes LTR and RTL strings might not be so surprised 🦋. Again, this memo doesn't try to suggest a solution to this problem 🫶.

7. Compatibility Considerations 🤝

7.1. Backwards Compatibility Considerations 🕰️

As with any change to an existing standard, it's important to think about what happens to existing implementations when the change is introduced 💭. Some troublesome cases include:

  • An old program used to input the newly allowed label. If the old program checks the input against RFC 3454, some labels won't be allowed, and domain names containing those labels will stay inaccessible 🚫.
  • An old program is asked to display the newly allowed label and checks it against RFC 3454 before displaying. The program will perform some kind of fallback, most likely displaying the label in A-label form 🔁.
  • An old program tries to display the newly allowed label. If the old program has code for displaying the last character of a label that's different from the code used for the characters in the middle of the label, the display may be inconsistent and cause confusion 😵.

One particular example of that last case: if a program examines the last character (in network order) of a string to determine its directionality, rather than the first, things get weird. If it finds an NSM character and tries to display the string as if it were a left-to-right string, the result may be interesting, but not useful 🙈.

The editors believe these cases will have a less harmful impact in practice than continuing to deny the use of words from the languages for which these strings are necessary as IDN labels 💖.

This specification does not forbid using leading European digits in ASCII-only labels 🔤. Doing so would conflict with a large installed base of such labels, and it would widen the scope of the specification from RTL labels to all labels. The harm from limiting the scope this way is described in Section 5 📖. Registries and private zone managers can check for this particular condition before they allow registration of any RTL label 🗂️. Generally, it's best to disallow registration of any right-to-left strings in a zone where the label at the level above begins with a digit 🧁.

7.2. Forward Compatibility Considerations 🔮

This text is intentionally specified strictly in terms of the Unicode Bidi properties 🎯. Whether the condition is sufficient to fulfill the criteria depends on the Unicode Bidi algorithm. It's unlikely that drastic changes will be made to this algorithm 🛡️.

However, whether any string is valid depends on the Unicode Bidi property values. The Unicode Consortium doesn't declare those values immutable 🌀. Also, the behavior of the algorithm for any given character is likely to be linguistically and culturally sensitive. So while it should occur rarely, it's possible that later versions of the Unicode Standard may change the Bidi properties assigned to certain Unicode characters 🌍.

This memo does not propose a solution for this problem 🙏.

8. Security Considerations 🔒✨

Okay bestie, security time 😭. Mixed-direction text can be seriously surprising if you're not used to it 🙈. Like, cut and paste a chunk of text and it might display totally differently at the destination if that destination is in another directionality context 💀. And adding one character in one spot can make characters way over on the other side of the string change their display position. Not a problem unique to domain names though. It's giving "text does weird things" everywhere 🌈.

The new IDNA protocol, and especially these new Bidi rules, will let some strings be used in IDNA contexts that aren't allowed today 💅. It's possible that IDNA2003 and IDNA2008 implementations interpreting labels differently could pose a security risk, but ngl it's really hard to picture any specific way that would happen 🤔.

Any rational attempt to compute, for instance, a hash over an identifier processed by IDNA would use network order for its computation, so it's unaffected by the new rules proposed here 🔐.

It's not believed to be a problem, but if display routines had been written with specific knowledge of the RFC 3454 IDNA prohibitions, the potential problems noted under "Backwards Compatibility Considerations" could cause new kinds of confusion 🫣.

9. Acknowledgements 🫶

While the listed editors held the pen, this document represents the joint work and conclusions of an ad hoc design team. Besides the editors, that team was, in alphabetic order, Tina Dam, Patrik Faltstrom, and John Klensin. Many further specific contributions and helpful comments came from the people listed below, and from others who have contributed to the development and use of the IDNA protocols 🌸.

The particular formulation of the Bidi rule in Section 2 was suggested by Matitiahu Allouche 👑.

The team especially wants to thank Roozbeh Pournader for calling its attention to the issue with the Thaana script, Paul Hoffman for pointing out the need to be explicit about backwards compatibility considerations, Ken Whistler for suggesting the basis of the formalized "Character Grouping" requirement, Mark Davis for commentary, Erik van der Poel for careful review, comments, and verification of the rulesets, Marcos Sanz, Andrew Sullivan, and Pete Resnick for reviews, and Vint Cerf for chairing the working group and contributing massively to getting the documents finished 🏆.

10. References 📚

10.1. Normative References

  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
  • [Unicode-UAX9] The Unicode Consortium, "Unicode Standard Annex #9: Unicode Bidirectional Algorithm", September 2009, <http://www.unicode.org/reports/tr9/>.
  • [Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). <http://www.unicode.org/versions/Unicode5.2.0/>.

10.2. Informative References

  • [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
  • [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
  • [SYO] "The Standardized Yiddish Orthography: Rules of Yiddish Spelling, 6th ed., New York, ISBN 0-914512-25-0", 1999.

Authors' Addresses 💌

Harald Tveit Alvestrand (editor)
Google
Beddingen 10
Trondheim,   7014
Norway

EMail: harald@alvestrand.no


Cary Karp
Swedish Museum of Natural History
Frescativ. 40
Stockholm,   10405
Sweden

Phone: +46 8 5195 4055
Fax:
EMail: ck@nic.museum
📦 where this page comes from