source: draft-ietf-iri-3987bis/draft-ietf-iri-comparison.xml @ 78

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

adding draft-ietf-iri-bidi-guidelines.xml and draft-ietf-iri-comparison.xml (version -00)

File size: 29.3 KB
Line 
1<?xml version="1.0"?>
2<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
3<!ENTITY rfc2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
4<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
5<!ENTITY rfc2130 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2130.xml">
6<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
7<!ENTITY rfc3490 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml">
8<!ENTITY rfc3491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3491.xml">
9<!ENTITY rfc3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
10<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
11<!ENTITY rfc3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
12<!ENTITY rfc5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
13]>
14<?rfc strict='yes'?>
15
16<?xml-stylesheet type='text/css' href='rfc2629.css' ?>
17<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
18<?rfc symrefs='yes'?>
19<?rfc sortrefs='yes'?>
20<?rfc iprnotified="no" ?>
21<?rfc toc='yes'?>
22<?rfc compact='yes'?>
23<?rfc subcompact='no'?>
24<rfc ipr="pre5378Trust200902" docName="draft-ietf-iri-comparison-00" category="std" xml:lang="en">
25<front>
26<title abbrev="IRI Equivalence">Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs)</title>
27
28<author initials="L." surname="Masinter" fullname="Larry Masinter">
29   <organization>Adobe</organization>
30   <address>
31   <postal>
32   <street>345 Park Ave</street>
33   <city>San Jose</city>
34   <region>CA</region>
35   <code>95110</code>
36   <country>U.S.A.</country>
37   </postal>
38   <phone>+1-408-536-3024</phone>
39   <email>masinter@adobe.com</email>
40   <uri>http://larry.masinter.net</uri>
41   </address>
42</author>
43
44  <author initials="M.J." surname="Duerst" fullname='Martin Duerst'>
45    <!-- (Note: Please write "Duerst" with u-umlaut wherever
46      possible, for example as "D&#252;rst" in XML and HTML) -->
47  <organization abbrev="Aoyama Gakuin University">Aoyama Gakuin University</organization>
48  <address>
49  <postal>
50  <street>5-10-1 Fuchinobe</street>
51  <city>Sagamihara</city>
52  <region>Kanagawa</region>
53  <code>229-8558</code>
54  <country>Japan</country>
55  </postal>
56  <phone>+81 42 759 6329</phone>
57  <facsimile>+81 42 759 6495</facsimile>
58  <email>duerst@it.aoyama.ac.jp</email>
59  <uri>http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/<!-- (Note: This is the percent-encoded form of an IRI)--></uri>
60  </address>
61</author>
62
63
64<date year="2011" month="August" day="14" />
65<area>Applications</area>
66<workgroup>Internationalized Resource Identifiers (iri)</workgroup>
67<keyword>IRI</keyword>
68<keyword>Internationalized Resource Identifier</keyword>
69<keyword>UTF-8</keyword>
70<keyword>URI</keyword>
71<keyword>URL</keyword>
72<keyword>IDN</keyword>
73<keyword>Normalization</keyword>
74<keyword>Canonicalization</keyword>
75<abstract>
76<t>Internationalized Resource Identifiers (IRIs) are unicode strings
77used to identify resources on the Internet. Applications that use
78IRIs often define a means of comparing two IRIs to determine
79when two IRIs are equivalent for the purpose of that
80application. Some applications also define a method
81for 'canonicalizing' or 'normalizing' an IRI -- translating one
82IRI into another which is equivalent under the comparison
83method used.</t>
84<t>This document gives guidelines and best practices for defining
85and using IRI comparison, equivalence, normalization and canonicalization
86methods.</t>
87</abstract>
88
89</front>
90<middle>
91
92<section title="Introduction">
93
94<t>Internationalized Resource Identifiers (IRIs) are unicode strings
95used to identify resources on the Internet. Applications that use
96IRIs often define a means of comparing two IRIs to determine
97when two IRIs are equivalent for the purpose of that
98application. Some applications also define a method
99for 'canonicalizing' or 'normalizing' an IRI -- translating one
100IRI into another which is equivalent under the comparison
101method used.</t>
102<t>This document gives guidelines and best practices for defining
103and using IRI comparison, equivalence, normalization and canonicalization
104methods.</t>
105
106<t>Things to do:
107<list style="symbols"><t>Introductory section on comparison, equivalence, normalization and
108canonicalization.</t>
109<t> Verify acknowledgements for this component.</t>
110<t> Verify cross-references from other documents.</t>
111<t> Consider making 4395bis reference this document and recommend scheme definitions describe equivalence
112specifically.
113</t>
114<t> Consider making this document 'update' 3986 in order to resolve which one is normative if there are conflicts. </t>
115<t> alternatively? Consider making this document BCP rather than standards track, since it basically gives
116  guidance for protocols and applications needing equivalence, and doesn't directly have a scope of application? </t>
117<t> Distingish between IRIs as sequence-of-unicode characters and presentations of IRIs. </t>
118<t> Should we insist that percent-hex encoding equivalence of non-reserved characters
119  MUST be always used if there is any equivalence at all? </t>
120<t> Update security considerations to describe security concerns specific to comparison.</t>
121<t> Consider making sections talk about 'equivalent' rather than 'normalization' where
122  appropriate. </t>
123</list></t>
124
125<t>One of the most common operations on IRIs is simple comparison:
126Determining whether two IRIs are equivalent, without using the IRIs to
127access their respective resource(s). A comparison is performed
128whenever a response cache is accessed, a browser checks its history to
129color a link, or an XML parser processes tags within a
130namespace. Extensive normalization prior to comparison of IRIs may be
131used by spiders and indexing engines to prune a search space or reduce
132duplication of request actions and response storage.</t>
133
134<t>IRI comparison is performed for some particular purpose. Protocols
135or implementations that compare IRIs for different purposes will often
136be subject to differing design trade-offs in regards to how much
137effort should be spent in reducing aliased identifiers. This document
138describes various methods that may be used to compare IRIs, the
139trade-offs between them, and the types of applications that might use
140them.</t>
141
142</section> <!-- introduction -->
143
144<section title="Equivalence">
145
146<t>Because IRIs exist to identify resources, presumably they should be
147considered equivalent when they identify the same resource. However,
148this definition of equivalence is not of much practical use, as there
149is no way for an implementation to compare two resources to determine
150if they are "the same" unless it has full knowledge or control of
151them. For this reason, determination of equivalence or difference of
152IRIs is based on string comparison, perhaps augmented by reference to
153additional rules provided by URI scheme definitions.  We use the terms
154"different" and "equivalent" to describe the possible outcomes of such
155comparisons, but there are many application-dependent versions of
156equivalence.</t>
157
158<t>Even when it is possible to determine that two IRIs are equivalent,
159IRI comparison is not sufficient to determine whether two IRIs
160identify different resources. For example, an owner of two different
161domain names could decide to serve the same resource from both,
162resulting in two different IRIs. Therefore, comparison methods are
163designed to minimize false negatives while strictly avoiding false
164positives.</t>
165
166<t>In testing for equivalence, applications should not directly
167compare relative references; the references should be converted to
168their respective target IRIs before comparison. When IRIs are compared
169to select (or avoid) a network action, such as retrieval of a
170representation, fragment components (if any) MUST be excluded from
171the comparison.</t>
172
173<t>Applications using IRIs as identity tokens with no relationship to
174a protocol MUST use the Simple String Comparison (see <xref
175target="stringcomp"></xref>).  All other applications MUST select one
176of the comparison practices from the Comparison Ladder (see <xref
177target="ladder"></xref>.</t>
178</section> <!-- equivalence -->
179
180<section title="Preparation for Comparison">
181<t>Any kind of IRI comparison REQUIRES that any additional contextual
182processing is first performed, including undoing higher-level
183escapings or encodings in the protocol or format that carries an
184IRI. This preprocessing is usually done when the protocol or format is
185parsed.</t>
186
187<t>Examples of such escapings or encodings are entities and
188numeric character references in <xref target="HTML4"></xref> and <xref
189target="XML1"></xref>. As an example,
190"http://example.org/ros&amp;eacute;" (in HTML),
191"http://example.org/ros&amp;#233;" (in HTML or XML), and
192<vspace/>"http://example.org/ros&amp;#xE9;" (in HTML or XML) are all
193resolved into what is denoted in this document (see 'Notation' section of <xref
194target="RFC3987bis" />) as "http://example.org/ros&amp;#xE9;"
195(the "&amp;#xE9;" here standing for the actual e-acute character, to
196compensate for the fact that this document cannot contain non-ASCII
197characters).</t>
198
199<t>Similar considerations apply to encodings such as Transfer Codings
200in HTTP (see <xref target="RFC2616"></xref>) and Content Transfer
201Encodings in MIME (<xref target="RFC2045"></xref>), although in these
202cases, the encoding is based not on characters but on octets, and
203additional care is required to make sure that characters, and not just
204arbitrary octets, are compared (see <xref
205target="stringcomp"></xref>).</t>
206
207</section> <!-- preparation -->
208
209<section title="Comparison Ladder" anchor="ladder">
210
211<t>In practice, a variety of methods are used to test IRI
212equivalence. These methods fall into a range distinguished by the
213amount of processing required and the degree to which the probability
214of false negatives is reduced. As noted above, false negatives cannot
215be eliminated. In practice, their probability can be reduced, but this
216reduction requires more processing and is not cost-effective for all
217applications.</t>
218
219
220<t>If this range of comparison practices is considered as a ladder,
221the following discussion will climb the ladder, starting with
222practices that are cheap but have a relatively higher chance of
223producing false negatives, and proceeding to those that have higher
224computational cost and lower risk of false negatives.</t>
225
226<section title="Simple String Comparison" anchor="stringcomp">
227
228<t>If two IRIs, when considered as character strings, are identical,
229then it is safe to conclude that they are equivalent.  This type of
230equivalence test has very low computational cost and is in wide use in
231a variety of applications, particularly in the domain of parsing. It
232is also used when a definitive answer to the question of IRI
233equivalence is needed that is independent of the scheme used and that
234can be calculated quickly and without accessing a network. An example
235of such a case is XML Namespaces (<xref
236target="XMLNamespace"></xref>).</t>
237
238
239<t>Testing strings for equivalence requires some basic precautions.
240This procedure is often referred to as "bit-for-bit" or
241"byte-for-byte" comparison, which is potentially misleading. Testing
242strings for equality is normally based on pair comparison of the
243characters that make up the strings, starting from the first and
244proceeding until both strings are exhausted and all characters are
245found to be equal, until a pair of characters compares unequal, or
246until one of the strings is exhausted before the other.</t>
247
248<t>This character comparison requires that each pair of characters be
249put in comparable encoding form. For example, should one IRI be stored
250in a byte array in UTF-8 encoding form and the second in a UTF-16
251encoding form, bit-for-bit comparisons applied naively will produce
252errors. It is better to speak of equality on a character-for-character
253rather than on a byte-for-byte or bit-for-bit basis.  In practical
254terms, character-by-character comparisons should be done codepoint by
255codepoint after conversion to a common character encoding form.
256
257When comparing character by character, the comparison function MUST
258NOT map IRIs to URIs, because such a mapping would create additional
259spurious equivalences. It follows that an IRI SHOULD NOT be modified
260when being transported if there is any chance that this IRI might be
261used in a context that uses Simple String Comparison.</t>
262
263
264<t>False negatives are caused by the production and use of IRI
265aliases. Unnecessary aliases can be reduced, regardless of the
266comparison method, by consistently providing IRI references in an
267already normalized form (i.e., a form identical to what would be
268produced after normalization is applied, as described below).
269Protocols and data formats often limit some IRI comparisons to simple
270string comparison, based on the theory that people and implementations
271will, in their own best interest, be consistent in providing IRI
272references, or at least be consistent enough to negate any efficiency
273that might be obtained from further normalization.</t>
274</section> <!-- stringcomp -->
275
276<section title="Syntax-Based Normalization">
277
278<figure><preamble>Implementations may use logic based on the
279definitions provided by this specification to reduce the probability
280of false negatives. This processing is moderately higher in cost than
281character-for-character string comparison. For example, an application
282using this approach could reasonably consider the following two IRIs
283equivalent:</preamble>
284
285<artwork>
286   example://a/b/c/%7Bfoo%7D/ros&amp;#xE9;
287   eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9
288</artwork></figure>
289
290<t>Web user agents, such as browsers, typically apply this type of IRI
291normalization when determining whether a cached response is
292available. Syntax-based normalization includes such techniques as case
293normalization, character normalization, percent-encoding
294normalization, and removal of dot-segments.</t>
295
296<section title="Case Normalization">
297
298<t>For all IRIs, the hexadecimal digits within a percent-encoding
299triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
300should be normalized to use uppercase letters for the digits A-F.</t>
301
302<t>When an IRI uses components of the generic syntax, the component
303syntax equivalence rules always apply; namely, that the scheme and
304US-ASCII only host are case insensitive and therefore should be
305normalized to lowercase. For example, the URI
306"HTTP://www.EXAMPLE.com/" is equivalent to
307"http://www.example.com/". Case equivalence for non-ASCII characters
308in IRI components that are IDNs are discussed in <xref
309target="schemecomp"></xref>.  The other generic syntax components are
310assumed to be case sensitive unless specifically defined otherwise by
311the scheme.</t>
312
313<t>Creating schemes that allow case-insensitive syntax components
314containing non-ASCII characters should be avoided. Case normalization
315of non-ASCII characters can be culturally dependent and is always a
316complex operation. The only exception concerns non-ASCII host names
317for which the character normalization includes a mapping step derived
318from case folding.</t>
319
320</section> <!-- casenorm -->
321
322<section title="Character Normalization" anchor="normalization">
323
324<t>The Unicode Standard <xref target="UNIV6"></xref> defines various
325equivalences between sequences of characters for various
326purposes. Unicode Standard Annex #15 <xref target="UTR15"></xref>
327defines various Normalization Forms for these equivalences, in
328particular Normalization Form C (NFC, Canonical Decomposition,
329followed by Canonical Composition) and Normalization Form KC (NFKC,
330Compatibility Decomposition, followed by Canonical Composition).</t>
331
332<t> IRIs already in Unicode MUST NOT be normalized before parsing or
333interpreting. In many non-Unicode character encodings, some text
334cannot be represented directly. For example, the word "Vietnam" is
335natively written "Vi&amp;#x1EC7;t Nam" (containing a LATIN SMALL
336LETTER E WITH CIRCUMFLEX AND DOT BELOW) in NFC, but a direct
337transcoding from the windows-1258 character encoding leads to
338"Vi&amp;#xEA;&amp;#x323;t Nam" (containing a LATIN SMALL LETTER E WITH
339CIRCUMFLEX followed by a COMBINING DOT BELOW). Direct transcoding of
340other 8-bit encodings of Vietnamese may lead to other
341representations.</t>
342
343<t>Equivalence of IRIs MUST rely on the assumption that IRIs are
344appropriately pre-character-normalized rather than apply character
345normalization when comparing two IRIs. The exceptions are conversion
346from a non-digital form, and conversion from a non-UCS-based character
347encoding to a UCS-based character encoding. In these cases, NFC or a
348normalizing transcoder using NFC MUST be used for interoperability. To
349avoid false negatives and problems with transcoding, IRIs SHOULD be
350created by using NFC. Using NFKC may avoid even more problems; for
351example, by choosing half-width Latin letters instead of full-width
352ones, and full-width instead of half-width Katakana.</t>
353
354
355<t>As an example,
356"http://www.example.org/r&amp;#xE9;sum&amp;#xE9;.html" (in XML
357Notation) is in NFC. On the other hand,
358"http://www.example.org/re&amp;#x301;sume&amp;#x301;.html" is not in
359NFC.</t>
360
361<t>The former uses precombined e-acute characters, and the latter uses
362"e" characters followed by combining acute accents. Both usages are
363defined as canonically equivalent in <xref target="UNIV6"></xref>.</t>
364
365<t><list style="hanging">
366
367<t hangText="Note:">
368Because it is unknown how a particular sequence of characters is being
369treated with respect to character normalization, it would be
370inappropriate to allow third parties to normalize an IRI
371arbitrarily. This does not contradict the recommendation that when a
372resource is created, its IRI should be as character normalized as
373possible (i.e., NFC or even NFKC). This is similar to the
374uppercase/lowercase problems.  Some parts of a URI are case
375insensitive (for example, the domain name). For others, it is unclear
376whether they are case sensitive, case insensitive, or something in
377between (e.g., case sensitive, but with a multiple choice selection if
378the wrong case is used, instead of a direct negative result).  The
379best recipe is that the creator use a reasonable capitalization and,
380when transferring the URI, capitalization never be
381changed.</t></list></t>
382
383<t>Various IRI schemes may allow the usage of Internationalized Domain
384Names (IDN) <xref target="RFC5890"/> either in the ireg-name
385part or elsewhere. Character Normalization also applies to IDNs, as
386discussed in <xref target="schemecomp"/>.</t>
387</section> <!-- charnorm -->
388
389<section title="Percent-Encoding Normalization">
390
391<t>The percent-encoding mechanism (Section 2.1 of <xref
392target="RFC3986"></xref>) is a frequent source of variance among
393otherwise identical IRIs. In addition to the case normalization issue
394noted above, some IRI producers percent-encode octets that do not
395require percent-encoding, resulting in IRIs that are equivalent to
396their nonencoded counterparts. These IRIs should be normalized by
397decoding any percent-encoded octet sequence that corresponds to an
398unreserved character, as described in section 2.3 of <xref
399target="RFC3986"></xref>.</t>
400
401<t>For actual resolution, differences in percent-encoding (except for
402the percent-encoding of reserved characters) MUST always result in the
403same resource.  For example, "http://example.org/~user",
404"http://example.org/%7euser", and "http://example.org/%7Euser", must
405resolve to the same resource.</t>
406
407<t>If this kind of equivalence is to be tested, the percent-encoding
408of both IRIs to be compared has to be aligned; for example, by
409converting both IRIs to URIs (see Section 3.1), eliminating escape
410differences in the resulting URIs, and making sure that the case of
411the hexadecimal characters in the percent-encoding is always the same
412(preferably upper case). If the IRI is to be passed to another
413application or used further in some other way, its original form MUST
414be preserved.  The conversion described here should be performed only
415for local comparison.</t>
416
417</section> <!-- pctnorm -->
418
419<section title="Path Segment Normalization">
420
421<t>The complete path segments "." and ".." are intended only for use
422within relative references (Section 4.1 of <xref
423target="RFC3986"></xref>) and are removed as part of the reference
424resolution process (Section 5.2 of <xref target="RFC3986"></xref>).
425However, some implementations may incorrectly assume that reference
426resolution is not necessary when the reference is already an IRI, and
427thus fail to remove dot-segments when they occur in non-relative
428paths.  IRI normalizers should remove dot-segments by applying the
429remove_dot_segments algorithm to the path, as described in Section
4305.2.4 of <xref target="RFC3986"></xref>.</t>
431
432</section> <!-- pathnorm -->
433</section> <!-- ladder -->
434
435<section title="Scheme-Based Normalization" anchor="schemecomp">
436
437<t>The syntax and semantics of IRIs vary from scheme to scheme, as
438described by the defining specification for each
439scheme. Implementations may use scheme-specific rules, at further
440processing cost, to reduce the probability of false negatives. For
441example, because the "http" scheme makes use of an authority
442component, has a default port of "80", and defines an empty path to be
443equivalent to "/", the following four IRIs are equivalent:</t>
444
445<figure><artwork>
446   http://example.com
447   http://example.com/
448   http://example.com:/
449   http://example.com:80/</artwork></figure>
450
451<t>In general, an IRI that uses the generic syntax for authority with
452an empty path should be normalized to a path of "/". Likewise, an
453explicit ":port", for which the port is empty or the default for the
454scheme, is equivalent to one where the port and its ":" delimiter are
455elided and thus should be removed by scheme-based normalization. For
456example, the second IRI above is the normal form for the "http"
457scheme.</t>
458
459<t>Another case where normalization varies by scheme is in the
460handling of an empty authority component or empty host
461subcomponent. For many scheme specifications, an empty authority or
462host is considered an error; for others, it is considered equivalent
463to "localhost" or the end-user's host. When a scheme defines a default
464for authority and an IRI reference to that default is desired, the
465reference should be normalized to an empty authority for the sake of
466uniformity, brevity, and internationalization. If, however, either the
467userinfo or port subcomponents are non-empty, then the host should be
468given explicitly even if it matches the default.</t>
469
470<t>Normalization should not remove delimiters when their associated
471component is empty unless it is licensed to do so by the scheme
472specification. For example, the IRI "http://example.com/?" cannot be
473assumed to be equivalent to any of the examples above. Likewise, the
474presence or absence of delimiters within a userinfo subcomponent is
475usually significant to its interpretation.  The fragment component is
476not subject to any scheme-based normalization; thus, two IRIs that
477differ only by the suffix "#" are considered different regardless of
478the scheme.</t>
479 
480<t>Some IRI schemes allow the usage of Internationalized Domain
481Names (IDN) <xref target='RFC5890'></xref> either in their ireg-name
482part or elswhere. When in use in IRIs, those names SHOULD
483conform to the definition of U-Label in <xref
484target='RFC5890'></xref>. An IRI containing an invalid IDN cannot
485successfully be resolved. For legibility purposes, they
486SHOULD NOT be converted into ASCII Compatible Encoding (ACE).</t>
487
488<t>Scheme-based normalization may also consider IDN
489components and their conversions to punycode as equivalent. As an
490example, "http://r&amp;#xE9;sum&amp;#xE9;.example.org" may be
491considered equivalent to
492"http://xn--rsum-bpad.example.org".</t><t>Other scheme-specific
493normalizations are possible.</t>
494
495</section> <!-- schemenorm -->
496
497<section title="Protocol-Based Normalization">
498
499<t>Substantial effort to reduce the incidence of false negatives is
500often cost-effective for web spiders. Consequently, they implement
501even more aggressive techniques in IRI comparison. For example, if
502they observe that an IRI such as</t>
503
504<figure><artwork>
505   http://example.com/data</artwork></figure>
506<t>redirects to an IRI differing only in the trailing slash</t>
507<figure><artwork>
508   http://example.com/data/</artwork></figure>
509
510<t>they will likely regard the two as equivalent in the future.  This
511kind of technique is only appropriate when equivalence is clearly
512indicated by both the result of accessing the resources and the common
513conventions of their scheme's dereference algorithm (in this case, use
514of redirection by HTTP origin servers to avoid problems with relative
515references).</t>
516
517</section> <!-- protonorm -->
518</section> <!-- equivalence -->
519
520<section title="Security Considerations" anchor="security">
521<t>The primary security difficulty comes from applications choosing the
522wrong equivalence relationship, or two different parties disagreeing
523on equivalence. This is especially a problem when IRIs are used in
524security protocols.</t>
525
526<t>Besides the large character repertoire of Unicode, reasons for
527  confusion include different forms of normalization and different normalization
528  expectations, use of percent-encoding with various legacy encodings,
529  and bidirectionality issues. See also <xref target='UTR36'/>.</t>
530
531</section><!-- security -->
532
533<section title="Acknowledgements">
534
535<t>This document was originally derived from <xref target="RFC3986"/>
536and <xref target="RFC3987"/>, based on text contributed by Tim
537Bray.</t>
538</section>
539
540</middle>
541
542<back>
543<references title="Normative References">
544
545      <reference anchor="RFC3987bis" 
546         target="http://tools.ietf.org/id/draft-ietf-iri-3987bis">
547         
548          <front>
549            <title>Internationalized Resource Identifiers (IRIs)</title>
550          <author initials="M." surname="Duerst"/>
551          <author initials="L." surname="Masinter" fullname="Larry Masinter"/>
552          <author initials="M." surname="Suignard"/>
553          <date year="2011"/>
554          </front>
555      </reference>
556
557
558&rfc2119;
559&rfc3490;
560&rfc3491;
561&rfc3629;
562&rfc3986;
563&rfc5890;
564
565<reference anchor="UNIV6">
566<front>
567<title>The Unicode Standard, Version 6.0.0 (Mountain View, CA, The Unicode Consortium, 2011, ISBN 978-1-936213-01-6)</title>
568<author><organization>The Unicode Consortium</organization></author>
569<date year="2010" month="October"/>
570</front>
571</reference>
572
573
574<reference anchor="UTR15" target="http://www.unicode.org/unicode/reports/tr15/tr15-23.html">
575<front>
576<title>Unicode Normalization Forms</title>
577<author initials="M." surname="Davis" fullname="Mark Davis"><organization/></author>
578<author initials="M.J." surname="Duerst" fullname="Martin Duerst"><organization/></author>
579<date year="2008" month="March"/>
580</front>
581<seriesInfo name="Unicode Standard Annex" value="#15"/>
582</reference>
583
584</references>
585
586<references title="Informative References">
587
588<reference anchor="HTML4" target="http://www.w3.org/TR/html401/appendix/notes.html#h-B.2">
589<front>
590<title>HTML 4.01 Specification</title>
591<author initials="D." surname="Raggett" fullname="Dave Raggett"><organization/></author>
592<author initials="A." surname="Le Hors" fullname="Arnaud Le Hors"><organization/></author>
593<author initials="I." surname="Jacobs" fullname="Ian Jacobs"><organization/></author>
594<date year="1999" month="December" day="24"/>
595</front>
596<seriesInfo name="World Wide Web Consortium" value="Recommendation"/>
597</reference>
598
599&rfc2045;
600&rfc3987;
601&rfc2616;
602 
603
604<reference anchor="UTR36" target="http://unicode.org/reports/tr36/">
605<front>
606<title>Unicode Security Considerations</title>
607<author initials="M." surname="Davis" fullname="Mark Davis"><organization/></author>
608<author initials="M." surname="Suignard" fullname="Michel Suignard"><organization/></author>
609<date year="2010" month="August" day="4"/>
610</front>
611<seriesInfo name="Unicode Technical Report" value="#36"/>
612</reference>
613
614<reference anchor="XML1" target="http://www.w3.org/TR/REC-xml">
615  <front>
616    <title>Extensible Markup Language (XML) 1.0 (Forth Edition)</title>
617    <author initials="T." surname="Bray" fullname="Tim Bray"><organization/></author>
618    <author initials="J." surname="Paoli" fullname="Jean Paoli"><organization/></author>
619    <author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
620      <organization/></author>
621    <author initials="E." surname="Maler" fullname="Eve Maler"><organization/></author>
622    <author initials="F." surname="Yergeau" fullname="Francois Yergeau"><organization/></author>
623    <date day="16" month="August" year="2006"/>
624  </front>
625  <seriesInfo name="World Wide Web Consortium" value="Recommendation"/>
626</reference>
627
628<reference anchor="XMLNamespace" target="http://www.w3.org/TR/REC-xml-names">
629  <front>
630    <title>Namespaces in XML (Second Edition)</title>
631    <author initials="T." surname="Bray" fullname="Tim Bray"><organization/></author>
632    <author initials="D." surname="Hollander" fullname="Dave Hollander"><organization/></author>
633    <author initials="A." surname="Layman" fullname="Andrew Layman"><organization/></author>
634    <author initials="R." surname="Tobin" fullname="Richard Tobin"><organization></organization></author>
635    <date day="16" month="August" year="2006"/>
636  </front>
637  <seriesInfo name="World Wide Web Consortium" value="Recommendation"/>
638</reference>
639
640</references>
641
642</back>
643</rfc>
Note: See TracBrowser for help on using the repository browser.