--- 1/draft-ietf-iri-3987bis-01.txt 2010-10-17 07:16:28.000000000 +0200 +++ 2/draft-ietf-iri-3987bis-02.txt 2010-10-17 07:16:29.000000000 +0200 @@ -1,21 +1,21 @@ Internationalized Resource M. Duerst Identifiers (iri) Aoyama Gakuin University Internet-Draft M. Suignard -Obsoletes: RFC 3987 Unicode Consortium -(if approved) L. Masinter -Intended status: Standards Track Adobe -Expires: January 27, 2011 July 26, 2010 +Obsoletes: 3987 (if approved) Unicode Consortium +Intended status: Standards Track L. Masinter +Expires: April 20, 2011 Adobe + October 17, 2010 Internationalized Resource Identifiers (IRIs) - draft-ietf-iri-3987bis-01 + draft-ietf-iri-3987bis-02 Abstract This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. In addition, this document provides named additional rule sets for @@ -26,27 +26,27 @@ Defining IRI as new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: other protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. - [RFC Editor: Please remove this paragraph before publication.] This - document is intended to update RFC 3987 and move towards IETF Draft - Standard. This version is essentially identical to - draft-duerst-iri-bis-07.txt, and is submitted as an initial draft to - start WG discussions. For discussion and comments on this draft, - please join the IETF IRI WG by subscribing to the mailing list - public-iri@w3.org. +RFC Editor: Please remove the next paragraph before publication. + + This document is intended to update RFC 3987 and move towards IETF + Draft Standard. For discussion and comments on this draft, please + join the IETF IRI WG by subscribing to the mailing list + public-iri@w3.org. For a list of open issues, please see the issue + tracker of the WG at http://trac.tools.ietf.org/wg/iri/trac/report/1. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. @@ -55,21 +55,21 @@ 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 January 27, 2011. + This Internet-Draft will expire on April 20, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -116,21 +116,21 @@ 4.3. Input of Bidi IRIs . . . . . . . . . . . . . . . . . . . 23 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Normalization and Comparison . . . . . . . . . . . . . . . . . 25 5.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Preparation for Comparison . . . . . . . . . . . . . . . 26 5.3. Comparison Ladder . . . . . . . . . . . . . . . . . . . . 27 5.3.1. Simple String Comparison . . . . . . . . . . . . . . . 27 5.3.2. Syntax-Based Normalization . . . . . . . . . . . . . . 28 5.3.3. Scheme-Based Normalization . . . . . . . . . . . . . . 31 5.3.4. Protocol-Based Normalization . . . . . . . . . . . . . 32 - 6. Use of IRIs . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 6. Use of IRIs . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Limitations on UCS Characters Allowed in IRIs . . . . . . 33 6.2. Software Interfaces and Protocols . . . . . . . . . . . . 33 6.3. Format of URIs and IRIs in Documents and Protocols . . . 33 6.4. Use of UTF-8 for Encoding Original Characters . . . . . . 34 6.5. Relative IRI References . . . . . . . . . . . . . . . . . 36 7. Liberal handling of otherwise invalid IRIs . . . . . . . . . . 36 7.1. LEIRI processing . . . . . . . . . . . . . . . . . . . . 36 7.2. Web Address processing . . . . . . . . . . . . . . . . . 36 7.3. Characters not allowed in IRIs . . . . . . . . . . . . . 38 8. URI/IRI Processing Guidelines (Informative) . . . . . . . . . 40 @@ -138,44 +138,43 @@ 8.2. URI/IRI Entry . . . . . . . . . . . . . . . . . . . . . . 41 8.3. URI/IRI Transfer between Applications . . . . . . . . . . 42 8.4. URI/IRI Generation . . . . . . . . . . . . . . . . . . . 42 8.5. URI/IRI Selection . . . . . . . . . . . . . . . . . . . . 43 8.6. Display of URIs/IRIs . . . . . . . . . . . . . . . . . . 43 8.7. Interpretation of URIs and IRIs . . . . . . . . . . . . . 44 8.8. Upgrading Strategy . . . . . . . . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 - 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 50 - 13.1. Changes from draft-duerst-iri-bis-07 to - draft-ietf-iri-3987bis-00 . . . . . . . . . . . . . . . . 50 - 13.2. Changes from -06 to -07 of draft-duerst-iri-bis . . . . . 50 - 13.2.1. OLD WAY . . . . . . . . . . . . . . . . . . . . . . . 50 - 13.2.2. NEW WAY . . . . . . . . . . . . . . . . . . . . . . . 51 - 13.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 51 - 13.4. Changes from -05 to -06 of draft-duerst-iri-bis-00 . . . 51 - 13.5. Changes from -04 to -05 of draft-duerst-iri-bis . . . . . 51 - 13.6. Changes from -03 to -04 of draft-duerst-iri-bis . . . . . 52 - 13.7. Changes from -02 to -03 of draft-duerst-iri-bis . . . . . 52 - 13.8. Changes from -01 to -02 of draft-duerst-iri-bis . . . . . 52 - 13.9. Changes from -00 to -01 of draft-duerst-iri-bis . . . . . 52 - 13.10. Changes from RFC 3987 to -00 of draft-duerst-iri-bis . . 52 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 52 - 14.2. Informative References . . . . . . . . . . . . . . . . . 54 - Appendix A. Design Alternatives . . . . . . . . . . . . . . . . . 56 - A.1. New Scheme(s) . . . . . . . . . . . . . . . . . . . . . . 56 - A.2. Character Encodings Other Than UTF-8 . . . . . . . . . . 56 - A.3. New Encoding Convention . . . . . . . . . . . . . . . . . 57 - A.4. Indicating Character Encodings in the URI/IRI . . . . . . 57 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 + 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 12.1. Changes from draft-duerst-iri-bis-07 to + draft-ietf-iri-3987bis-00 . . . . . . . . . . . . . . . . 48 + 12.2. Changes from -06 to -07 of draft-duerst-iri-bis . . . . . 48 + 12.2.1. OLD WAY . . . . . . . . . . . . . . . . . . . . . . . 49 + 12.2.2. NEW WAY . . . . . . . . . . . . . . . . . . . . . . . 49 + 12.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 49 + 12.4. Changes from -05 to -06 of draft-duerst-iri-bis-00 . . . 49 + 12.5. Changes from -04 to -05 of draft-duerst-iri-bis . . . . . 50 + 12.6. Changes from -03 to -04 of draft-duerst-iri-bis . . . . . 50 + 12.7. Changes from -02 to -03 of draft-duerst-iri-bis . . . . . 50 + 12.8. Changes from -01 to -02 of draft-duerst-iri-bis . . . . . 50 + 12.9. Changes from -00 to -01 of draft-duerst-iri-bis . . . . . 50 + 12.10. Changes from RFC 3987 to -00 of draft-duerst-iri-bis . . 51 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 51 + 13.2. Informative References . . . . . . . . . . . . . . . . . 52 + Appendix A. Design Alternatives . . . . . . . . . . . . . . . . . 54 + A.1. New Scheme(s) . . . . . . . . . . . . . . . . . . . . . . 54 + A.2. Character Encodings Other Than UTF-8 . . . . . . . . . . 55 + A.3. New Encoding Convention . . . . . . . . . . . . . . . . . 55 + A.4. Indicating Character Encodings in the URI/IRI . . . . . . 55 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction 1.1. Overview and Motivation A Uniform Resource Identifier (URI) is defined in [RFC3986] as a sequence of characters chosen from a limited subset of the repertoire of US-ASCII [ASCII] characters. The characters in URIs are frequently used for representing words of @@ -1426,30 +1425,26 @@ Normalization should not remove delimiters when their associated component is empty unless it is licensed to do so by the scheme specification. For example, the IRI "http://example.com/?" cannot be assumed to be equivalent to any of the examples above. Likewise, the presence or absence of delimiters within a userinfo subcomponent is usually significant to its interpretation. The fragment component is not subject to any scheme-based normalization; thus, two IRIs that differ only by the suffix "#" are considered different regardless of the scheme. - ((NOTE: THIS NEEDS TO BE UPDATED TO DEAL WITH IDNA8)) Some IRI - schemes may allow the usage of Internationalized Domain Names (IDN) - [RFC3490] either in their ireg-name part or elsewhere. When in use - in IRIs, those names SHOULD be validated by using the ToASCII - operation defined in [RFC3490], with the flags "UseSTD3ASCIIRules" - and "AllowUnassigned". An IRI containing an invalid IDN cannot - successfully be resolved. Validated IDN components of IRIs SHOULD be - character normalized by using the Nameprep process [RFC3491]; - however, for legibility purposes, they SHOULD NOT be converted into - ASCII Compatible Encoding (ACE). + Some IRI schemes allow the usage of Internationalized Domain Names + (IDN) [RFC5890] either in their ireg-name part or elswhere. When in + use in IRIs, those names SHOULD conform to the definition of U-Label + in [RFC5890]. An IRI containing an invalid IDN cannot successfully + be resolved. For legibility purposes, they SHOULD NOT be converted + into ASCII Compatible Encoding (ACE). Scheme-based normalization may also consider IDN components and their conversions to punycode as equivalent. As an example, "http://résumé.example.org" may be considered equivalent to "http://xn--rsum-bpad.example.org". Other scheme-specific normalizations are possible. 5.3.4. Protocol-Based Normalization @@ -1701,21 +1695,21 @@ or defined The HRef-charset is as defined. If the resulting HRef-charset is a unicode based character encoding (e.g., UTF-16), then use UTF-8 instead. The syntax for Web Addresses is obtained by replacing the 'ucschar', pct-form, and path-sep rules with the href-ucschar, href-pct-form, and href-path-sep rules below. In addition, some characters are stripped. - href-ucschar = " " / "<" / ">" / '"' / "{" / "}" / "|" + href-ucschar = " " / "<" / ">" / DQUOTE / "{" / "}" / "|" / "\" / "^" / "`" / %x0-1F / %x7F-D7FF / %xE000-FFFD / %x10000-10FFFF href-pct-form = pct-encoded / "%" href-path-sep = "/" / "\" href-strip = (NOTE: NEED TO FIX THESE SETS TO MATCH HTML5; NOT SURE ABOUT NEXT SENTENCE) browsers did not enforce the restriction on bidirectional formatting characters in Section 4.1, and the iprivate production becomes redundant. @@ -2190,233 +2184,146 @@ McQueen. Thanks to the Internationalization Working Group (I18N WG) of the World Wide Web Consortium (W3C), and the members of the W3C I18N Working Group and Interest Group for their contributions and their work on [CharMod]. Thanks also go to the members of many other W3C Working Groups for adopting IRIs, and to the members of the Montreal IAB Workshop on Internationalization and Localization for their review. -12. Open Issues - - NOTE: The issues noted in this section should be addressed before the - document is submitted as an RFC. These issues are not in any - particular order, and do not necessarily form a complete list of all - known issues. - - length limits on domain name See, for example, - http://lists.w3.org/Archives/Public/public-iri/2009Sep/0064.html - discussion on public-iri@w3.org (that discussion is mostly - irrelevant now as the "63 octets in UTF-8 per label" restriction - was dropped) - - Allow generic scheme-independent IRI to URI translation Previous - drafts of this specification proposed a generic IRI to URI - transformation using pct-encoding, and allowed domain name - translation to be optionally handled by retranslating host names - from pct-encoding back into Unicode and then into punycode. This - draft does not allow that behavior, but this should be fixed to be - in line with RFC 3986 syntax and to lead implementations towards - an uniform an long-term URI<->IRI correspondence. See also - [Gettys] - - update URI scheme registry? This document starts the process of - making minor changes to the URI scheme registry. This should be - handled as an update to RFC 4395. - - utf8 in HTTP Not really IRI issue, but some HTTP implementations - send UTF8 path directly, review. - - handling of \\ Some web applications convert \ to / and others - don't. Make this mandatory or disallowed (but not optional), for - Web Addresses. - - dealing with disallowed IRI characters - - misplaced text Find a place to note that some older software - transcoding to UTF-8 may produce illegal output for some input, in - particular for characters outside the BMP (Basic Multilingual - Plane). As an example, for the IRI with non-BMP characters (in - XML Notation): - "http://example.com/𐌀𐌁𐌂"; - which contains the first three letters of the Old Italic alphabet, - the correct conversion to a URI is - "http://example.com/%F0%90%8C%80%F0%90%8C%81%F0%90%8C%82" - - Special Query Handling needed? The percent-encoding handling of - query components in the HTTP scheme is really unfortunate. There - is no good normative advice to give if the percent-encoding is - delayed until the query-IRI is interpreted. Could HTML ask - browsers to percent-encode the form data using the document - character set BEFORE the query IRI is constructed, and only in the - case where the document character set isn't Unicode-based and the - query is being added to http: or https: URIs? This would give - more consistent results. Browsers might have to change their - behavior in constructing the IRI-with-query-added, but the results - would be more consistent and fewer bugs, and it wouldn't affect - interpretation of any existing web pages. It would remove the - need to have a normative special case for queries in HTML - documents, just for http, in a way in which things like - transcoding etc. wouldn't work well. You could tell the - difference between a query URI in the address bar and one created - via a form because the address bar would always be UTF-8. The - browsers might have to change the algorithm for showing the - address in the adress bar to know how to undo the encoding. - - handling illegal characters Section 3.3 used to apply only to - characters in either 'ucschar' or 'iprivate', but then later said - that systems accepting IRIs MAY also deal with the printable - characters in US-ASCII that are not allowed in URIs, namely "<", - ">", '"', space, "{", "}", "|", "\", "^", and "`". Larry felt - that this a MAY would result in non-uniform behavior, because some - systems would produce valid URI components and others wouldn't. - Non-printable US-ASCII characters should be stripped by most - software, so if they get to if they're passed on somewhere as IRI - characters, encoding them makes sense. The section also used to - say "If these characters are found but are not converted, then the - conversion SHOULD fail." but there is no notion of conversion - failing -- every string is converted. Please note that the number - sign ("#"), the percent sign ("%"), and the square bracket - characters ("[", "]") are not part of the above list and MUST NOT - be converted. - - adding single % and hash Changed the BNF to not match the URI - document in allowing single % in path but not everywhere, and - allowing a # in the fragment part. - -13. Change Log +12. Change Log Note to RFC Editor: Please completely remove this section before publication. -13.1. Changes from draft-duerst-iri-bis-07 to draft-ietf-iri-3987bis-00 +12.1. Changes from draft-duerst-iri-bis-07 to draft-ietf-iri-3987bis-00 Changed draft name, date, last paragraph of abstract, and titles in change log, and added this section in moving from draft-duerst-iri-bis-07 (personal submission) to draft-ietf-iri-3987bis-00 (WG document). -13.2. Changes from -06 to -07 of draft-duerst-iri-bis +12.2. Changes from -06 to -07 of draft-duerst-iri-bis Major restructuring of IRI processing model to make scheme-specific translation necessary to handle IDNA requirements and for consistency with web implementations. Starting with IRI, you want one of: a IRI components (IRI parsed into UTF8 pieces) b URI components (URI parsed into ASCII pieces, encoded correctly) c whole URI (for passing on to some other system that wants whole URIs) -13.2.1. OLD WAY +12.2.1. OLD WAY 1. Pct-encoding on the whole thing to a URI. (c1) If you want a (maybe broken) whole URI, you might stop here. 2. Parsing the URI into URI components. (b1) If you want (maybe broken) URI components, stop here. 3. Decode the components (undoing the pct-encoding). (a) if you want IRI components, stop here. 4. reencode: Either using a different encoding some components (for domain names, and query components in web pages, which depends on the component, scheme and context), and otherwise using pct- encoding. (b2) if you want (good) URI components, stop here. 5. reassemble the reencoded components. (c2) if you want a (*good*) whole URI stop here. -13.2.2. NEW WAY +12.2.2. NEW WAY 1. Parse the IRI into IRI components using the generic syntax. (a) if you want IRI components, stop here. 2. Encode each components, using pct-encoding, IDN encoding, or special query part encoding depending on the component scheme or context. (b) If you want URI components, stop here. 3. reassemble the a whole URI from URI components. (c) if you want a whole URI stop here. -13.3. Changes from -00 to -01 +12.3. Changes from -00 to -01 o Removed 'mailto:' before mail addresses of authors. o Added "" as right side of 'href-strip' rule. Fixed '|' to '/' for alternatives. -13.4. Changes from -05 to -06 of draft-duerst-iri-bis-00 +12.4. Changes from -05 to -06 of draft-duerst-iri-bis-00 o Add HyperText Reference, change abstract, acks and references for it o Add Masinter back as another editor. o Masinter integrates HRef material from HTML5 spec. o Rewrite introduction sections to modernize. -13.5. Changes from -04 to -05 of draft-duerst-iri-bis +12.5. Changes from -04 to -05 of draft-duerst-iri-bis o Updated references. o Changed IPR text to pre5378Trust200902. -13.6. Changes from -03 to -04 of draft-duerst-iri-bis +12.6. Changes from -03 to -04 of draft-duerst-iri-bis o Added explicit abbreviation for LEIRIs. o Mentioned LEIRI references. o Completed text in LEIRI section about tag characters and about specials. -13.7. Changes from -02 to -03 of draft-duerst-iri-bis +12.7. Changes from -02 to -03 of draft-duerst-iri-bis o Updated some references. o Updated Michel Suginard's coordinates. -13.8. Changes from -01 to -02 of draft-duerst-iri-bis +12.8. Changes from -01 to -02 of draft-duerst-iri-bis o Added tag range to iprivate (issue private-include-tags-115). o Added Specials (U+FFF0-FFFD) to Legacy Extended IRIs. -13.9. Changes from -00 to -01 of draft-duerst-iri-bis +12.9. Changes from -00 to -01 of draft-duerst-iri-bis o Changed from "IRIs with Spaces/Controls" to "Legacy Extended IRI" based on input from the W3C XML Core WG. Moved the relevant subsections to the back and promoted them to a section. o Added some text re. Legacy Extended IRIs to the security section. o Added a IANA Consideration Section. o Added this Change Log Section. o Added a section about "IRIs with Spaces/Controls" (converting from a Note in RFC 3987). -13.10. Changes from RFC 3987 to -00 of draft-duerst-iri-bis +12.10. Changes from RFC 3987 to -00 of draft-duerst-iri-bis Fixed errata (see http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=3987). -14. References +13. References -14.1. Normative References +13.1. Normative References [ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [ISO10646] International Organization for Standardization, "ISO/IEC 10646:2003: Information Technology - Universal Multiple- Octet Coded Character Set (UCS)", ISO Standard 10646, December 2003. @@ -2432,40 +2339,47 @@ Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, August 2010. + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, August 2010. + [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [UNI9] Davis, M., "The Bidirectional Algorithm", Unicode Standard Annex #9, March 2004, . [UNIV4] The Unicode Consortium, "The Unicode Standard, Version 5.1.0, defined by: The Unicode Standard, Version 5.0 (Boston, MA, Addison-Wesley, 2007. ISBN 0-321-48091-0), as amended by Unicode 4.1.0 (http://www.unicode.org/versions/Unicode5.1.0/)", April 2008. [UTR15] Davis, M. and M. Duerst, "Unicode Normalization Forms", Unicode Standard Annex #15, March 2008, . -14.2. Informative References +13.2. Informative References [BidiEx] "Examples of bidirectional IRIs", . [CharMod] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., and T. Texin, "Character Model for the World Wide Web: Resource Identifiers", World Wide Web Consortium Candidate Recommendation, November 2004, . @@ -2533,20 +2447,24 @@ [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [UNIXML] Duerst, M. and A. Freytag, "Unicode in XML and other Markup Languages", Unicode Technical Report #20, World Wide Web Consortium Note, June 2003, . + [UTR36] Davis, M. and M. Suignard, "Unicode Security + Considerations", Unicode Technical Report #36, + August 2010, . + [XLink] DeRose, S., Maler, E., and D. Orchard, "XML Linking Language (XLink) Version 1.0", World Wide Web Consortium Recommendation, June 2001, . [XML1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Forth Edition)", World Wide Web Consortium Recommendation, August 2006, . @@ -2629,21 +2547,21 @@ If UTF-8 is used exclusively, an upgrade to the URI syntax is not needed. It avoids potentially multiple labels that have to be copied correctly in all cases, even on the side of a bus or on a napkin, leading to usability problems (and being prohibitively annoying). Exclusively using UTF-8 also reduces transcoding errors and confusion. Authors' Addresses Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever - possible, for example as "Dürst" in XML and HTML') + possible, for example as "Dürst" in XML and HTML) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan Phone: +81 42 759 6329 Fax: +81 42 759 6495 Email: duerst@it.aoyama.ac.jp URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ (Note: This is the percent-encoded form of an IRI)