WDIFF

draft-alvestrand-idna-bidi-02.txt --> draft-alvestrand-idna-bidi-03.txt

Network Working Group H. Alvestrand, Ed.
Internet-Draft Google
Intended status: Standards Track C. Karp, Ed.
Expires: July 12, 30, 2008 Swedish Museum of Natural History
Jan 9, 27, 2008

An updated IDNA problem in criterion for right-to-left scripts
draft-alvestrand-idna-bidi-02
draft-alvestrand-idna-bidi-03

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 12, 30, 2008.

Abstract

The use of right-to-left scripts in internationalized domain names
has presented several challenges. This memo discusses some problems
with these scripts, including one resulting from a constraint on the
use of combining characters at the end of an RTL domain label,
causing some words to be declared invalid as IDN labels, and some shortcomings in the 2003 IDNA BIDI
criterion. Based on this discussion, it proposes a means new BIDI
criterion for ameliorating this problem. IDNA labels.

Alvestrand & Karp Expires July 12, 30, 2008 [Page 1]

Internet-Draft IDNA RTL fix Jan 2008

Table of Contents

1. Introduction and problem description . . . . . . . . . . . . . 3
2. Detailed examples . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Dhivehi . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Yiddish . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Strings with numbers . . . . . . . . . . . . . . . . . . . 5 6
3. An expanded justification for the bidi rule . . . . . . . . . 6
4. Modification to A replacement for the RFC 3454 criterion . . . . . . . . . . . 9
5. Other issues in need of resolution . . . . . . . . 6
4.1. Alternative approach . . . . . . 11
6. Compatibility considerations . . . . . . . . . . . . . 7
5. Other issues in need of resolution . . . . 11
6.1. Backwards compatibility considerations . . . . . . . . . . 8
6. Backwards compatibility 11
6.2. Forward compatibiltiy considerations . . . . . . . . . . . . 9 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 13
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 13
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11 13
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 11 13
A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 14
Intellectual Property and Copyright Statements . . . . . . . . . . 13 15

Alvestrand & Karp Expires July 12, 30, 2008 [Page 2]

Internet-Draft IDNA RTL fix Jan 2008

1. Introduction and problem description

The IDNA specification "Stringprep", [RFC3454] makes the following
statement in its section 6 on 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 prohibition was to ensure that every
component of a visually presented displayed domain name has an unambiguously preferred
direction. However, this makes certain words in languages written
with right-to-left scripts invalid as IDN labels, and in at least one
case means that all the words of an entire language are forbidden as
IDN labels.

This will be illustrated below with examples taken from the Dhivehi
and Yiddish languages, as written with the Thaana and Hebrew scripts,
respectively.

The problem may be addressed by more carefully considering

In investigating this problem, it was realized that the bidi
algorithm in Unicode Standard Annex #9 [UAX9] which states in section
3.3.3 W1: "Examine each non-spacing mark (NSM) in RFC 3454
specification did not exactly specify what the level run, requirement to be
fulfilled was, and
change the type therefore, it was impossible to tell whether a
simple relaxation of the NSM rule would continue to fulfil the type of
requirement. A further investigation led to the previous character."
(See below conclusion that for some terminology).

Section 3
one reasonable set of UAX9 contains several instructions for determining requirements, IDNA2003's BIDI restriction did
not fulfil the
directionality of requirements. This document therefore proposes
replacing the characters RFC 3454 BIDI requirement in a string. Some of them (for
instance those using explicit embedding) are irrelevant to IDNA
because its entirety.

While the corresponding codes are not permitted as IDNA input, so a
slightly simplified version should document proposes completely new text, most reasonable
labels that were allowed under the old criterion will also be enough for IDNA purposes. allowed
under the new criterion, so the operational impact of the rule change
is limited.

A note on terminology:

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" and "previous" are used to refer to the relationship
of characters in network order.

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 in display order.

Alvestrand & Karp Expires July 12, 30, 2008 [Page 3]

Internet-Draft IDNA RTL fix Jan 2008

2. Detailed examples

2.1. Dhivehi

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 double vowels and syllable-final
consonants are indicated by the marking of special unvoiced
characters. Every Dhivehi word therefore 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 THANAA UBIUFILI (NSM)

The directionality class of U+07AA in the Unicode database is NSM
(non-spacing mark), which is not R or AL; a conformant implementation
of the IDNA algorithm will say that "this is not in RandALCat", and
refuse to encode the string.

