source: draft-ietf-iri-3987bis/draft-ietf-iri-bidi-guidelines.xml @ 109

Last change on this file since 109 was 109, checked in by adil@…, 8 years ago

Bump version number for next submission
take into account issues #116 and #117

File size: 21.8 KB
1<?xml version="1.0"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3<!ENTITY rfc2119 SYSTEM "">
4<!ENTITY rfc3490 SYSTEM "">
5<!ENTITY rfc3491 SYSTEM "">
6<!ENTITY rfc3987 SYSTEM "">
8<?rfc strict='yes'?>
10<?xml-stylesheet type='text/css' href='rfc2629.css' ?>
11<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
12<?rfc symrefs='yes'?>
13<?rfc sortrefs='yes'?>
14<?rfc iprnotified="no" ?>
15<?rfc toc='yes'?>
16<?rfc compact='yes'?>
17<?rfc subcompact='no'?>
18<rfc ipr="pre5378Trust200902" docName="draft-ietf-iri-bidi-guidelines-03"
19  category="bcp" xml:lang="en">
20  <front>
21    <title abbrev="Bidi IRI Guidelines">Guidelines for Internationalized
22      Resource Identifiers with Bi-directional Characters (Bidi IRIs)</title>
23    <author initials="M.J." surname="Duerst" fullname="Martin Duerst">
24      <!-- (Note: Please write "Duerst" with u-umlaut wherever
25        possible, for example as "D&#252;rst" in XML and HTML) -->
26      <organization abbrev="Aoyama Gakuin University">Aoyama Gakuin
27        University</organization>
28      <address>
29        <postal>
30          <street>5-10-1 Fuchinobe</street>
31          <city>Sagamihara</city>
32          <region>Kanagawa</region>
33          <code>229-8558</code>
34          <country>Japan</country>
35        </postal>
36        <phone>+81 42 759 6329</phone>
37        <facsimile>+81 42 759 6495</facsimile>
38        <email></email>
39        <uri><!-- (Note: This is the percent-encoded form of an IRI)--></uri>
40      </address>
41    </author>
42    <author initials="L." surname="Masinter" fullname="Larry Masinter">
43      <organization>Adobe</organization>
44      <address>
45        <postal>
46          <street>345 Park Ave</street>
47          <city>San Jose</city>
48          <region>CA</region>
49          <code>95110</code>
50          <country>U.S.A.</country>
51        </postal>
52        <phone>+1-408-536-3024</phone>
53        <email></email>
54        <uri></uri>
55      </address>
56    </author>
57    <author initials="A." surname="Allawi" fullname="Adil Allawi">
58      <organization>Diwan Software Limited</organization>
59      <address>
60        <postal>
61          <street>37-39 Peckham Road</street>
62          <city>London</city>
63          <code>SE5 8UH</code>
64          <country>United Kingdom</country>
65        </postal>
66        <phone>+44 7718 785850</phone>
67        <facsimile>+44 20 72525444</facsimile>
68        <email></email>
69        <uri></uri>
70      </address>
71    </author>
72    <date year="2012" month="March" day="13"/>
73    <area>Applications</area>
74    <workgroup>Internationalized Resource Identifiers (iri)</workgroup>
75    <keyword>IRI</keyword>
76    <keyword>Internationalized Resource Identifier</keyword>
77    <keyword>BIDI</keyword>
78    <keyword>URI</keyword>
79    <keyword>URL</keyword>
80    <keyword>IDN</keyword>
81    <abstract>
82      <t>This specification gives guidelines for selection, use, and
83        presentation of International Resource Identifiers (IRIs) which include
84        characters with inherent right-to-left (rtl) writing direction. </t>
85    </abstract>
86  </front>
87  <middle>
88    <section title="Introduction">
89      <t>Some UCS characters, such as those used in the Arabic and Hebrew
90        scripts, have an inherent right-to-left (rtl) writing direction as
91        opposed to characters, such as those in Latin scripts, that have an
92        inherent left-to-right (ltr) direction. IRIs containing rtl characters
93        (called bidirectional IRIs or Bidi IRIs) require additional attention
94        because of the non-trivial relation between their logical and visual
95        ordering. The logical order represents the order in which characters are
96        stored on computers and read by people. The visual order is the order in
97        which the characters appear (or are expected to appear) on a computer
98        display or printout.</t>
99      <t>Generally, alphabetic characters in scripts like Arabic and Hebrew are
100        drawn rtl while numbers are drawn ltr. Symbols, such as slash '/' and
101        period '.' take their visual direction from the surrounding chracters.</t>
102      <t>Because of this complex interaction between the logical representation,
103        the visual representation, and the syntax of a Bidi IRI, a balance is
104        needed between various requirements. The main requirements are: <list
105        style="hanging">
106        <t hangText="1.">user-predictable conversion between visual and logical
107          representation;</t>
108        <t hangText="2.">the ability to include a wide range of characters in
109          various parts of the IRI; and</t>
110        <t hangText="3.">minor or no changes or restrictions for
111          implementations.</t>
112        </list></t>
113      <section title="Notation">
114        <t>In this document, "Bidi Notation" is used for the given Bidi IRI
115          examples as follows: Lower case letters a-z stand for characters that
116          are written with a left to right ordering (such as Latin characters),
117          whereas upper case letters A-Z represent characters that are written
118          right to left (such as Arqbic or Hebrew characters). Numbers and
119          symbols are the same.</t>
120        <t> In this document, the key words "MUST", "MUST NOT", "REQUIRED",
122          and "OPTIONAL" are to be interpreted as described in <xref
123            target="RFC2119"/>.</t>
124      </section>
125      <!-- Notation -->
126    </section>
127    <!-- Introduction -->
128    <section title="Logical Storage and Visual Presentation" anchor="visual">
129      <t>When stored or transmitted in digital representation, Bidi IRIs MUST be
130        in full logical order and MUST conform to the IRI syntax rules (which
131        includes the rules relevant to their scheme). This ensures that
132        Bidi IRIs can be processed in the same way as other IRIs.</t>
133      <t>Bidi IRIs MUST be visually ordered by the Unicode Bidirectional
134        Algorithm <xref target="UNIV6"/>, <xref target="UNI9"/>. Bidi IRIs MUST
135        be rendered in the same way as they would be if they were in a
136        left-to-right embedding. </t>
137      <t>In conformance with the Unicode Bidirectional Algorithm, embedding MAY
138        be done in one of two ways: <list style="hanging">
139        <t hangText="1.">precede the IRI with U+202A, LEFT-TO-RIGHT EMBEDDING
140          (LRE), and follow with U+202C, POP DIRECTIONAL FORMATTING (PDF);
141          or</t>
142        <t hangText="2.">use a higher-level protocol (e.g., the dir='ltr'
143          attribute in HTML).</t>
144        </list></t>
145      <t>Preceding and following the Bidi IRI with U+200E, LEFT-TO-RIGHT MARK
146        (LRM). Is NOT RECOMMENDED as, there are cases where this may not be
147        sufficient to match full left to right embedding.</t>
148      <t>There is no requirement to use embedding if the display is still the
149        same without the embedding. For example, a Bidi IRI in a text
150        with left-to-right base directionality (such as used for English or
151        Cyrillic) that is preceded and followed by whitespace and strong
152        left-to-right characters does not need an embedding. Also, a
153        bidirectional relative IRI reference that only contains strong
154        right-to-left characters and weak characters (such as symbols) and that
155        starts and ends with a strong right-to-left character and appears in a
156        text with right-to-left base directionality (such as used for Arabic or
157        Hebrew) and is preceded and followed by whitespace and strong characters
158        does not need an embedding.</t>
159      <t>However, Implementers are, RECOMMENDED to use embedding in all cases
160        where they are not completely sure that the display behavior is
161        unaffected without the embedding.</t>
162      <t>The Unicode Bidirectional Algorithm (<xref target="UNI9"/>, section
163        4.3) permits higher-level protocols to influence bidirectional
164        rendering. Such changes by higher-level protocols MUST NOT be used if
165        they change the rendering of IRIs.</t>
166      <t>The bidirectional formatting characters that may be used before or
167        after the IRI to ensure correct display are not themselves part of the
168        IRI. IRIs MUST NOT contain bidirectional formatting characters (LRM,
169        RLM, LRE, RLE, LRO, RLO, and PDF). They affect the visual rendering of
170        the IRI but do not appear themselves. It would therefore not be possible
171        to input an IRI with such characters correctly.</t>
172    </section>
173    <!-- visual -->
174    <section title="Bidi IRI Structure" anchor="bidi-structure">
175      <t>The Unicode Bidirectional Algorithm is designed for general purpose
176        text. To make sure that it does not affect the rendering of Bidi IRIs
177        outside of the requirements of this document, some restrictions on Bidi
178        IRIs are necessary. These restrictions are given in terms of delimiters
179        (structural characters, mostly punctuation such as "@", ".", ":", and
180        "/") and components (usually consisting mostly of letters and
181        digits).</t>
182      <t>The following syntax rules from the ABNF of <xref target="RFC3987bis"/>
183        correspond to components for the purpose of Bidi behavior: iuserinfo,
184        ireg-name, isegment, isegment-nz, isegment-nz-nc, ireg-name, iquery, and
185        ifragment.</t>
186      <t>Specifications that define the syntax of any of the above components
187        MAY divide them further and define smaller parts to be components
188        according to this document. As an example, the restrictions of <xref
189          target="RFC3490"/> on bidirectional domain names correspond to treating
190        each label of a domain name as a component for schemes with ireg-name as
191        a domain name. Even where the components are not defined formally, it
192        may be helpful to think about some syntax in terms of components and to
193        apply the relevant restrictions. For example, for the usual name/value
194        syntax in query parts, it is convenient to treat each name and each
195        value as a component. As another example, the extensions in a resource
196        name can be treated as separate components.</t>
197      <t>For each component, the following restrictions apply:</t>
198      <t> <list style="hanging">
199        <t hangText="1.">A component SHOULD NOT use both right-to-left and
200          left-to-right characters.</t>
201        <t hangText="2.">A component using right-to-left characters SHOULD start
202          and end with right-to-left characters.</t>
203      </list></t>
204      <t>The above restrictions are given as "SHOULD"s, rather than as "MUST"s.
205        For IRIs that are never presented visually, they are not relevant.
206        However, for IRIs in general, they are very important to ensure
207        consistent conversion between visual presentation and logical
208        representation, in both directions.</t>
209      <t><list style="hanging">
210        <t hangText="Note:">In some components, the above restrictions may
211          actually be strictly enforced. For example, <xref target="RFC3490"/>
212          requires that these restrictions apply to the labels of a host name
213          for those schemes where ireg-name is a host name. In some other
214          components (for example, path components) following these restrictions
215          may not be too difficult. For other components, such as parts of the
216          query part, it may be very difficult to enforce the restrictions
217          because the values of query parameters may be arbitrary character
218          sequences.</t>
219      </list></t>
220      <t>If the above restrictions cannot be satisfied otherwise, the affected
221        component can always be mapped to URI notation using the general
222        percent-encoding of IRI components, as described in <xref
223          target="RFC3987bis"/>. Please note that the whole component has to be
224        mapped (see also Example 9 below).</t>
225    </section>
226    <!-- bidi-structure -->
227    <section title="Input of Bidi IRIs" anchor="bidiInput">
228      <t>Bidi input methods MUST generate Bidi IRIs in logical order while
229        rendering them according to <xref target="visual"/>. During input,
230        rendering SHOULD be updated after every new character is input to avoid
231        end-user confusion.</t>
232    </section>
233    <!-- bidiInput -->
234    <section title="Examples">
235      <t>This section gives examples of Bidi IRIs in Bidi Notation. It shows
236        legal IRIs with the relationship between their logical and visual
237        representation and explains how certain phenomena in this relationship
238        may look strange to somebody not familiar with bidirectional behavior,
239        but familiar to users of Arabic and Hebrew. It also shows what happens
240        if the restrictions given in <xref target="bidi-structure"/> are not
241        followed. The examples below can be seen at <xref target="BidiEx"/>, in
242        Arabic, Hebrew, and Bidi Notation variants.</t>
243      <t>To read the bidi text in the examples, read the visual representation
244        from left to right until you encounter a block of rtl text. Read the rtl
245        block (including slashes and other special characters) from right to
246        left, then continue at the next unread ltr character.</t>
247      <t>Example 1: A single component with rtl characters is inverted:
248        <vspace/>Logical representation:
249        "http://ab.CDEFGH.ij/kl/mn/op.html"<vspace/>Visual representation:
250        "http://ab.HGFEDC.ij/kl/mn/op.html"<vspace/>Components can be read one
251        by one, and each component can be read in its natural direction.</t>
252      <t>Example 2: More than one consecutive component with rtl characters is
253        inverted as a whole: <vspace/>Logical representation:
254        "http://ab.CDE.FGH/ij/kl/mn/op.html"<vspace/>Visual representation:
255        "http://ab.HGF.EDC/ij/kl/mn/op.html"<vspace/> A sequence of rtl
256        components is read rtl, in the same way as a sequence of rtl words is
257        read rtl in a bidi text.</t>
258      <t>Example 3: All components of an IRI (except for the scheme) are rtl.
259        All rtl components are inverted overall: <vspace/>Logical
260        representation: "http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV"<vspace/>Visual
261        representation: "http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA"<vspace/> The
262        whole IRI (except the scheme) is read rtl. Delimiters between rtl
263        components stay between the respective components; delimiters between
264        ltr and rtl components don't move.</t>
265      <t>Example 4: Each of several sequences of rtl components is inverted on
266        its own: <vspace/>Logical representation:
267        "http://AB.CD.ef/gh/IJ/KL.html"<vspace/>Visual representation:
268        "http://DC.BA.ef/gh/LK/JI.html"<vspace/> Each sequence of rtl components
269        is read rtl, in the same way as each sequence of rtl words in an ltr
270        text is read rtl.</t>
271      <t>Example 5: Example 2, applied to components of different kinds:
272        <vspace/>Logical representation: ""
273        <vspace/>Visual representation: ""<vspace/>
274        The inversion of the domain name label and the path component may be
275        unexpected, but it is consistent with other bidi behavior. For
276        reassurance that the domain component really is "", it may be
277        helpful to read aloud the visual representation following the Unicode
278        Bidirectional Algorithm. After "" one reads the RTL block
279        "E-F-slash-G-H", which corresponds to the logical representation. </t>
280      <t>Example 6: Same as Example 5, with more rtl components:
281        <vspace/>Logical representation:
282        "http://ab.CD.EF/GH/IJ/kl.html"<vspace/>Visual representation:
283        "http://ab.JI/HG/FE.DC/kl.html"<vspace/> The inversion of the domain
284        name labels and the path components may be easier to identify because
285        the delimiters also move.</t>
286      <t>Example 7: A single rtl component includes digits: <vspace/>Logical
287        representation: "http://ab.CDE123FGH.ij/kl/mn/op.html"<vspace/>Visual
288        representation: "http://ab.HGF123EDC.ij/kl/mn/op.html"<vspace/> Numbers
289        are written ltr in all cases but are treated as an additional embedding
290        inside a run of rtl characters. This is completely consistent with usual
291        bidirectional text.</t>
292      <t>Example 8 (not allowed): Numbers are at the start or end of an rtl
293        component:<vspace/>Logical representation:
294        ""<vspace/>Visual representation:
295        ""<vspace/> The sequence "1/2" is
296        interpreted by the Bidirectional Algorithm as a fraction, fragmenting the
297        components and leading to confusion. There are other characters that are
298        interpreted in a special way close to numbers; in particular, "+", "-",
299        "#", "$", "%", ",", ".", and ":".</t>
300      <t>Example 9 (not allowed): The numbers in the previous example are
301        percent-encoded: <vspace/>Logical representation:
302        "",<vspace/>Visual representation:
303        ""</t>
304      <t>Example 10 (allowed but not recommended): <vspace/>Logical
305        representation: "http://ab.CDEFGH.123/kl/mn/op.html"<vspace/>Visual
306        representation: "http://ab.123.HGFEDC/kl/mn/op.html"<vspace/> Components
307        consisting of only numbers are allowed (it would be rather difficult to
308        prohibit them), but these may interact with adjacent RTL components in
309        ways that are not easy to predict.</t>
310      <t>Example 11 (allowed but not recommended): <vspace/>Logical
311        representation: "http://ab.CDEFGH.123ij/kl/mn/op.html"<vspace/>Visual
312        representation: "http://ab.123.HGFEDCij/kl/mn/op.html"<vspace/>
313        Components consisting of numbers and left-to-right characters are
314        allowed, but these may interact with adjacent RTL components in ways
315        that are not easy to predict.</t>
316    </section>
317    <!-- examples -->
318    <section title="IANA Considerations" anchor="iana">
319      <t>This document makes no changes to IANA registries.</t>
320    </section>
321    <!-- IANA -->
322    <section title="Security Considerations" anchor="security">
323      <t>Confusion can occur with bidirectional IRIs, if the restrictions in
324        <xref target="bidi-structure"/> are not followed. The same visual
325        representation may be interpreted as different logical representations,
326        and vice versa. It is also very important that a correct Unicode
327        bidirectional implementation be used.</t>
328    </section>
329    <!-- security -->
330    <section title="Acknowledgements">
331      <t>This document was derived from <xref target="RFC3987"/> and <xref
332        target="RFC3987bis"/> and the acknowledgments of those documents
333        apply.</t>
334    </section>
335    <!-- acknowledgements -->
336  </middle>
337  <back>
338    <references title="Normative References">
339      <reference anchor="RFC3987bis"
340        target="">
341        <front>
342          <title>Internationalized Resource Identifiers (IRIs)</title>
343          <author initials="M." surname="Duerst"/>
344          <author initials="L." surname="Masinter" fullname="Larry Masinter"/>
345          <author initials="M." surname="Suignard"/>
346          <date year="2011" month="August" day="14"/>
347        </front>
348      </reference>
349      <reference anchor="ASCII">
350        <front>
351          <title>Coded Character Set -- 7-bit American Standard Code for
352            Information Interchange</title>
353          <author>
354            <organization>American National Standards Institute</organization>
355          </author>
356          <date year="1986"/>
357        </front>
358        <seriesInfo name="ANSI" value="X3.4"/>
359      </reference>
360      <reference anchor="ISO10646">
361        <front>
362          <title>ISO/IEC 10646:2003: Information Technology - Universal
363            Multiple-Octet Coded Character Set (UCS)</title>
364          <author>
365            <organization>International Organization for
366              Standardization</organization>
367          </author>
368          <date month="December" year="2003"/>
369        </front>
370        <seriesInfo name="ISO" value="Standard 10646"/>
371      </reference> &rfc2119; &rfc3490; &rfc3491; <reference anchor="UNIV6">
372        <front>
373          <title>The Unicode Standard, Version 6.0.0 (Mountain View, CA, The
374            Unicode Consortium, 2011, ISBN 978-1-936213-01-6)</title>
375          <author>
376            <organization>The Unicode Consortium</organization>
377          </author>
378          <date year="2010" month="October"/>
379        </front>
380      </reference>
381      <reference anchor="UNI9"
382        target="">
383        <front>
384          <title>The Unicode Bidirectional Algorithm</title>
385          <author initials="M." surname="Davis" fullname="Mark Davis">
386            <organization/>
387          </author>
388          <date year="2004" month="March"/>
389        </front>
390        <seriesInfo name="Unicode Standard Annex" value="#9"/>
391      </reference>
392    </references>
393    <references title="Informative References">
394      <reference anchor="BidiEx"
395        target="">
396        <front>
397          <title>Examples of Bidi IRIs</title>
398          <author>
399            <organization/>
400          </author>
401          <date year="" month=""/>
402        </front>
403      </reference> &rfc3987; </references>
404  </back>
Note: See TracBrowser for help on using the repository browser.