One document matched: draft-ietf-idnabis-bidi-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idnabis-bidi-06" ipr="trust200902">
<front>
<title abbrev="IDNA right-to-left">Right-to-left scripts for IDNA</title>
<author fullname="Harald Tveit Alvestrand" initials="H. T." role="editor"
surname="Alvestrand">
<organization>Google</organization>
<address>
<postal>
<street>Beddingen 10</street>
<city>Trondheim</city>
<region></region>
<code>7014</code>
<country>Norway</country>
</postal>
<email>harald@alvestrand.no</email>
</address>
</author>
<author fullname="Cary Karp" initials="C." surname="Karp">
<organization>Swedish Museum of Natural History</organization>
<address>
<postal>
<street>Frescativ. 40</street>
<city>Stockholm</city>
<region></region>
<code>10405</code>
<country>Sweden</country>
</postal>
<phone>+46 8 5195 4055</phone>
<facsimile></facsimile>
<email>ck@nrm.museum</email>
<uri></uri>
</address>
</author>
<date day="28" month="September" year="2009" />
<abstract>
<t>The use of right-to-left scripts in internationalized domain names
has presented several challenges. This memo proposes a new BIDI rule for
IDNA labels, based on the encountered problems with some scripts, and
some shortcomings in the 2003 IDNA BIDI criterion.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Purpose and applicability">
<t>The purpose of this document is to establish a rule that can be
applied to Internationalized Domain Name (IDN) labels in Unicode form
(U-labels) containing characters from scripts that are written from
right to left. It is part of the revised IDNA protocol defined in
<xref target="I-D.ietf-idnabis-protocol"></xref>.</t>
<t>When labels satisfy the rule, and when certain other conditions are
satisfied, there is only a minimal chance of these labels being
displayed in a confusing way by the Unicode bidirectional display
algorithm.</t>
<t>This specification is not intended to place any requirements on
domain names that do not contain characters from such scripts.</t>
</section>
<section title="Background and history">
<t>The "Stringprep" specification <xref target="RFC3454"></xref>, part
of IDNA2003, made the following statement in its section 6 on the BIDI
algorithm:<list style="empty">
<t>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.</t>
</list></t>
<t>(A RandALCat character is a character with unambiguously
right-to-left directionality.)</t>
<t>The reasoning behind this prohibition was to ensure that every
component of a displayed domain name has an unambiguously preferred
direction. However, this made certain words in languages written with
right-to-left scripts invalid as IDN labels, and in at least one case
meant that all the words of an entire language were forbidden as IDN
labels.</t>
<t>This is illustrated below with examples taken from the Dhivehi and
Yiddish languages, as written with the Thaana and Hebrew scripts,
respectively.</t>
<t>RFC 3454 did not explicitly state the requirement to be fulfilled.
Therefore, it is impossible to determine whether a simple relaxation
of the rule would continue to fulfil the requirement.</t>
<t>While this document specifies rules quite different from RFC 3454,
most reasonable labels that were allowed under RFC 3454 will also be
allowed under this specification (the most important example of
non-permitted labels being 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 <xref target="terminology"></xref> for
terminology), so the operational impact of using the new rule in the
updated IDNA specification is limited.</t>
</section>
<section title="Structure of the rest of this document">
<t><xref target="rule"></xref> 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. The primary initial use
of this rule is as part of the IDNA2008 protocol<xref
target="I-D.ietf-idnabis-protocol"></xref>.</t>
<t><xref target="requirement"></xref> sets out the requirements for
defining the BIDI rule.</t>
<t><xref target="issues"></xref> gives detailed examples that serve as
justification for the new rule.</t>
<t><xref target="trouble"></xref> to <xref target="Security"></xref>
describe various situations that can occur when dealing with domain
names with characters of different directionality.</t>
<t>Only <xref target="terminology"></xref> and <xref
target="rule"></xref> are normative.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The terminology used to describe IDNA concepts is defined in <xref
target="I-D.ietf-idnabis-defs"></xref></t>
<t>The terminology used for the BIDI properties of Unicode characters
is taken from the Unicode Standard<xref target="Unicode">.</xref></t>
<t>The Unicode standard specifies a BIDI property for each character,
which controls the character's behaviour in the Unicode bidirectional
algorithm <xref target="UAX9"></xref>. For reference, here are the
values that the Unicode BIDI property can have: <list style="symbols">
<t>L - Left-to-right - most letters in LTR scripts</t>
<t>R - Right-to-left - most letters in non-Arabic RTL scripts</t>
<t>AL - Arabic letters - most letters in the Arabic script</t>
<t>EN - European Number (0-9, and Extended Arabic-Indic
numbers)</t>
<t>ES - European Number Separator (+ and -)</t>
<t>ET - European Number Terminator (currency symbols, the hash
sign, the percent sign and so on)</t>
<t>AN - Arabic Number; this encompasses the Arabic-Indic numbers,
but not the Extended Arabic-Indic numbers</t>
<t>CS - Common Number Separator (. , / : et al)</t>
<t>NSM - Non spacing Mark - most combining accents</t>
<t>BN - Boundary Neutral - control characters (ZWNJ, ZWJ and
others)</t>
<t>B - Paragraph Separator</t>
<t>S - Segment Separator</t>
<t>WS - Whitespace, including the SPACE character</t>
<t>ON - Other Neutrals, including @, &, parentheses, MIDDLE
DOT</t>
<t>LRE, LRO, RLE, RLO, PDF - these are "directional control
characters", and are not used in IDNA labels.</t>
</list></t>
<t>In this memo, we use "network order" to describe the sequence of
characters as transmitted on the wire or stored in a file; the terms
"first", "next", "previous", "beginning", "end", "before" and "after"
are used to refer to the relationship of characters and labels in
network order.</t>
<t>We use "display order" to talk about the sequence of characters as
imaged on a display medium; the terms "left" and "right" are used to
refer to the relationship of characters and labels in display
order.</t>
<t>Most of the time, the examples use the abbreviations for the
Unicode BIDI classes to denote the directionality of the characters;
the example string CS L consists of one character of class CS and one
character of class L. In some examples, the convention that uppercase
characters are of class R or AL, and lowercase characters are of class
L is used - thus, the example string ABC.abc would consist of 3
right-to-left characters and 3 left-to-right characters.</t>
<t>The directionality of such examples is determined by context - for
instance, in the sentence "ABC.abc is displayed as CBA.abc", the first
example string is in network order, the second example string is in
display order.</t>
<t>The term "paragraph" is used in the sense of the Unicode BIDI
specification <xref target="UAX9"></xref> - it means "a block of text
that has an overall direction, either left-to-right or right-to-left",
approximately; see UAX 9 for the details.</t>
<t>"RTL" and "LTR" are abbreviations for "right to left" and "left to
right", respectively.</t>
<t>An RTL label is a label that contains at least one character of
type R, AL or AN.</t>
<t>An LTR label is any label that is not an RTL label.</t>
<t>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. Providing a separate category
of "RTL domain names" would not make this specification simpler, so
has not been done.)</t>
</section>
</section>
<section anchor="rule" title="The BIDI Rule">
<t>The following rule, consisting of six conditions, applies to labels
in BIDI domain names. The requirements that this rule satisfies are
described in <xref target="requirement"></xref>. All the conditions must
be satisfied for the rule to be satisfied.</t>
<t><list style="numbers">
<t>The first character must be a character with BIDI property L, R
or AL. If it has the R or AL property, it is an RTL label; if it has
the L property, it is an LTR label.</t>
<t>In an RTL label, only characters with the BIDI properties R, AL,
AN, EN, ES, CS, ET, ON, BN and NSM are allowed.</t>
<t>In an RTL label, the end of the label must be a character with
BIDI property R, AL, EN or AN, followed by zero or more characters
with BIDI property NSM.</t>
<t>In an RTL label, if an EN is present, no AN may be present, and
vice versa.</t>
<t>In an LTR label, only characters with the BIDI properties L, EN,
ES, CS. ET, ON, BN and NSM are allowed.</t>
<t>In an LTR label, the end of the label must be a character with
BIDI property L or EN, followed by zero or more characters with BIDI
property NSM.</t>
</list>The following guarantees can be made based on the above:</t>
<t><list style="symbols">
<t>In a domain name consisting of only labels that satisfy the rule,
the requirements of <xref target="requirement"></xref> are
satisfied. Note that even LTR labels and pure ASCII labels have to
be tested.</t>
<t>In a domain name consisting of only LDH-labels and labels that
satisfy the rule, the requirements of <xref
target="requirement"></xref> are satisfied as long as a label that
starts with an ASCII digit does not come after a right-to-left
label.</t>
</list>No guarantee is given for other combinations.</t>
</section>
<section anchor="requirement"
title="The requirement set for the BIDI rule">
<t>This document, unlike RFC 3454, proposes an explicit justification
for the BIDI rule, and states a set of requirements for which it is
possible to test whether or not the modified rule fulfils the
requirement.</t>
<t>All the text in this document assumes that text containing the labels
under consideration will be displayed using the Unicode bidirectional
algorithm <xref target="UAX9"></xref>.</t>
<t>The requirements proposed are these:<list style="symbols">
<t>Label Uniqueness: No two labels, when presented 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, both when the paragraph has LTR direction and when the
paragraph has RTL direction. (This is the criterion that is explicit
in RFC 3454). (Note that a label displayed in an RTL paragraph may
display the same as a different label displayed in an LTR paragraph,
and still satisfy this criterion.)</t>
<t>Character Grouping: When displaying a string of labels, using the
Unicode BIDI algorithm to reorder the characters for display, the
characters of each label should remain grouped between the
characters delimiting the labels, both when the string is embedded
in a paragraph with LTR direction and when it is embedded in a
paragraph with RTL direction.</t>
</list></t>
<t>Several stronger statements were considered and rejected, because
they seem to be impossible to fulfil within the constraints of the
Unicode bidirectional algorithm. These include:</t>
<t><list style="symbols">
<t>The appearance of a label should be unaffected by its embedding
context. This proved impossible even for ASCII labels; the label
"123-A" will have a different display order in an RTL context than
in an LTR context. (This particular example is, however, disallowed
anyway.)</t>
<t>The sequence of labels should be consistent with network order.
This proved impossible - a domain name consisting of the labels (in
network order) L1.R1.R2.L2 will be displayed as L1.R2.R1.L2 in an
LTR context. (In an RTL context, it will be displayed as
L2.R2.R1.L1).</t>
<t>No two domain names should be displayed the same, even under
differing directionality. This was shown to be unsound, since the
domain name (in network order) ABC.abc will have display order
CBA.abc in an LTR context and abc.CBA in an RTL context, while the
domain name (network) abc.ABC will have display order abc.CBA in an
LTR context and CBA.abc in an RTL context.</t>
</list></t>
<t>One possible requirement was thought to be problematic, but turned
out to be satisfied by a string that obeys the proposed rules:</t>
<t><list style="symbols">
<t>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). Because these controls affect
presentation order in non-obvious ways, by affecting the "sor" and
"eor" properties of the Unicode BIDI algorithm, the conditions above
require extra testing in order to figure out whether or not 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.</t>
</list></t>
<t>This is still not stated as a requirement, since it did not seem as
important as those stated, but it is useful to know that BIDI domain
names where the labels satisfy the rule have this propierty.</t>
<t>In the following descriptions, first-level bullets are used to
indicate rules or normative statements; second-level bullets are
commentary.</t>
<t>The Character Grouping requirement can be more formally stated
as:<list style="symbols">
<t>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.) <list style="symbols">
<t>ET, though it commonly occurs next to domain names in
practice, is problematic: the context R CS L EN ET (for instance
A.a1%) makes the label L EN not satisfy the character grouping
requirement.</t>
<t>ES commonly occurs in labels as HYPHEN-MINUS, but could also
be used as a delimiter (for instance, the plus sign). It is left
out here.</t>
</list></t>
<t>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".)</t>
</list></t>
<t>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:</t>
<t>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, both if the overall paragraph direction is LTR
and if the overall paragraph direction is RTL.</t>
<t>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 does not create problems for
testing whether or not a given proposed rule satisfies the
criterion.</t>
<t>The "zero-length" case represents the case where a domain name is
next to something that isn't a domain name, separated by a delimiter
character.</t>
<t>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, and are therefore treated as if removed
during BIDI processing (<xref target="UAX9"></xref> section 3.3.2 rule
X9 and section 5.3). Therefore, the question of "what position does a BN
have after reordering" is not meaningful. It has been ignored while
developing the rules here.</t>
<t>The Label Uniqueness requirement can be formally stated as:</t>
<t>If two non-identical labels X and Y, embedded as for the test above,
displayed in paragraphs with the same directionality, are reordered by
the BIDI algorithm into the same sequence of codepoints, the labels X
and Y cannot both be legal.</t>
</section>
<section anchor="issues" title="Examples of issues found with RFC 3454">
<section title="Dhivehi">
<t>Dhivehi, the official language of the Maldives, is written with the
Thaana script. This displays some of the characteristics of Arabic
script, including its directional properties, and the indication of
vowels by the diacritical marking of consonantal base characters. This
marking is obligatory, and both two consecutive vowels and
syllable-final consonants are indicated with unvoiced combining marks.
Every Dhivehi word therefore ends with a combining mark.</t>
<t>The word for "computer", which is romanized as "konpeetaru", is
written with the following sequence of Unicode code points:</t>
<t><list>
<t>U+0786 THAANA LETTER KAAFU (AL)</t>
<t>U+07AE THAANA OBOFILI (NSM)</t>
<t>U+0782 THAANA LETTER NOONU (AL)</t>
<t>U+07B0 THAANA SUKUN (NSM)</t>
<t>U+0795 THAANA LETTER PAVIYANI (AL)</t>
<t>U+07A9 THAANA LETTER EEBEEFILI (AL)</t>
<t>U+0793 THAANA LETTER TAVIYANI (AL)</t>
<t>U+07A6 THAANA ABAFILI (NSM)</t>
<t>U+0783 THAANA LETTER RAA (AL)</t>
<t>U+07AA THAANA UBUFILI (NSM)</t>
</list></t>
<t>The directionality class of U+07AA in the Unicode database <xref
target="Unicode"></xref> is NSM (non-spacing mark), which is not R or
AL; a conformant implementation of the IDNA2003 algorithm will say
that "this is not in RandALCat", and refuse to encode the string.</t>
</section>
<section title="Yiddish">
<t>Yiddish is one of several languages written with the Hebrew script
(others include Hebrew and Ladino). This is basically a consonantal
alphabet (also termed an "abjad") but Yiddish is written using an
extended form that is fully vocalic. The vowels are indicated in
several ways, of which one is by repurposing letters that are
consonants in Hebrew. Other letters are used both as vowels and
consonants, with combining marks, called "points", used to
differentiate between them. Finally, some base characters can indicate
several different vowels, which are also disambiguated by combining
marks. Pointed characters can appear in word-final position and may
therefore also be needed at the end of labels. This is not an
invariable attribute of a Yiddish string and there is thus greater
latitude here than there is with Dhivehi.</t>
<t>The organization now known as the "YIVO Institute for Jewish
Research" developed orthographic rules for modern Standard Yiddish
during the 1930s on the basis of work conducted in several venues
since earlier in that century. These are given in, "The Standardized
Yiddish Orthography: Rules of Yiddish Spelling" <xref
target="SYO"></xref>, and are taken as normatively descriptive of
modern Standard Yiddish in any context where that notion is deemed
relevant. They have been applied exclusively in all formal Yiddish
dictionaries published since their establishment, and are similarly
dominant in academic and bibliographic regards.</t>
<t>It therefore appears appropriate for this repertoire also to be
supported fully by IDNA. This presents no difficulty with characters
in initial and medial positions, but pointed characters are regularly
used in final position as well. All of the characters in the SYO
repertoire appear in both marked and unmarked form with one exception:
the HEBREW LETTER PE (U+05E4). The SYO only permits this with a HEBREW
POINT DAGESH (U+05BC), providing the Yiddish equivalent to the Latin
letter "p", or a HEBREW POINT RAFE (U+05BF), equivalent to the Latin
letter "f". There is, however, a separate unpointed allograph, the
HEBREW LETTER FINAL PE (U+05E3), for the latter character when it
appears in final position. The constraint on the use of the SYO
repertoire resulting from the proscription of combining marks at the
end of RTL strings thus reduces to nothing more, or less, than the
equivalent of saying that a string of Latin characters cannot end with
the letter "p". It must also be noted that the HEBREW LETTER PE with
HEBREW POINT DAGESH is characteristic of almost all traditional
Yiddish orthographies that predate (or remain in use in parallel to)
the SYO, being the first pointed character to appear in any of
them.</t>
<t>A more general instantiation of the basic problem can be seen in
the representation of the YIVO acronym. This is written with the
Hebrew letters YOD YOD HIRIQ VAV VAV ALEF QAMATS, where HIRIQ and
QAMATS are combining points: <list>
<t>U+05D9 HEBREW LETTER YOD (R)</t>
<t>U+05B4 HEBREW POINT HIRIQ (NSM)</t>
<t>U+05D5 HEBREW LETTER VAV (R)</t>
<t>U+05D0 HEBREW LETTER ALEF (R)</t>
<t>U+05B8 HEBREW POINT QAMATS (NSM)</t>
</list> The directionality class of U+05B8 HEBREW POINT QAMATS in
the Unicode database is NSM, which again causes the IDNA2003 algorithm
to reject the string.</t>
<t>It may also be noted that all of the combined characters mentioned
above exist in precomposed form at separate positions in the Unicode
chart. However, by invoking Stringprep, the IDNA2003 algorithm also
rejects those codepoints, for reasons not discussed here.</t>
</section>
<section title="Strings with numbers">
<t>By requiring that the first or last character of a string be
category R or AL, RFC 3454 prohibited a string containing
right-to-left characters from ending with a number.</t>
<t>Consider the strings ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE) and 5
ALEF. Displayed in an LTR context, the first one will be displayed
from left to right as 5 ALEF (with the 5 being considered
right-to-left because of the leading ALEF), while 5 ALEF will be
displayed in exactly the same order (5 taking the direction from
context). Clearly, only one of those should be permitted as a
registered label, but barring them both seems unnecessary.</t>
</section>
</section>
<section anchor="trouble" title="Troublesome situations and guidelines">
<t>There are situations in which labels that satisfy the rule above will
be displayed in a surprising fashion. The most important of these is the
case where a label ending in a character with BIDI property AL, AN or R
occurs before a label beginning with a character of BIDI property EN. In
that case, the number will appear to move into the label containing the
right-to-left character, violating the Character Grouping
requirement.</t>
<t>If the label that occurs after the right-to-left label itself
satisfies the BIDI criterion, the requirements will be satisfied in all
cases (this is the reason why the criterion talks about strings
containing L in some cases). However, the WG concluded that this could
not be required for several reasons:</t>
<t><list style="symbols">
<t>There is a large current deployment of ASCII domain names
starting with digits. These cannot possibly be invalidated.</t>
<t>Domain names are often constructed piecemeal, for instance by
combining a string with the content of a search list. This may occur
after IDNA processing, and thus in part of the code that is not
IDNA-aware, making detection of the undesirable combination
impossible.</t>
<t>Even if a label is registered under a "safe" label, there may be
a DNAME <xref target="RFC2672"></xref> with an "unsafe" label that
points to the "safe" label, thus creating seemingly-valid names that
would not satisfy the criterion.</t>
<t>Wildcards create the odd situation where a label is "valid" (can
be looked up successfully) without the zone owner knowing that this
label exists. So an owner of a zone whose name starts with a digit
and contains a wildcard has no way of controlling whether or not
names with RTL labels in them are looked up in his zone.</t>
</list>Rather than trying to suggest rules that disallow all such
undesirable situations, this document merely warns about the
possibility, and leaves it to application developers to take whatever
measures they deem appropriate to avoid problematic situations.</t>
</section>
<section title="Other issues in need of resolution">
<t>This document concerns itself only with the rules that are needed
when dealing with domain names with characters that have differing BIDI
properties, and considers characters only in terms of their BIDI
properties. All other issues with scripts that are written from right to
left must be considered in other contexts.</t>
<t>One such issue is the need to keep numbers separate. Several scripts
are used with multiple sets of numbers - most commonly they use Latin
numbers and a script-specific set of numbers, but in the case of Arabic,
there are 2 sets of "Arabic-Indic" digits involved.</t>
<t>The algorithm in this document disallows occurrences of AN-class
characters ("Arabic-Indic digits", U+0660 to U+0669) together with
EN-class characters (which includes "European" digits, U+0030 to U+0039
and "extended Arabic-Indic digits", U+06F0 to U+06F9), but does not help
in preventing the mixing of, for instance, Bengali digits (U+09E6 to
U+09EF) and Gujarati digits (U+0AE6 to U+0AEF), both of which have BIDI
class L. A registry or script community that wishes to create rules
restricting the mixing of digits in a label will be able to specify
these restrictions at the registry level. Some rules are also specified
at the protocol level.</t>
<t>Another set of issues concerns the proper display of IDNs with a
mixture of LTR and RTL labels, or only RTL labels.</t>
<t>It is unrealistic to expect that applications will display domain
names using embedded formatting codes between their labels (for one
thing, no reliable algorithms for identifying domain names in running
text exist); thus, the display order will be determined by the BIDI
algorithm. Thus, a sequence (in network order) of R1.R2.ltr will be
displayed in the order 2R.1R.ltr in an LTR context, which might surprise
someone expecting to see labels displayed in hierarchical order. People
used to working with text that mixes LTR and RTL strings might not be so
surprised by this. Again, this memo does not attempt to suggest a
solution to this problem.</t>
</section>
<section title="Compatibility considerations">
<t></t>
<section title="Backwards compatibility considerations">
<t>As with any change to an existing standard, it is important to
consider what happens with existing implementations when the change is
introduced. Some troublesome cases include:</t>
<t><list style="symbols">
<t>Old program used to input the newly-allowed label. If the old
program checks the input against RFC 3454, some labels will not be
allowed, and domain names containing those labels will remain
inaccessible.</t>
<t>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.</t>
<t>Old program tries to display the newly-allowed label. If the
old program has code for displaying the last character of a label
that is different from the code used to display the characters in
the middle of the label, the display may be inconsistent and cause
confusion.</t>
</list></t>
<t>One particular example of the last case is if a program chooses to
examine the last character (in network order) of a string in order to
determine its directionality, rather than its first. If it finds an
NSM character and tries to display the string as if it was a
left-to-right string, the resulting display may be interesting, but
not useful.</t>
<t>The editors believe that these cases will have 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.</t>
<t>This specification does not forbid using leading European digits in
ASCII-only labels, since this would conflict with a large installed
base of such labels, and would increase the scope of the specification
from RTL labels to all labels. The harm resulting from this limitation
of scope is described in <xref target="trouble"></xref>. Registries
and private zone managers can check for this particular condition
before they allow registration of any RTL label. Generally it is best
to disallow registration of any right-to-left strings in a zone where
the label at the level above begins with a digit.</t>
</section>
<section title="Forward compatibility considerations">
<t>This text is intentionally specified strictly in terms of the
Unicode BIDI properties. The determination that the condition is
sufficient to fulfil the criteria depends on the Unicode BIDI
algorithm; it is unlikely that drastic changes will be made to this
algorithm.</t>
<t>However, the determination of validity for any string depends on
the Unicode BIDI property values, which are not declared immutable by
the Unicode Consortium. Furthermore, the behaviour of the algorithm
for any given character is likely to be linguistically and culturally
sensitive, so that while it should occur rarely, it is possible that
later versions of the Unicode standard may change the BIDI properties
assigned to certain Unicode characters.</t>
<t>This memo does not propose a solution for this problem.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The new IDNA protocol, and particularly these new BIDI rules, will
allow some strings to be used in IDNA contexts that are not allowed
today. It is possible that differences in the interpretation of labels
between implementations of IDNA2003 and IDNA2008 could pose a security
risk, but it is difficult to envision any specific instantiation of
this.</t>
<t>Any rational attempt to compute, for instance, a hash over an
identifier processed by IDNA would use network order for its
computation, and thus be unaffected by the new rules proposed here.</t>
<t>While it is not believed to pose a problem, if display routines had
been written with specific knowledge of the RFC 3454 IDNA prohibitions,
it is possible that the potential problems noted under "backwards
compatibility" could cause new kinds of confusion.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>While the listed editors held the pen, this document represents the
joint work and conclusions of an ad hoc design team. In addition to the
editors this consisted of, in alphabetic order, Tina Dam, Patrik
Faltstrom, and John Klensin. Many further specific contributions and
helpful comments were received from the people listed below, and others
who have contributed to the development and use of the IDNA
protocols.</t>
<t>The particular formulation of the BIDI rule in section 2 was
suggested by Matitiahu Allouche.</t>
<t>The team wishes in particular 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,
and Marcos Sanz, Andrew Sullivan and Pete Resnick for reviews.</t>
</section>
</middle>
<back>
<references title="Normative references">
<reference anchor="UAX9">
<front>
<title>Unicode Standard Annex #9: The Bidirectional Algorithm,
revision 19</title>
<author fullname="Mark Davis" initials="M." surname="Davis">
<organization>Unicode Consortium</organization>
</author>
<date day="21" month="03" year="2008" />
</front>
</reference>
<reference anchor="Unicode">
<front>
<title>The Unicode Standard - version 5.1</title>
<author fullname="Unicode Consortium" surname="Unicode">
<organization></organization>
</author>
<date year="2008" />
</front>
</reference>
<?rfc include='reference.I-D.draft-ietf-idnabis-defs-10'?>
</references>
<references title="Informative references">
<?rfc include='reference.RFC.3454'?>
<?rfc include='reference.RFC.2672'?>
<?rfc include='reference.I-D.draft-ietf-idnabis-protocol-14'?>
<reference anchor="SYO">
<front>
<title>The Standardized Yiddish Orthography: Rules of Yiddish
Spelling, 6th ed., , New York, ISBN 0-914512-25-0",</title>
<author fullname="YIVO Institute for Jewish Research">
<organization></organization>
</author>
<date year="1999" />
</front>
</reference>
</references>
<section title="Change log">
<t>This appendix is intended to be removed by the RFC Editor when this
document is published as an RFC.</t>
<section title="Changes from draft-alvestrand-00 to -01">
<t>Suggested a possible new algorithm.</t>
<t>Multiple smaller changes.</t>
</section>
<section title="Changes from alvestrand-01 to -02">
<t>Date of publication updated.</t>
<t>Change log added.</t>
</section>
<section title="Changes from alvestrand-02 to -03">
<t>Intro changed to reflect addressing the deeper issues with the BIDI
algorithm.</t>
<t>Gave formalized criteria for "valid strings", and documented the
new set of requirements for strings that satisfy the criteria.</t>
<t>Removed most of section 5, "Other problems", and noted that this
memo focuses ONLY on issues that can be evaluated by looking at the
BIDI properties of characters.</t>
</section>
<section title="Changes from alvestrand-03 to -04">
<t>Added back AN to the list of allowed characters; it had been left
out by accident in -03.</t>
<t>Removed some rules that were redundant.</t>
<t>Added some considerations for backwards compatibility and
interaction with ASCII labels that start with a number.</t>
<t>Mentioned the issue with DNAME pointing to a zone containing RTL
labels in the security considerations section.</t>
<t>Wording updates in multiple places, including some spelling
errors.</t>
<t>Rewrote the introduction section.</t>
<t>Split references into "normative" and "informative".</t>
</section>
<section title="Changes from draft-alvestrand-04 to draft-ietf -00">
<t>Changed name of draft.</t>
<t>Added a couple of "note in draft" statements to remind the WG of
open issues.</t>
<t>Noted that BIDI controls in the paragraph are unproblematic with
the given ruleset.</t>
</section>
<section title="Changes from idnabis -00 to -01">
<t>Added text to section 5 describing issues with mixture of numbers
in labels</t>
<t>Addressed some of the issues raised by Mark Davis in March 2008 in
regard to document clarity.</t>
<t>Changed the formulation of the label uniqueness requirement to be
consistent with the text under "Labels with numbers".</t>
<t>Spell-checked document.</t>
</section>
<section title="Changes from idnabis -01 to -02">
<t>Changed the domain of applicability to be only labels containing
RTL characters, described the conditions under which harm may result
from putting RTL labels next to other labels, and how to detect
them.</t>
<t>A number of clarification and formatting changes in response to
reviews.</t>
</section>
<section title="Changes from idnabis -02 to -03">
<t>Rearranged section list so that the normative material is collected
at the front.</t>
<t>Moved list of BIDI properties into "terminology"</t>
<t>Clarified that only terminology and the BIDI rule is normative</t>
<t>Changed reference to point to -defs for definitions instead of
-rationale</t>
<t>Minor fixes in response to comments, wording cleanups, removed all
tentative language.</t>
</section>
<section title="Changes from idnabis -03 to -04">
<t>Updated to new IPR rules.</t>
<t>Minor textual clarifications.</t>
<t>Replaced the BIDI test with a version suggested by Matitiahu
Allouche - this description is simpler to understand than the one in
-03, and generates a larger set of allowable strings, while all tests
indicate that they still pass all the criteria.</t>
</section>
<section title="Changes from idnabis -04 to -05">
<t>Minor textual clarifications resulting from WG Last Call. No
technical changes.</t>
<t>Updated UAX9 reference to Unicode 5.1 version.</t>
<t>Made better use of some terminology, and clarified the relationship
with RFC 3454 based on input from Paul Hoffman.</t>
<t>Added examples of newly-forbidden labels, based on advice from
Andrew Sullivan</t>
<t></t>
</section>
<section title="Changes from idnabis -05 to -06">
<t>Most of these changes are based on a review by Martin Duerst.</t>
<t>Rewrote abstract.</t>
<t>Changed "test" to "rule" throughout, with accompanying minor
tweaks</t>
<t>Re-allowed BN in LTR labels (error introduced in -04).</t>
<t>Added words to explain role of BN more (in the requirements
section).</t>
<t>Modified the words about the effect of BIDI changes after having
reassurance that changes are likely to be rare.</t>
<t>Minor textual fixes.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2024 | 2024-05-13 23:41:42 |