2.2. Yiddish

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 used to

Alvestrand & Karp Expires July 12, 30, 2008 [Page 4]

Internet-Draft IDNA RTL fix Jan 2008

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. Marked 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 all a Yiddish strings string and there is thus
greater latitude here than there is with Dhivehi.

The organization now known as the "YIVO Institute for Jewish
Research" is widely known by developed orthographic rules for modern Standard Yiddish
during the 1930s on the
acronym basis of its work conducted in several venues
since earlier in that century. These are given in, "The Standardized
Yiddish name. This organization maintains a primary
reference standard Orthography: Rules of Yiddish Spelling, 6th ed., YIVO
Institute for Jewish Research, New York, 1999, ISBN 0-914512-25-0",
("SYO") and are taken as normatively descriptive of modern Standard
Yiddish orthography, in any context where that notion is deemed relevant. They
have been applied exclusively in all Yiddish dictionaries published
since their establishment, and are similarly dominant in academic and
bibliographic regards.

It therefore appears appropriate for this repertoire also commonly referred 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 same acronym (as 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.

A more general instantiation of the basic problem can be seen in the
representation of the "YIVO Rules"). YIVO acronym. This is written with the Hebrew
letters YOD YOD HIRIQ VAV VAV ALEF QAMATS, where HIRIQ and QAMATS are
combining "points": points:

U+05D9 HEBREW LETTER YOD (R)

Alvestrand & Karp Expires July 30, 2008 [Page 5]

Internet-Draft IDNA RTL fix Jan 2008

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, which again causes the IDNA IDNA2003 algorithm to reject
the string. (It

It may also be noted that all of the requisite combined characters
also mentioned
above exist in precomposed form at separate positions in the Unicode
chart. However, Stringprep by invoking Stringprep, the IDNA2003 algorithm also
rejects those codepoints, for reasons not discussed here.) here.

2.3. Strings with numbers

RFC 3454, in its insistence that the first or last character of a
string be category R or AL, prohibited strings that contained right-
to-left characters and numbers. numbers at the end.

Considering the string strings ALEF 5 (HEBREW LETTER ALEF + DIGIT FIVE), if
we specify that UAX#9 is used to find FIVE and 5
ALEF. Displayed in a LTR context, the directionality of
characters, this string first one will have a consistent direction (R).
However, be displayed
from left to right as 5 ALEF (with the string 5 ALEF, when embedded in an LTR context, being considered right-to-
left because of the leading ALEF), while 5 ALEF will
have be displayed in
exactly the same display order, with a different direction assigned to order (5 taking the number 5. These two display strings are confusable, so we need a
rule that permits direction from context).
Clearly, only one of these in those should be permitted as a domain name registered label.

Alvestrand & Karp Expires July 12, 2008 [Page 5]

Internet-Draft IDNA RTL fix Jan 2008

3. An expanded justification for the bidi rule

One issue with RFC 3454 was that it did not give an explicit
justification for the bidi rule, thus it was hard to tell if a
modified rule would continue to fulfil the purpose for which the RFC
3454 rule was written.

This document proposes an explicit justification, by stating a set of
requirements for which we think it is possible to test whether or not
the modified rule fulfils the
justification. requirement.

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

The justification proposed is this:

Alvestrand & Karp Expires July 30, 2008 [Page 6]

Internet-Draft IDNA RTL fix Jan 2008

o No two labels, when presented in visual display order, should have the
same sequence of characters without also having the same sequence
of characters in network order. (This is the criterion that is
explicit in RFC 3454).

o In a visual presentation display of a string of labels, the characters of each label
should remain grouped between the dots characters delimiting the label
components.

o This property These properties should hold true both when the string is embedded
in a RTL context paragraph with LTR direction and when it's embedded in a LTR context.

o This property should hold true without adding extra formatting,
for example bidi control characters, to
paragraph with RTL direction, as long as explicit directional
controls are not used within the string. same paragraph.

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:

o The appearance of a label should be unaffected by its embedding
context. This proved impossible even for ASCII labels; the label
"123-456" will have a different display order in a RTL context
than in a LTR context.

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

4. Modification to RFC 3454

