idnits 2.17.1 draft-ietf-iri-bidi-guidelines-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2012) is 4177 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNI9' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIV6' -- Duplicate reference: RFC3987, mentioned in 'RFC3987', was also mentioned in 'RFC3987bis'. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internationalized Resource Identifiers M. Duerst 3 (iri) Aoyama Gakuin University 4 Internet-Draft L. Masinter 5 Intended status: BCP Adobe 6 Expires: April 24, 2013 A. Allawi 7 Diwan Software Limited 8 October 21, 2012 10 Guidelines for Internationalized Resource Identifiers with Bi- 11 directional Characters (Bidi IRIs) 12 draft-ietf-iri-bidi-guidelines-03 14 Abstract 16 This specification gives guidelines for selection, use, and 17 presentation of International Resource Identifiers (IRIs) which 18 include characters with inherent right-to-left (rtl) writing 19 direction. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 24, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Availability . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Logical Storage and Visual Presentation . . . . . . . . . . . 4 72 3. Bidi IRI Structure . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Input of Bidi IRIs . . . . . . . . . . . . . . . . . . . . . . 6 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. Main Changes Since RFC 3987 . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Appendix A. List of ASCII Symbols and their Bidirectional 83 Character Types . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 1.1. Overview 90 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 93 an inherent left-to-right (ltr) direction. IRIs containing rtl 94 characters (called bidirectional IRIs or Bidi IRIs) require 95 additional attention because of the non-trivial relation between 96 their logical and visual ordering. The logical order represents the 97 order in which characters are stored on computers and read by people. 98 The visual order is the order in which the characters appear (or are 99 expected to appear) on a computer display or printout. 101 Generally, alphabetic characters in scripts like Arabic and Hebrew 102 are drawn rtl while numbers are drawn ltr. Symbols such as slash 103 ('/') and period ('.') take their visual direction from the 104 surrounding characters. A list of all ASCII symbols with their 105 bidirectional character type and their function in URIs and IRIs is 106 given in Appendix A. 108 Because of this complex interaction between the logical 109 representation, the visual representation, and the syntax of a Bidi 110 IRI, a balance is needed between various requirements. The main 111 requirements are: 113 1. user-predictable conversion between visual and logical 114 representation; 116 2. the ability to include a wide range of characters in various parts 117 of the IRI; and 119 3. minor or no changes or restrictions for implementations. 121 1.2. Availability 123 This document is available in (line-printer ready) plaintext ASCII 124 and in PDF. It is also available in HTML from 125 http://www.sw.it.aoyama.ac.jp/2012/pub/ 126 draft-ietf-iri-bidi-guidelines-03.html, and in UTF-8 plaintext from 127 http://www.sw.it.aoyama.ac.jp/2012/pub/ 128 draft-ietf-iri-bidi-guidelines-03.utf8.txt. While all these versions 129 are identical in their technical content, the HTML, PDF, and UTF-8 130 plaintext versions show non-Unicode characters directly. This often 131 makes it easier to understand examples, and readers are therefore 132 strongly advised to consult one of these versions in preference to or 133 as a supplement to the ASCII version. 135 1.3. Notation 137 In this document, "Bidi Notation", abbreviated "BN" is used for the 138 given Bidi IRI examples as follows: Lower case letters a-z stand for 139 characters that are written with a left to right ordering (such as 140 Latin characters), whereas upper case letters A-Z represent 141 characters that are written right to left (such as Arabic or Hebrew 142 characters). Numbers and symbols are the same. 144 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 145 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 146 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 148 2. Logical Storage and Visual Presentation 150 When stored or transmitted in digital representation, Bidi IRIs MUST 151 be in full logical order and MUST conform to the IRI syntax rules 152 (which includes the rules relevant to their scheme). This ensures 153 that Bidi IRIs can be processed in the same way as other IRIs. 155 Bidi IRIs MUST be visually ordered by the Unicode Bidirectional 156 Algorithm [UNIV6], [UNI9]. Bidi IRIs MUST be rendered in the same 157 way as they would be if they were in a left-to-right embedding. 159 In conformance with the Unicode Bidirectional Algorithm, embedding 160 MAY be done in one of two ways: 162 1. precede the IRI with U+202A, LEFT-TO-RIGHT EMBEDDING (LRE), and 163 follow with U+202C, POP DIRECTIONAL FORMATTING (PDF); or 165 2. use a higher-level protocol (e.g., the dir='ltr' attribute in 166 HTML). 168 Preceding and following the Bidi IRI with U+200E, LEFT-TO-RIGHT MARK 169 (LRM) is NOT RECOMMENDED as, there are cases where this may not be 170 sufficient to match full left to right embedding. 172 There is no requirement to use embedding if the display is still the 173 same without the embedding. For example, a Bidi IRI in a text with 174 left-to-right base directionality (such as used for English or 175 Cyrillic) that is preceded and followed by whitespace and strong 176 left-to-right characters does not need an embedding. Also, a 177 bidirectional relative IRI reference that only contains strong right- 178 to-left characters and weak characters (such as symbols) and that 179 starts and ends with a strong right-to-left character and appears in 180 a text with right-to-left base directionality (such as used for 181 Arabic or Hebrew) and is preceded and followed by whitespace and 182 strong characters does not need an embedding. 184 However, implementers are RECOMMENDED to use embedding in all cases 185 where they are not completely sure that the display behavior is 186 unaffected without the embedding. 188 The Unicode Bidirectional Algorithm ([UNI9], section 4.3) permits 189 higher-level protocols to influence bidirectional rendering. Such 190 changes by higher-level protocols MUST NOT be used if they change the 191 rendering of IRIs. 193 The bidirectional formatting characters that may be used before or 194 after the IRI to ensure correct display are not themselves part of 195 the IRI. IRIs MUST NOT contain bidirectional formatting characters 196 (LRM, RLM, LRE, RLE, LRO, RLO, and PDF). They affect the visual 197 rendering of the IRI but do not appear themselves. It would 198 therefore not be possible to input an IRI with such characters 199 correctly. 201 3. Bidi IRI Structure 203 The Unicode Bidirectional Algorithm is designed for general purpose 204 text. To make sure that it does not affect the rendering of Bidi 205 IRIs outside of the requirements of this document, some restrictions 206 on Bidi IRIs are necessary. These restrictions are given in terms of 207 delimiters (structural characters, mostly punctuation such as "@", 208 ".", ":", and "/") and components (usually consisting mostly of 209 letters and digits). 211 The following syntax rules from the ABNF of [RFC3987bis] correspond 212 to components for the purpose of Bidi behavior: iuserinfo, ireg-name, 213 isegment, isegment-nz, isegment-nz-nc, ireg-name, iquery, and 214 ifragment. 216 Specifications that define the syntax of any of the above components 217 MAY divide them further and define smaller parts to be components 218 according to this document. As an example, the restrictions of 219 [RFC3490] on bidirectional domain names correspond to treating each 220 label of a domain name as a component for schemes with ireg-name as a 221 domain name. Even where the components are not defined formally, it 222 may be helpful to think about some syntax in terms of components and 223 to apply the relevant restrictions. For example, for the usual name/ 224 value syntax in query parts, it is convenient to treat each name and 225 each value as a component. As another example, the extensions in a 226 resource name can be treated as separate components. 228 For each component, the following restrictions apply: 230 1. A component SHOULD NOT use both right-to-left and left-to-right 231 characters. 233 2. A component using right-to-left characters SHOULD start with a 234 right-to-left character, and end with a right-to-left character 235 potentially followed by one or more nonspacing mark (bidi class 236 NSM). 238 The above restrictions are given as "SHOULD"s, rather than as 239 "MUST"s. For IRIs that are never presented visually, they are not 240 relevant. However, for IRIs in general, they are very important to 241 ensure consistent conversion between visual presentation and logical 242 representation, in both directions. 244 Note: In some components, the above restrictions may actually be 245 strictly enforced. For example, [RFC3490] requires that these 246 restrictions apply to the labels of a host name for those schemes 247 where ireg-name is a host name. In some other components (for 248 example, path components) following these restrictions may not be 249 too difficult. For other components, such as parts of the query 250 part, it may be very difficult to enforce the restrictions because 251 the values of query parameters may be arbitrary character 252 sequences. 254 If the above restrictions cannot be satisfied otherwise, the affected 255 component can always be mapped to URI notation using the general 256 percent-encoding of IRI components, as described in [RFC3987bis]. 257 Please note that the whole component has to be mapped (see also 258 Example 9 below). 260 4. Input of Bidi IRIs 262 Bidi input methods MUST generate Bidi IRIs in logical order while 263 rendering them according to Section 2. During input, rendering 264 SHOULD be updated after every new character is input to avoid end- 265 user confusion. 267 5. Examples 269 This section gives examples of Bidi IRIs in Bidi Notation. It shows 270 legal IRIs with the relationship between their logical and visual 271 representation and explains how certain phenomena in this 272 relationship may look strange to somebody not familiar with 273 bidirectional behavior, but familiar to users of Arabic and Hebrew. 274 It also shows what happens if the restrictions given in Section 3 are 275 not followed. Please see for versions of the examples 276 in Arabic and Hebrew script. 278 To read the bidi text in the examples, read the visual representation 279 from left to right until you encounter a block of rtl text. Read the 280 rtl block (including slashes and other special characters) from right 281 to left, then continue at the next unread ltr character. 283 Please note that "BN" stands for "Bidi Notation", see . AR 284 stands for Arabic, HE for Hebrew. 286 Example 1: A single component with rtl characters is inverted: 287 Logical representation (BN): "http://ab.CDEFGH.ij/kl/mn/op.html" 288 Visual representation (BN): "http://ab.HGFEDC.ij/kl/mn/op.html" 289 Components can be read one by one, and each component can be read in 290 its natural direction. 292 Example 2: More than one consecutive component with rtl characters is 293 inverted as a whole: 294 Logical representation (BN): "http://ab.CDE.FGH/ij/kl/mn/op.html" 295 Visual representation (BN): "http://ab.HGF.EDC/ij/kl/mn/op.html" 296 A sequence of rtl components is read rtl, in the same way as a 297 sequence of rtl words is read rtl in a bidi text. 299 Example 3: All components of an IRI (except for the scheme) are rtl. 300 All rtl components are inverted overall: 301 Logical representation (BN): 302 "http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV" 303 Visual representation (BN): "http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA" 304 The whole IRI (except the scheme) is read rtl. Delimiters between 305 rtl components stay between the respective components; delimiters 306 between ltr and rtl components don't move. 308 Example 4: Each of several sequences of rtl components is inverted on 309 its own: 310 Logical representation (BN): "http://AB.CD.ef/gh/IJ/KL.html" 311 Visual representation (BN): "http://DC.BA.ef/gh/LK/JI.html" 312 Each sequence of rtl components is read rtl, in the same way as each 313 sequence of rtl words in an ltr text is read rtl. 315 Example 5: Example 2, applied to components of different kinds: 316 Logical representation (BN): "http://ab.cd.EF/GH/ij/kl.html" 317 Visual representation (BN): "http://ab.cd.HG/FE/ij/kl.html" 318 The inversion of the domain name label and the path component may be 319 unexpected, but it is consistent with other bidi behavior. For 320 reassurance that the domain component really is "ab.cd.EF", it may be 321 helpful to read aloud the visual representation following the Unicode 322 Bidirectional Algorithm. After "http://ab.cd." one reads the RTL 323 block "E-F-slash-G-H", which corresponds to the logical 324 representation. 326 Example 6: Same as Example 5, with more rtl components: 327 Logical representation (BN): "http://ab.CD.EF/GH/IJ/kl.html" 328 Visual representation (BN): "http://ab.JI/HG/FE.DC/kl.html" 329 The inversion of the domain name labels and the path components may 330 be easier to identify because the delimiters also move. 332 Example 7: A single rtl component includes digits: 333 Logical representation (BN): "http://ab.CDE123FGH.ij/kl/mn/op.html" 334 Visual representation (BN): "http://ab.HGF123EDC.ij/kl/mn/op.html" 335 Numbers are written ltr in all cases but are treated as an additional 336 embedding inside a run of rtl characters. This is completely 337 consistent with usual bidirectional text. 339 Example 8 (not allowed): Numbers are at the start or end of an rtl 340 component: 341 Logical representation (BN): "http://ab.cd.ef/GH1/2IJ/KL.html" 342 Visual representation (BN): "http://ab.cd.ef/LK/JI1/2HG.html" 343 The sequence "1/2" is interpreted by the Bidirectional Algorithm as a 344 fraction, fragmenting the components and leading to confusion. There 345 are other characters that are interpreted in a special way close to 346 numbers; in particular, "+", "-", "#", "$", "%", ",", ".", and ":". 348 Example 9 (not allowed): The numbers in the previous example are 349 percent-encoded: 350 Logical representation (BN): "http://ab.cd.ef/GH%31/%32IJ/KL.html" 351 Visual representation (BN): "http://ab.cd.ef/LK/JI%32/%31HG.html" 353 Example 10 (allowed but not recommended): 354 Logical representation (BN): "http://ab.CDEFGH.123/kl/mn/op.html" 355 Visual representation (BN): "http://ab.123.HGFEDC/kl/mn/op.html" 356 Components consisting of only numbers are allowed (it would be rather 357 difficult to prohibit them), but these may interact with adjacent RTL 358 components in ways that are not easy to predict. 360 Example 11 (allowed but not recommended): 361 Logical representation (BN): "http://ab.CDEFGH.123ij/kl/mn/op.html" 362 Visual representation (BN): "http://ab.123.HGFEDCij/kl/mn/op.html" 363 Components consisting of numbers and left-to-right characters are 364 allowed, but these may interact with adjacent RTL components in ways 365 that are not easy to predict. 367 6. IANA Considerations 369 This document makes no changes to IANA registries. 371 7. Security Considerations 373 Confusion can occur with bidirectional IRIs, if the restrictions in 374 Section 3 are not followed. The same visual representation may be 375 interpreted as different logical representations, and vice versa. It 376 is also very important that a correct Unicode bidirectional 377 implementation be used. 379 8. Acknowledgements 381 This document was derived from [RFC3987] and [RFC3987bis] and the 382 acknowledgments of those documents apply. Shunsuke Oshima provided 383 the data for Appendix A. 385 9. Main Changes Since RFC 3987 387 This section describes the main changes since [RFC3987]. 389 o Separated out the section on bidi in [RFC3987] to this document. 391 o Added examples in Arabic and Hebrew, which can be seen in html/ 392 pdf/utf8.txt versions. 394 o Allowed NSMs at the end of components, for Dhivehi, Yiddish,... 396 o TODO: check for major changes between RFC3987 and draft -02. 398 Note to RFC Editor: Please remove this paragraph before publication. 399 Detailled change logs are available in the IETF tools subversion 400 repository at http://trac.tools.ietf.org/wg/iri/trac/log/ 401 draft-ietf-iri-3987bis/draft-ietf-iri-bidi-guidelines.xml. 403 10. References 405 10.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 411 "Internationalizing Domain Names in Applications (IDNA)", 412 RFC 3490, March 2003. 414 [RFC3987bis] 415 Duerst, M., Masinter, L., and M. Suignard, 416 "Internationalized Resource Identifiers (IRIs)", 417 October 2012, 418 . 420 [UNI9] Davis, M., "The Unicode Bidirectional Algorithm", Unicode 421 Standard Annex #9, September 2012, 422 . 424 [UNIV6] The Unicode Consortium, "The Unicode Standard, Version 425 6.2.0 (Mountain View, CA, The Unicode Consortium, 2012, 426 ISBN 978-1-936213-07-8)", October 2012. 428 10.2. Informative References 430 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 431 Identifiers (IRIs)", RFC 3987, January 2005. 433 Appendix A. List of ASCII Symbols and their Bidirectional Character 434 Types 436 To help understand the influence of various symbols on IRI display, 437 this appendix lists all of them, giving the character itself, the 438 Unicode codepoint, the character name, the bidirectional character 439 type (BCT) and the rule and relevance in the IRI syntax. 441 The most important ones in practice are ":", delimining schem and 442 port (CS, Common Number Separator), "/" to indicate generic 443 (hierarchical) schemes and as a path separator (CS, Common Number 444 Separator), "?" to introduce a query part (ON, Other Neutral), "#" to 445 introduce a fragment identifier (ET, European Number Terminator), "." 446 to separate labels in a domain name (CS, Common Number Separator), 447 "&" to separate form parameters (ON, Other Neutral), and "@" to 448 separate user information (ON, Other Neutral). 450 Char Codepoint Character Name BCT IRI syntax 451 ------------------------------------------------------------- 452 "#" U+0023 NUMBER SIGN ET gen-delims, fragments 453 "/" U+002F SOLIDUS CS gen-delims, paths 454 ":" U+003A COLON CS gen-delims, scheme, port 455 "?" U+003F QUESTION MARK ON gen-delims, query part 456 "@" U+0040 COMMERCIAL AT ON gen-delims, user 457 "[" U+005B LEFT SQUARE BRACKET ON gen-delims 458 "]" U+005D RIGHT SQUARE BRACKET ON gen-delims 459 "%" U+0025 PERCENT SIGN ET pcd-encoded 460 "!" U+0021 EXCLAMATION MARK ON sub-delims 461 "," U+002C COMMA CS sub-delims 462 "+" U+002B PLUS SIGN ES sub-delims 463 "$" U+0024 DOLLAR SIGN ET sub-delims 464 "(" U+0028 LEFT PARENTHESIS ON sub-delims 465 "'" U+0027 APOSTROPHE ON sub-delims 466 ")" U+0029 RIGHT PARENTHESIS ON sub-delims 467 "*" U+002A ASTERISK ON sub-delims 468 ";" U+003B SEMICOLON ON sub-delims 469 "=" U+003D EQUALS SIGN ON sub-delims, forms 470 "&" U+0026 AMPERSAND ON sub-delims, forms 471 "." U+002E FULL STOP CS unreserved, domain names 472 "-" U+002D HYPHEN-MINUS ES unreserved 473 "_" U+005F LOW LINE ON unreserved 474 "~" U+007E TILDE ON unreserved 475 " " U+0020 SPACE WS excluded, delim 476 '"' U+0022 QUOTATION MARK ON excluded, delim 477 "\" U+005C REVERSE SOLIDUS ON excluded, unwise 478 "^" U+005E CIRCUMFLEX ACCENT ON excluded, unwise 479 "<" U+003C LESS-THAN SIGN ON excluded, delim 480 ">" U+003E GREATER-THAN SIGN ON excluded, delim 481 "`" U+0060 GRAVE ACCENT ON excluded, unwise 482 "|" U+007C VERTICAL LINE ON excluded, unwise 483 "{" U+007B LEFT CURLY BRACKET ON excluded, delim 484 "}" U+007D RIGHT CURLY BRACKET ON excluded, delim 486 Authors' Addresses 488 Martin J. Duerst (Note: Please write "Duerst" with u-umlaut wherever 489 possible, for example as "Dürst" in XML and HTML.) 490 Aoyama Gakuin University 491 5-10-1 Fuchinobe 492 Chuo-ku 493 Sagamihara, Kanagawa 252-5258 494 Japan 496 Phone: +81 42 759 6329 497 Fax: +81 42 759 6495 498 Email: duerst@it.aoyama.ac.jp 499 URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ 500 (Note: This is the percent-encoded form of an IRI) 502 Larry Masinter 503 Adobe 504 345 Park Ave 505 San Jose, CA 95110 506 U.S.A. 508 Phone: +1-408-536-3024 509 Email: masinter@adobe.com 510 URI: http://larry.masinter.net 512 Adil Allawi 513 Diwan Software Limited 514 37-39 Peckham Road 515 London SE5 8UH 516 United Kingdom 518 Phone: +44 7718 785850 519 Fax: +44 20 72525444 520 Email: adil@diwan.com 521 URI: http://ironymark.diwan.com/