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

Last change on this file since 167 was 167, checked in by duerst@…, 7 years ago

replaced entity reference to RFC 3987 with internationalized inline version

File size: 31.9 KB
1<?xml version="1.0"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3<!ENTITY rfc2119 SYSTEM "">
4<!ENTITY rfc3490 SYSTEM "">
5<!ENTITY DRAFT "draft-ietf-iri-bidi-guidelines-03">
6<!ENTITY YEAR "2012">
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;"
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." isurname="Dürst" surname="Duerst" ifullname="Martin J. Dürst"
24      fullname="Martin J. Duerst (Note: Please write &quot;Duerst&quot; with u-umlaut wherever possible, for example as &quot;D&amp;#252;rst&quot; in XML and HTML.)">
25      <organization>Aoyama Gakuin University<ionly> (青山学院大学)</ionly> </organization>
26      <address>
27        <postal>
28          <street>5-10-1 Fuchinobe</street>
29          <street>Chuo-ku</street>
30          <city>Sagamihara</city>
31          <region>Kanagawa</region>
32          <code>252-5258</code>
33          <country>Japan</country>
34        </postal>
35        <phone>+81 42 759 6329</phone>
36        <facsimile>+81 42 759 6495</facsimile>
37        <email></email>
38        <uri><aonly> (Note: This is the percent-encoded form of an IRI)</aonly><ionly>ürst/</ionly></uri>
39      </address>
40    </author>
41    <author initials="L." surname="Masinter" fullname="Larry Masinter">
42      <organization>Adobe</organization>
43      <address>
44        <postal>
45          <street>345 Park Ave</street>
46          <city>San Jose</city>
47          <region>CA</region>
48          <code>95110</code>
49          <country>U.S.A.</country>
50        </postal>
51        <phone>+1-408-536-3024</phone>
52        <email></email>
53        <uri></uri>
54      </address>
55    </author>
56    <author initials="A." isurname="Allawi (عادل علاوي)" surname="Allawi"
57      ifullname="Adil 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="&YEAR;" month="October" />
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      <section title='Overview'>
90      <t>Some UCS characters, such as those used in the Arabic and Hebrew
91        scripts, have an inherent right-to-left (rtl) writing direction as
92        opposed to characters, such as those in the Latin script, that have an
93        inherent left-to-right (ltr) direction. IRIs containing rtl characters
94        (called bidirectional IRIs or Bidi IRIs) require additional attention
95        because of the non-trivial relation between their logical and visual
96        ordering. The logical order represents the order in which characters are
97        stored on computers and read by people. The visual order is the order in
98        which the characters appear (or are expected to appear) on a computer
99        display or printout.</t>
100      <t>Generally, alphabetic characters in scripts like Arabic and Hebrew are
101        drawn rtl while numbers are drawn ltr. Symbols such as slash ('/') and
102        period ('.') take their visual direction from the surrounding characters.
103        A list of all ASCII symbols with their bidirectional character type
104        and their function in URIs and IRIs is given in <xref target="ASCIISymbols"/>.</t>
105      <t>Because of this complex interaction between the logical representation,
106        the visual representation, and the syntax of a Bidi IRI, a balance is
107        needed between various requirements. The main requirements are: <list
108        style="hanging">
109        <t hangText="1.">user-predictable conversion between visual and logical
110          representation;</t>
111        <t hangText="2.">the ability to include a wide range of characters in
112          various parts of the IRI; and</t>
113        <t hangText="3.">minor or no changes or restrictions for
114          implementations.</t>
115        </list></t>
116        </section>
117      <section title='Availability'>
118        <t>This document is available in (line-printer ready) plaintext ASCII and in PDF.
119          It is also available in HTML from
120          <vspace/><eref target=";/pub/&DRAFT;.html"
121            >;/pub/&DRAFT;.html</eref>,
122          and in UTF-8 plaintext from
123          <vspace/><eref target=";/pub/&DRAFT;.utf8.txt"
124            >;/pub/&DRAFT;.utf8.txt</eref>.
125          While all these versions are identical in their technical content,
126          the HTML, PDF, and UTF-8 plaintext versions show non-Unicode characters directly.
127          This often makes it easier to understand examples, and readers are therefore strongly advised
128          to consult one of these versions in preference to or as a supplement to the ASCII version.</t>
129        <t><ionly>This version of this document contains bidirectional examples.
130          In order to correctly understand the examples, it is important to view this document
131          with a viewer that correctly implements the Unicode Bidirectional Algorithm <xref target="UNI9"/>.
132           Many text viewers and text editors, and all major browsers, currently implement
133           the Unicode Bidirectional Algorithm.
134           Also, all users who are reading RTL text on a regular basis have viewers
135           that implement this algorithm, because otherwise, they would be unable
136           to read even the simplest texts.
137           In order to check whether a viewer implements the Unicode Bidirectional Algorithm,
138            please observe the following three lines:
139           <vspace/>FEDCBA ,EDCBA ,DCBA, CBA, BA, A
140          <vspace/><span dir='ltr'>ب, بت, بتث, بتثج, بتثجح, بتثجحخ</span>
141          <vspace/><span dir='ltr'>א, אב, אבג, אבגד, אבגדה, אבגדהו</span>
142           <vspace/>The first line contains upper-case Latin letters,
143           the second line contains Arabic letters,
144           and the third line contains Hebrew letters.
145           Your viewer will be okay if in all three lines, the shortest word (one character)
146           is on the right, and the longest word (six characters) on the left,
147           the words are getting longer and longer from right to left,
148           and the commas are between the words, but on the right of the spaces.
149           Otherwise, please use another viewer.
150           In the second line, the characters in each word should all be connected,
151           and change shape slighly on context. In the first and third line,
152           no characters should be connected.</ionly></t>
153      </section>
154      <section title="Notation">
155        <t>In this document, "Bidi Notation", abbreviated "BN" is used for the given Bidi IRI
156          examples as follows: Lower case letters a-z stand for characters that
157          are written with a left to right ordering (such as Latin characters),
158          whereas upper case letters A-Z represent characters that are written
159          right to left (such as Arabic or Hebrew characters). Numbers and
160          symbols are the same.</t>
161        <t> In this document, the key words "MUST", "MUST NOT", "REQUIRED",
163          and "OPTIONAL" are to be interpreted as described in <xref
164            target="RFC2119"/>.</t>
165      </section>
166      <!-- Notation -->
167    </section>
168    <!-- Introduction -->
169    <section title="Logical Storage and Visual Presentation" anchor="visual">
170      <t>When stored or transmitted in digital representation, Bidi IRIs MUST be
171        in full logical order and MUST conform to the IRI syntax rules (which
172        includes the rules relevant to their scheme). This ensures that
173        Bidi IRIs can be processed in the same way as other IRIs.</t>
174      <t>Bidi IRIs MUST be visually ordered by the Unicode Bidirectional
175        Algorithm <xref target="UNIV6"/>, <xref target="UNI9"/>. Bidi IRIs MUST
176        be rendered in the same way as they would be if they were in a
177        left-to-right embedding. </t>
178      <t>In conformance with the Unicode Bidirectional Algorithm, embedding MAY
179        be done in one of two ways: <list style="hanging">
180        <t hangText="1.">precede the IRI with U+202A, LEFT-TO-RIGHT EMBEDDING
181          (LRE), and follow with U+202C, POP DIRECTIONAL FORMATTING (PDF);
182          or</t>
183        <t hangText="2.">use a higher-level protocol (e.g., the dir='ltr'
184          attribute in HTML).</t>
185        </list></t>
186      <t>Preceding and following the Bidi IRI with U+200E, LEFT-TO-RIGHT MARK
187        (LRM) is NOT RECOMMENDED as, there are cases where this may not be
188        sufficient to match full left to right embedding.</t>
189      <t>There is no requirement to use embedding if the display is still the
190        same without the embedding. For example, a Bidi IRI in a text
191        with left-to-right base directionality (such as used for English or
192        Cyrillic) that is preceded and followed by whitespace and strong
193        left-to-right characters does not need an embedding. Also, a
194        bidirectional relative IRI reference that only contains strong
195        right-to-left characters and weak characters (such as symbols) and that
196        starts and ends with a strong right-to-left character and appears in a
197        text with right-to-left base directionality (such as used for Arabic or
198        Hebrew) and is preceded and followed by whitespace and strong characters
199        does not need an embedding.</t>
200      <t>However, implementers are RECOMMENDED to use embedding in all cases
201        where they are not completely sure that the display behavior is
202        unaffected without the embedding.</t>
203      <t>The Unicode Bidirectional Algorithm (<xref target="UNI9"/>, section
204        4.3) permits higher-level protocols to influence bidirectional
205        rendering. Such changes by higher-level protocols MUST NOT be used if
206        they change the rendering of IRIs.</t>
207      <t>The bidirectional formatting characters that may be used before or
208        after the IRI to ensure correct display are not themselves part of the
209        IRI. IRIs MUST NOT contain bidirectional formatting characters (LRM,
210        RLM, LRE, RLE, LRO, RLO, and PDF). They affect the visual rendering of
211        the IRI but do not appear themselves. It would therefore not be possible
212        to input an IRI with such characters correctly.</t>
213    </section>
214    <!-- visual -->
215    <section title="Bidi IRI Structure" anchor="bidi-structure">
216      <t>The Unicode Bidirectional Algorithm is designed for general purpose
217        text. To make sure that it does not affect the rendering of Bidi IRIs
218        outside of the requirements of this document, some restrictions on Bidi
219        IRIs are necessary. These restrictions are given in terms of delimiters
220        (structural characters, mostly punctuation such as "@", ".", ":", and
221        "/") and components (usually consisting mostly of letters and
222        digits).</t>
223      <t>The following syntax rules from the ABNF of <xref target="RFC3987bis"/>
224        correspond to components for the purpose of Bidi behavior: iuserinfo,
225        ireg-name, isegment, isegment-nz, isegment-nz-nc, ireg-name, iquery, and
226        ifragment.</t>
227      <t>Specifications that define the syntax of any of the above components
228        MAY divide them further and define smaller parts to be components
229        according to this document. As an example, the restrictions of <xref
230          target="RFC3490"/> on bidirectional domain names correspond to treating
231        each label of a domain name as a component for schemes with ireg-name as
232        a domain name. Even where the components are not defined formally, it
233        may be helpful to think about some syntax in terms of components and to
234        apply the relevant restrictions. For example, for the usual name/value
235        syntax in query parts, it is convenient to treat each name and each
236        value as a component. As another example, the extensions in a resource
237        name can be treated as separate components.</t>
238      <t>For each component, the following restrictions apply:</t>
239      <t> <list style="hanging">
240        <t hangText="1.">A component SHOULD NOT use both right-to-left and
241          left-to-right characters.</t>
242        <t hangText="2.">A component using right-to-left characters SHOULD start
243          with a right-to-left character, and end with a right-to-left character
244          potentially followed by one or more nonspacing mark (bidi class NSM).</t>
245      </list></t>
246      <t>The above restrictions are given as "SHOULD"s, rather than as "MUST"s.
247        For IRIs that are never presented visually, they are not relevant.
248        However, for IRIs in general, they are very important to ensure
249        consistent conversion between visual presentation and logical
250        representation, in both directions.</t>
251      <t><list style="hanging">
252        <t hangText="Note:">In some components, the above restrictions may
253          actually be strictly enforced. For example, <xref target="RFC3490"/>
254          requires that these restrictions apply to the labels of a host name
255          for those schemes where ireg-name is a host name. In some other
256          components (for example, path components) following these restrictions
257          may not be too difficult. For other components, such as parts of the
258          query part, it may be very difficult to enforce the restrictions
259          because the values of query parameters may be arbitrary character
260          sequences.</t>
261      </list></t>
262      <t>If the above restrictions cannot be satisfied otherwise, the affected
263        component can always be mapped to URI notation using the general
264        percent-encoding of IRI components, as described in <xref
265          target="RFC3987bis"/>. Please note that the whole component has to be
266        mapped (see also Example 9 below).</t>
267    </section>
268    <!-- bidi-structure -->
269    <section title="Input of Bidi IRIs" anchor="bidiInput">
270      <t>Bidi input methods MUST generate Bidi IRIs in logical order while
271        rendering them according to <xref target="visual"/>. During input,
272        rendering SHOULD be updated after every new character is input to avoid
273        end-user confusion.</t>
274    </section>
275    <!-- bidiInput -->
276    <section title="Examples">
277      <t>This section gives examples of Bidi IRIs in Bidi Notation. It shows
278        legal IRIs with the relationship between their logical and visual
279        representation and explains how certain phenomena in this relationship
280        may look strange to somebody not familiar with bidirectional behavior,
281        but familiar to users of Arabic and Hebrew. It also shows what happens
282        if the restrictions given in <xref target="bidi-structure"/> are not
283        followed. <aonly>Please see <eref target="Availability"/> for versions
284        of the examples in Arabic and Hebrew script.</aonly></t>
285      <t>To read the bidi text in the examples, read the visual representation
286        from left to right until you encounter a block of rtl text. Read the rtl
287        block (including slashes and other special characters) from right to
288        left, then continue at the next unread ltr character.</t>
289      <t>Please note that "BN" stands for "Bidi Notation", see <eref target="Notation" />.
290        AR stands for Arabic, HE for Hebrew.</t>
292      <t>Example 1: A single component with rtl characters is inverted:
294        <vspace/>Logical representation (BN): "http://ab.CDEFGH.ij/kl/mn/op.html"
295        <vspace/>Visual representation (BN): "http://ab.HGFEDC.ij/kl/mn/op.html"
296        <ionly>
297        <vspace/>Visual representation (AR): "<span dir='ltr'>http://ab.تثجحخد.ij/kl/mn/op.html</span>"
298        <vspace/>Visual representation (HE): "<span dir='ltr'>http://ab.גדהוזח.ij/kl/mn/op.html</span>"
299        </ionly>
300        <vspace/>Components can be read one
301        by one, and each component can be read in its natural direction.</t>
303      <t>Example 2: More than one consecutive component with rtl characters is
304        inverted as a whole:
306        <vspace/>Logical representation (BN): "http://ab.CDE.FGH/ij/kl/mn/op.html"
307        <vspace/>Visual representation (BN): "http://ab.HGF.EDC/ij/kl/mn/op.html"
308        <ionly>
309          <vspace/>Visual representation (AR): "<span dir='ltr'>http://ab.تثج.حخد/ij/kl/mn/op.html</span>"
310          <vspace/>Visual representation (HE): "<span dir='ltr'>http://ab.גדה.וזח/ij/kl/mn/op.html</span>"
311        </ionly>
313        <vspace/> A sequence of rtl
314        components is read rtl, in the same way as a sequence of rtl words is
315        read rtl in a bidi text.</t>
317      <t>Example 3: All components of an IRI (except for the scheme) are rtl.
318        All rtl components are inverted overall:
320        <vspace/>Logical representation (BN): "http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV"
321        <vspace/>Visual representation (BN): "http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA"
322        <ionly>
323          <vspace/>Visual representation (AR): "<span dir='ltr'>http://اب.تث.جح/خد/ذر/زس?شص=ضط;ظع=غف#قك</span>"
324          <vspace/>Visual representation (HE): "<span dir='ltr'>http://אב.גד.הו/זח/טי/כל?מן=סע;פץ=קר#שת</span>"
325        </ionly>
327        <vspace/> The
328        whole IRI (except the scheme) is read rtl. Delimiters between rtl
329        components stay between the respective components; delimiters between
330        ltr and rtl components don't move.</t>
332      <t>Example 4: Each of several sequences of rtl components is inverted on
333        its own:
335        <vspace/>Logical representation (BN): "http://AB.CD.ef/gh/IJ/KL.html"
336        <vspace/>Visual representation (BN): "http://DC.BA.ef/gh/LK/JI.html"
337        <ionly>
338          <vspace/>Visual representation (AR): "<span dir='ltr'>http://اب.تث.ef/gh/ذر/زس.html</span>"
339          <vspace/>Visual representation (HE): "<span dir='ltr'>http://אב.גד.ef/gh/טי/כל.html</span>"
340        </ionly>
342        <vspace/> Each sequence of rtl components
343        is read rtl, in the same way as each sequence of rtl words in an ltr
344        text is read rtl.</t>
346      <t>Example 5: Example 2, applied to components of different kinds:
348        <vspace/>Logical representation (BN): ""
349        <vspace/>Visual representation (BN): ""
350        <ionly>
351          <vspace/>Visual representation (AR): "<span dir='ltr'>جح/خد/ij/kl.html</span>"
352          <vspace/>Visual representation (HE): "<span dir='ltr'>הו/זח/ij/kl.html</span>"
353        </ionly>
355        <vspace/>
356        The inversion of the domain name label and the path component may be
357        unexpected, but it is consistent with other bidi behavior. For
358        reassurance that the domain component really is "", it may be
359        helpful to read aloud the visual representation following the Unicode
360        Bidirectional Algorithm. After "" one reads the RTL block
361        "E-F-slash-G-H", which corresponds to the logical representation. </t>
363      <t>Example 6: Same as Example 5, with more rtl components:
365        <vspace/>Logical representation (BN): "http://ab.CD.EF/GH/IJ/kl.html"
366        <vspace/>Visual representation (BN): "http://ab.JI/HG/FE.DC/kl.html"
367        <ionly>
368          <vspace/>Visual representation (AR): "<span dir='ltr'>http://ab.تث.جح/خد/ذر/kl.html</span>"
369          <vspace/>Visual representation (HE): "<span dir='ltr'>http://ab.גד.הו/זח/טי/kl.html</span>"
370        </ionly>
372        <vspace/> The inversion of the domain
373        name labels and the path components may be easier to identify because
374        the delimiters also move.</t>
376      <t>Example 7: A single rtl component includes digits:
378        <vspace/>Logical representation (BN): "http://ab.CDE123FGH.ij/kl/mn/op.html"
379        <vspace/>Visual representation (BN): "http://ab.HGF123EDC.ij/kl/mn/op.html"
380        <ionly>
381          <vspace/>Visual representation (AR): "<span dir='ltr'>http://ab.تثج123حخد.ij/kl/mn/op.html</span>"
382          <vspace/>Visual representation (HE): "<span dir='ltr'>http://ab.גדה123וזח.ij/kl/mn/op.html</span>"
383        </ionly>
385        <vspace/> Numbers
386        are written ltr in all cases but are treated as an additional embedding
387        inside a run of rtl characters. This is completely consistent with usual
388        bidirectional text.</t>
390      <t>Example 8 (not allowed): Numbers are at the start or end of an rtl
391        component:
393        <vspace/>Logical representation (BN): ""
394        <vspace/>Visual representation (BN): ""
395        <ionly>
396          <vspace/>Visual representation (AR): "<span dir='ltr'>خد1/2ذر/زس.html</span>"
397          <vspace/>Visual representation (HE): "<span dir='ltr'>זח1/2טי/כל.html</span>"
398        </ionly>
400        <vspace/> The sequence "1/2" is
401        interpreted by the Bidirectional Algorithm as a fraction, fragmenting the
402        components and leading to confusion. There are other characters that are
403        interpreted in a special way close to numbers; in particular, "+", "-",
404        "#", "$", "%", ",", ".", and ":".</t>
406      <t>Example 9 (not allowed): The numbers in the previous example are
407        percent-encoded:
409        <vspace/>Logical representation (BN): ""
410        <vspace/>Visual representation (BN): ""
411        <ionly>
412          <vspace/>Visual representation (AR): "<span dir='ltr'>خد%31/%32ذر/زس.html</span>"
413          <vspace/>Visual representation (HE): "<span dir='ltr'>זח%31/%32טי/כל.html</span>"
414        </ionly>
416      </t>
418      <t>Example 10 (allowed but not recommended):
420        <vspace/>Logical representation (BN): "http://ab.CDEFGH.123/kl/mn/op.html"
421        <vspace/>Visual representation (BN): "http://ab.123.HGFEDC/kl/mn/op.html"
422        <ionly>
423          <vspace/>Visual representation (AR): "<span dir='ltr'>http://ab.تثجحخد.123/kl/mn/op.html</span>"
424          <vspace/>Visual representation (HE): "<span dir='ltr'>http://ab.גדהוזח.123/kl/mn/op.html</span>"
425        </ionly>
427        <vspace/> Components
428        consisting of only numbers are allowed (it would be rather difficult to
429        prohibit them), but these may interact with adjacent RTL components in
430        ways that are not easy to predict.</t>
432      <t>Example 11 (allowed but not recommended):
434        <vspace/>Logical representation (BN): "http://ab.CDEFGH.123ij/kl/mn/op.html"
435        <vspace/>Visual representation (BN): "http://ab.123.HGFEDCij/kl/mn/op.html"
436        <ionly>
437          <vspace/>Visual representation (AR): "<span dir='ltr'>http://ab.تثجحخد.123ij/kl/mn/op.html</span>"
438          <vspace/>Visual representation (HE): "<span dir='ltr'>http://ab.גדהוזח.123ij/kl/mn/op.html</span>"
439        </ionly>
441        <vspace/>
442        Components consisting of numbers and left-to-right characters are
443        allowed, but these may interact with adjacent RTL components in ways
444        that are not easy to predict.</t>
445    </section>
446    <!-- examples -->
447    <section title="IANA Considerations" anchor="iana">
448      <t>This document makes no changes to IANA registries.</t>
449    </section>
450    <!-- IANA -->
451    <section title="Security Considerations" anchor="security">
452      <t>Confusion can occur with bidirectional IRIs, if the restrictions in
453        <xref target="bidi-structure"/> are not followed. The same visual
454        representation may be interpreted as different logical representations,
455        and vice versa. It is also very important that a correct Unicode
456        bidirectional implementation be used.</t>
457    </section>
458    <!-- security -->
459    <section title="Acknowledgements">
460      <t>This document was derived from <xref target="RFC3987"/> and <xref
461        target="RFC3987bis"/> and the acknowledgments of those documents
462        apply. Shunsuke Oshima (大嶋 俊介) provided the data for <xref  target="ASCIISymbols"/>.</t>
463    </section>
464    <!-- acknowledgements -->
465    <section title="Main Changes Since RFC 3987">
466      <t>This section describes the main changes since <xref target="RFC3987"></xref>.</t>       
468      <t><list style="symbols">
469        <t>Separated out the section on bidi in <xref target="RFC3987"/> to this document.</t>
470        <t>Added examples in Arabic and Hebrew, which can be seen in html/pdf/utf8.txt versions.</t>
471        <t>Allowed NSMs at the end of components, for Dhivehi, Yiddish,...</t>
472        <t>TODO: check for major changes between RFC3987 and draft -02.</t>
473      </list>
474      </t>
475        <t>Note to RFC Editor: Please remove this paragraph before publication.
476          Detailled change logs are available in the IETF tools subversion repository at
478     </section>
479  </middle>
480  <back>
481    <references title="Normative References">
482      <reference anchor="RFC3987bis"
483        target="">
484        <front>
485          <title>Internationalized Resource Identifiers (IRIs)</title>
486          <author initials="M.J." isurname="Dürst" surname="Duerst" ifullname="Martin J. Dürst" fullname="Martin J. Duerst"/>
487          <author initials="L." surname="Masinter" fullname="Larry Masinter"/>
488          <author initials="M." surname="Suignard"/>
489          <date year="2012" month="October"/>
490        </front>
491      </reference>
492      &rfc2119;
493      &rfc3490;
494      <reference anchor="UNIV6">
495        <front>
496          <title>The Unicode Standard, Version 6.2.0 (Mountain View, CA, The
497            Unicode Consortium, 2012, ISBN 978-1-936213-07-8)</title>
498          <author>
499            <organization>The Unicode Consortium</organization>
500          </author>
501          <date year="2012" month="October"/>
502        </front>
503      </reference>
504      <reference anchor="UNI9"
505        target="">
506        <front>
507          <title>The Unicode Bidirectional Algorithm</title>
508          <author initials="M." surname="Davis" fullname="Mark Davis">
509            <organization/>
510          </author>
511          <date year="2012" month="September"/>
512        </front>
513        <seriesInfo name="Unicode Standard Annex" value="#9"/>
514      </reference>
515    </references>
517    <references title="Informative References">
518      <reference anchor="RFC3987">
519        <front>
520          <title>Internationalized Resource Identifiers (IRIs)</title>
521          <author  initials="M.J." isurname="Dürst" surname="Duerst" ifullname="Martin J. Dürst" fullname="Martin J. Duerst"/>
522          <author initials="M." surname="Suignard" fullname="M. Suignard">
523            <organization/>
524          </author>
525          <date year="2005" month="January"/>
526        </front>
527        <seriesInfo name="RFC" value="3987"/>
528        <format type="TXT" octets="111190" target=""/>
529      </reference>
531    </references>
532    <section title='List of ASCII Symbols and their Bidirectional Character Types'  anchor="ASCIISymbols">
533      <t>To help understand the influence of various symbols on IRI display,
534        this appendix lists all of them, giving the character itself,
535        the Unicode codepoint, the character name, the bidirectional character type (BCT)
536        and the rule and relevance in the IRI syntax.</t>
537      <t>The most important ones in practice are
538        ":", delimining schem and port (CS, Common Number Separator),
539        "/" to indicate generic (hierarchical) schemes and as a path separator (CS, Common Number Separator),
540        "?" to introduce a query part (ON, Other Neutral),
541        "#" to introduce a fragment identifier (ET, European Number Terminator),
542        "." to separate labels in a domain name (CS, Common Number Separator),
543        "&amp;" to separate form parameters (ON, Other Neutral), and
544        "@" to separate user information (ON, Other Neutral).
545      </t>
546      <figure>
547        <artwork>
548Char Codepoint  Character Name       BCT  IRI syntax
550"#"  U+0023     NUMBER SIGN          ET   gen-delims, fragments
551"/"  U+002F     SOLIDUS              CS   gen-delims, paths
552":"  U+003A     COLON                CS   gen-delims, scheme, port
553"?"  U+003F     QUESTION MARK        ON   gen-delims, query part
554"@"  U+0040     COMMERCIAL AT        ON   gen-delims, user
555"["  U+005B     LEFT SQUARE BRACKET  ON   gen-delims
556"]"  U+005D     RIGHT SQUARE BRACKET ON   gen-delims
557"%"  U+0025     PERCENT SIGN         ET   pcd-encoded
558"!"  U+0021     EXCLAMATION MARK     ON   sub-delims
559","  U+002C     COMMA                CS   sub-delims
560"+"  U+002B     PLUS SIGN            ES   sub-delims
561"$"  U+0024     DOLLAR SIGN          ET   sub-delims
562"("  U+0028     LEFT PARENTHESIS     ON   sub-delims
563"'"  U+0027     APOSTROPHE           ON   sub-delims
564")"  U+0029     RIGHT PARENTHESIS    ON   sub-delims
565"*"  U+002A     ASTERISK             ON   sub-delims
566";"  U+003B     SEMICOLON            ON   sub-delims
567"="  U+003D     EQUALS SIGN          ON   sub-delims, forms
568"&amp;"  U+0026     AMPERSAND            ON   sub-delims, forms
569"."  U+002E     FULL STOP            CS   unreserved, domain names
570"-"  U+002D     HYPHEN-MINUS         ES   unreserved
571"_"  U+005F     LOW LINE             ON   unreserved
572"~"  U+007E     TILDE                ON   unreserved
573" "  U+0020     SPACE                WS   excluded, delim
574'"'  U+0022     QUOTATION MARK       ON   excluded, delim
575"\"  U+005C     REVERSE SOLIDUS      ON   excluded, unwise
576"^"  U+005E     CIRCUMFLEX ACCENT    ON   excluded, unwise
577"&lt;"  U+003C     LESS-THAN SIGN       ON   excluded, delim
578">"  U+003E     GREATER-THAN SIGN    ON   excluded, delim
579"`"  U+0060     GRAVE ACCENT         ON   excluded, unwise
580"|"  U+007C     VERTICAL LINE        ON   excluded, unwise
581"{"  U+007B     LEFT CURLY BRACKET   ON   excluded, delim
582"}"  U+007D     RIGHT CURLY BRACKET  ON   excluded, delim
583        </artwork>
584      </figure>
585    </section>
586  </back>
Note: See TracBrowser for help on using the repository browser.