o The "remain grouped" property should remain true when directional
controls (LRE, RLE, RLO, LRO, PDF) are used in the following modification is made to RFC 3454 section 6, same paragraph 4, we believe that the usefulness
(outside of the specification for
languages written with right-to-left scripts will be significantly

Alvestrand & Karp Expires July 12, 2008 [Page 6]

Internet-Draft IDNA RTL fix Jan 2008

improved:

Old text:

[Unicode3.2] defines several bidirectional categories; each
character has one bidirectional category assigned to it. For labels). Because these controls affect
presentation order in non-obvious ways, by affecting the
purposes "sor" and
"eor" properties of the requirements below, an "RandALCat character" is a
character that has Unicode bidirectional categories "R" or "AL"; BIDI algorithm, the conditions
above would be very hard to satisfy for an "LCat character" is a character that has Unicode bidirectional
category "L".

New text:

[Unicode3.2] defines several bidirectional categories; each
character has one bidirectional category assigned to it.

For characters that have category "R", "AL" or "L", the category
is fixed (UAX#9 defines them useful set of strings
if this was true. As long as having "strong" category); for
characters in category EN, ES, ET, AN, CS, NSM, BN, B, S, WS and
ON, the category is determined by applying the algorithm described
in UAX#9 section 3.3 to the string.

For these controls have no influence
over the purposes display of the requirements below, an "RandALCat
character" is a character that, after this determination, has
Unicode bidirectional categories "R" or "AL"; an "LCat character"
is a character that has Unicode bidirectional category "L".

Note that Unicode 5.0 is domain name, no problem will be caused,
but the current version of Unicode. This fix
refers to Unicode 3.2 only, exact criterion for "will not influence" is hard to maintain consistency with
codify.

o The "no two labels display the rest of
RFC 3454. Nothing here same" should affect the relationship hold true between
Unicode versions LTR
paragraphs and IDNA.

Also, as noted in the introduction, the Unicode UAX#9 algorithm is
quite complex. For the purposes of IDNA, a simpler algorithm may RTL paragraphs. This was shown to be
defind that yields the same result within the constraints of this
context, but may unsound,
since ((EXAMPLE NEEDED HERE).

o No two domain names should be easier for people displayed the same, even under
differing directionality. This was shown to implement consistently.
Such an algorithm may be included unsound, since the
domain name (network) ABC.abc will have display order CBA.abc in later versions of this memo.

4.1. Alternative approach

The editors are not entirely happy with
an LTR context and abc.CBA in an RTL context, while the text above. We are
considering, instead, a complete replacement for section 6 of RFC
3454.

A first draft of such a section is below. domain
name (network) abc.ABC will display as abc.CBA in an LTR context

Alvestrand & Karp Expires July 12, 30, 2008 [Page 7]

Internet-Draft IDNA RTL fix Jan 2008

Conceptually, to verify suitability

and as CBA.abc in a domain name label, one
constructs the string consisting of RTL context.

For reference, here are the label preceded and followed
by a full stop (U+002E), and executes values that the Unicode bidirectional
algorithm twice, once with <sor> (start of run) BIDI property can
have:

o L - Left-to-right - most letters in LTR scripts

o R - Right-to-left - most letters in non-Arabic RTL scripts

o AL - Arabic letters - most letters in the Arabic script

o EN - European Number (0-9)

o ES - European Number Separator (+ and -)

o ET - European Number Terminator (currency symbols, the hash sign,
the percent sign and so on)

o AN - Arabic Number

o CS - Common Number Separator (. , / : et al)

o NSM - Nonspacking Mark - most combining accents

o BN - Boundary Neutral - control characters

o B - Paragraph Separator

o S - Segment Separator

o WS - Whitespace, including the SPACE character

o ON - Other Neutrals, including @, &, parentheses, MIDDLE DOT

o LRE, LRO, RLE, RLO, PDF - these are "directional control
characters", and <eor> (end are not used in IDNA labels.

The "remain grouped" property can be more formally stated as:

o Let "Delimiterchars" be a set of
run) having direction characters with the Unicode BIDI
properties CS, WS, ON

* ET, which 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 grow unstable.

* ES commonly occurs in labels as HYPHEN-MINUS, but could also be
used as a delimiter (for instance, the plus sign). It is left

Alvestrand & Karp Expires July 30, 2008 [Page 8]

Internet-Draft IDNA RTL fix Jan 2008

out here.

o Let "Position" be the position of a character in a string (in
network order)

o Let "Bidi position" be the position computed by the Unicode Bidi
algorithm

In the paragraph containing a string formed from the substrings A B L
C D, where A and D are (possibly zero-length) legal labels, and B and
C are single "Delimiterchars", the label L is a legal label if, for
all A, B, C and D, the bidi position of all characters in L is within
the range of positions for the characters of L in the string, for
both the LTR and RTL paragraph direction.

The "No two labels" property can be formally stated as:

If two labels L and L', embedded as for the test above, displayed in
a paragraph with the same directionality, are rearranged into the
same sequence of codepoints, neither L nor L' is a legal label.

4. A replacement for the RFC 3454 criterion

A set of rules that satisfies the tests above is as follows. The
main bullets give the rule, subordinate bullets (if any) give
justifications or examples of things that break if this rule is not
present. The term "unstable" means that it fails to satisfy the
"remain grouped" property defined above.

NOTE: The "remain grouped" property has been tested exhaustively up
to 5-character strings with 0-3 character surrounding labels. The
"no two labels display the same" property has not been tested.

o Only characters with the BIDI properties L, R, AL, EN, ES, BN, ON
and once with them having direction R. (The
full stop, being of NSM are allowed.

* B, S and WS are excluded because they are separators or spaces.

* LRE, LRO, RLE, RLO, PDF are excluded because they are bidi class CS,
controls.

* ET is used excluded because it seems likely to
show up any problems, and occurs next to labels a lot of the time.
Other times, a label string L ET is adjacent to an @ sign, a space or another
character.)

The following conditions MUST be true in both resulting strings for unstable.

* CS is excluded because the string to be acceptable: L CS is unstable.

Alvestrand & Karp Expires July 30, 2008 [Page 9]

Internet-Draft IDNA RTL fix Jan 2008

o The leftmost ES and rightmost character of the resulting string in
display order must be a full stop (U+002E)

o No non-spacing mark (NSM) can occur ON are not allowed in the second first position of the
string (leftmost in L order, rightmost in

* ES R order); that is, no
mark can be allowed to attach to the delimiting characters. and ON R are both unstable.

o The direction of the leftmost ES and rightmost characters ON, followed by zero or more NSM, is not allowed in the
string (the periods) must be either
last position

* L ON and L ES are both unstable.

o If an L is present, no R, AL or R

Note that there AN may be present.

o If an R, AL or AN is present, no requirement that the character sequence L may be the
same in the two cases.

All RTL strings permitted by RFC 3454 section 6 will pass this test.
Strings that consist of such a string with NSM characters appended to
it will also pass this test.

[[NOTE: Not sure if the ALEF 5 vs 5 ALEF issue will present.

o If an EN is present, no AN may be solved by this
rule. Test needed.]]

[[NOTE: do we need present

o If an AN is present, no EN may be present

o If an AN is present, at least one R or AL must be present

* if 1 or more AN are allowed alone, AL AN, when put next to require something for the sor=L, eor=R AN,
is unstable.

* The same thing happens with AL ES AN, AL ON AN and
sor=R, eor=L cases?]]

5. Other issues in need of resolution

This AL NSM

* A BN has no influence on the Bidi algorithm, so doesn't help.

* EN is not permitted per the only issue with right-to-left scripts. Retaining
Yiddish for the purposes of further exemplification, its alphabet
includes three digraphs that can rule above.

o The first character may not be an NSM

o The first character may not be encoded an EN (European Number) or an AN
(Arabic Number).

* If the character on both as consecutive
instances sides of a CS is an EN or an AN, the
labels turn unstable.

* Some domain names where some of the two component characters, labels use leading EN and as precomposed
ligatures. One
AN may be problem-free, but there's no way of these digraphs also requires additional combined
marking. For example, the HEBREW LIGATURE YIDDISH DOUBLE VAV
(U+05F0) verifying this
while looking at a single label in isolation.

* NOTE: This is orthographically equivalent to, and typographically
utterly confusable with, a sequence of two HEBREW LETTER VAV
(U+05D5). However, restriction on ASCII labels when used together
with IDNA labels. This is a change from the ligature has no canonical decomposition and existing rules for
ASCII labels.

* We could achieve stability by barring numbers at the end of
labels, but this may be more disruptive in practice.

Alvestrand & Karp Expires July 12, 30, 2008 [Page 8] 10]

Internet-Draft IDNA RTL fix Jan 2008

is therefore preserved by the IDNA algorithm. These digraphs need to
be enumerated and the one form either made invalid for input

5. Other issues in the
IDNA context, or normalized to the other.

We believe that there is a clear likelihood need of similar issues
existing resolution

This document concerns itself only with other scripts and languages the rules that are not currently used
extensively needed
when dealing with IDNs. Careful consideration of all the languages
written in a given script, in consultation domain names with all characters that have differing
Bidi properties, and considers characters only in terms of the
corresponding speech communities, is therefore needed before we can
say their Bidi
properties. All other issues with any degree of certainty that using that script for IDNs is
unproblematic. these scripts have to be
considered in other contexts.

Another set of issues concerns the proper display of IDNs with a
mixture of LTR and RTL labels, or only RTL labels.

It is unrealistic to expect that domain names will be written using
embedded formatting codes between their labels; it is not clear to
these authors what thus, the proper display
order of will be determined by the components of bidirectional algorithm. Thus, a
domain name are if the directiion of the components
sequence (in network order) is, for instance, FirstRTL.SecondRTL.LTR - is it
LTRtsriF.LTRdnoceS.LTR or LTRdnoceS.LTRtsrif.LTR? of R1.R2.ltr will be displayed in the
order 2R.1R.ltr in a LTR context, which might surprise someone
expecting to see labels displayed in hierarchical order. Again, this
memo does not attempt to suggest a solution to this problem.

6. Compatibility considerations

6.1. Backwards compatibility considerations

As with any change to an existing standard, it is important to
consider what happens with existing implementations when the change
is introduced. The following troublesome cases have been noted:

o Old program used to input the newly allowed string. If the old
program checks the input against RFC 3454, the string will not be
allowed, and that domain name will remain inaccessible.

o Old program is asked to display the newly allowed string, and
checks it against RFC 3454 before displaying. The program will
perform some kind of fallback, most likely displaying the Punycode
form of the string.

o Old program tries to display the newly allowed string. If the old
program has code for displaying the last character of a string
that is different from the code used to display the characters in
the middle of the string, display may be inconsistent and cause
confusion.

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.

Alvestrand & Karp Expires July 12, 30, 2008 [Page 9] 11]

Internet-Draft IDNA RTL fix Jan 2008

useful.

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.

6.2. Forward compatibiltiy considerations

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.

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 it's not unlikely 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.

7. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an
RFC.

8. Security Considerations

This modification will allow some strings to be used in Stringprep
contexts that are not allowed today. It is possible that differences
in the interpretation of the specification between old and new
implementations could pose a security risk, but it is difficult to
envision any specific instantiation of this.

Any rational attempt to compute, for instance, a hash over an
identifier processed by stringprep would use network order for its
computation, and thus be unaffected by the changes proposed here.

While it is not believed to pose a problem, if display routines had
been written with specific knowledge of the current RFC 3454 Stringprep
prohibitions, it is possible that the possible problems noted under

Alvestrand & Karp Expires July 30, 2008 [Page 12]

Internet-Draft IDNA RTL fix Jan 2008

"backwards compatibility" 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. 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.

The team wishes in particular to thank Roozbeh Pournader for calling
its attention to the issue with the Thaana script, and Paul Hoffmann for
pointing out the need to be explicit about backwards compatibility considerations.

Alvestrand & Karp Expires July 12, 2008 [Page 10]

Internet-Draft IDNA RTL fix Jan 2008
considerations, and Ken Whistler for suggesting the basis of the
formalized "remain grouped" requirement.

Appendix A. Change log

This appendix is intended to be removed when this document is
published as an RFC.

A.1. Changes from -00 to -01

Suggested a possible new algorithm.

Multiple smaller changes.

A.2. Changes from -01 to -02

Date of publication updated.

Change log added.

A.3. Changes from -02 to -03

Intro changed to reflect addresing the deeper issues with the Bidi
algorithm.

Gave formalized criteria for "valid strings", and documented the new
set of requirements for strings that satisfy the criteria.

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.

Alvestrand & Karp Expires July 30, 2008 [Page 13]

Internet-Draft IDNA RTL fix Jan 2008

10. References

[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.

[UAX9] 0, Davis, M., "Unicode Standard Annex #9: The Bidirectional
Algorithm, revision 15", 03 2005.

Authors' Addresses

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

Email: harald@alvestrand.no

Alvestrand & Karp Expires July 12, 2008 [Page 11]

Internet-Draft IDNA RTL fix Jan 2008

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

Phone: +46 8 5195 4055
Fax:
Email: ck@nrm.museum
URI:

Alvestrand & Karp Expires July 12, 30, 2008 [Page 12] 14]

Internet-Draft IDNA RTL fix Jan 2008

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Alvestrand & Karp Expires July 12, 30, 2008 [Page 13] 15]

----