One document matched: draft-ietf-iri-comparison-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2130 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2130.xml">
<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc3490 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml">
<!ENTITY rfc3491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3491.xml">
<!ENTITY rfc3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY rfc5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
]>
<?rfc strict='yes'?>
<?xml-stylesheet type='text/css' href='rfc2629.css' ?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc symrefs='yes'?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified="no" ?>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc ipr="pre5378Trust200902" docName="draft-ietf-iri-comparison-00" category="std" xml:lang="en">
<front>
<title abbrev="IRI Equivalence">Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs)</title>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization>Adobe</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>U.S.A.</country>
</postal>
<phone>+1-408-536-3024</phone>
<email>masinter@adobe.com</email>
<uri>http://larry.masinter.net</uri>
</address>
</author>
<author initials="M.J." surname="Duerst" fullname='Martin Duerst'>
<!-- (Note: Please write "Duerst" with u-umlaut wherever
possible, for example as "Dürst" in XML and HTML) -->
<organization abbrev="Aoyama Gakuin University">Aoyama Gakuin University</organization>
<address>
<postal>
<street>5-10-1 Fuchinobe</street>
<city>Sagamihara</city>
<region>Kanagawa</region>
<code>229-8558</code>
<country>Japan</country>
</postal>
<phone>+81 42 759 6329</phone>
<facsimile>+81 42 759 6495</facsimile>
<email>duerst@it.aoyama.ac.jp</email>
<uri>http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/<!-- (Note: This is the percent-encoded form of an IRI)--></uri>
</address>
</author>
<date year="2011" month="August" day="14" />
<area>Applications</area>
<workgroup>Internationalized Resource Identifiers (iri)</workgroup>
<keyword>IRI</keyword>
<keyword>Internationalized Resource Identifier</keyword>
<keyword>UTF-8</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>IDN</keyword>
<keyword>Normalization</keyword>
<keyword>Canonicalization</keyword>
<abstract>
<t>Internationalized Resource Identifiers (IRIs) are unicode strings
used to identify resources on the Internet. Applications that use
IRIs often define a means of comparing two IRIs to determine
when two IRIs are equivalent for the purpose of that
application. Some applications also define a method
for 'canonicalizing' or 'normalizing' an IRI -- translating one
IRI into another which is equivalent under the comparison
method used.</t>
<t>This document gives guidelines and best practices for defining
and using IRI comparison, equivalence, normalization and canonicalization
methods.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Internationalized Resource Identifiers (IRIs) are unicode strings
used to identify resources on the Internet. Applications that use
IRIs often define a means of comparing two IRIs to determine
when two IRIs are equivalent for the purpose of that
application. Some applications also define a method
for 'canonicalizing' or 'normalizing' an IRI -- translating one
IRI into another which is equivalent under the comparison
method used.</t>
<t>This document gives guidelines and best practices for defining
and using IRI comparison, equivalence, normalization and canonicalization
methods.</t>
<t>Things to do:
<list style="symbols"><t>Introductory section on comparison, equivalence, normalization and
canonicalization.</t>
<t> Verify acknowledgements for this component.</t>
<t> Verify cross-references from other documents.</t>
<t> Consider making 4395bis reference this document and recommend scheme definitions describe equivalence
specifically.
</t>
<t> Consider making this document 'update' 3986 in order to resolve which one is normative if there are conflicts. </t>
<t> alternatively? Consider making this document BCP rather than standards track, since it basically gives
guidance for protocols and applications needing equivalence, and doesn't directly have a scope of application? </t>
<t> Distingish between IRIs as sequence-of-unicode characters and presentations of IRIs. </t>
<t> Should we insist that percent-hex encoding equivalence of non-reserved characters
MUST be always used if there is any equivalence at all? </t>
<t> Update security considerations to describe security concerns specific to comparison.</t>
<t> Consider making sections talk about 'equivalent' rather than 'normalization' where
appropriate. </t>
</list></t>
<t>One of the most common operations on IRIs is simple comparison:
Determining whether two IRIs are equivalent, without using the IRIs to
access their respective resource(s). A comparison is performed
whenever a response cache is accessed, a browser checks its history to
color a link, or an XML parser processes tags within a
namespace. Extensive normalization prior to comparison of IRIs may be
used by spiders and indexing engines to prune a search space or reduce
duplication of request actions and response storage.</t>
<t>IRI comparison is performed for some particular purpose. Protocols
or implementations that compare IRIs for different purposes will often
be subject to differing design trade-offs in regards to how much
effort should be spent in reducing aliased identifiers. This document
describes various methods that may be used to compare IRIs, the
trade-offs between them, and the types of applications that might use
them.</t>
</section> <!-- introduction -->
<section title="Equivalence">
<t>Because IRIs exist to identify resources, presumably they should be
considered equivalent when they identify the same resource. However,
this definition of equivalence is not of much practical use, as there
is no way for an implementation to compare two resources to determine
if they are "the same" unless it has full knowledge or control of
them. For this reason, determination of equivalence or difference of
IRIs is based on string comparison, perhaps augmented by reference to
additional rules provided by URI scheme definitions. We use the terms
"different" and "equivalent" to describe the possible outcomes of such
comparisons, but there are many application-dependent versions of
equivalence.</t>
<t>Even when it is possible to determine that two IRIs are equivalent,
IRI comparison is not sufficient to determine whether two IRIs
identify different resources. For example, an owner of two different
domain names could decide to serve the same resource from both,
resulting in two different IRIs. Therefore, comparison methods are
designed to minimize false negatives while strictly avoiding false
positives.</t>
<t>In testing for equivalence, applications should not directly
compare relative references; the references should be converted to
their respective target IRIs before comparison. When IRIs are compared
to select (or avoid) a network action, such as retrieval of a
representation, fragment components (if any) MUST be excluded from
the comparison.</t>
<t>Applications using IRIs as identity tokens with no relationship to
a protocol MUST use the Simple String Comparison (see <xref
target="stringcomp"></xref>). All other applications MUST select one
of the comparison practices from the Comparison Ladder (see <xref
target="ladder"></xref>.</t>
</section> <!-- equivalence -->
<section title="Preparation for Comparison">
<t>Any kind of IRI comparison REQUIRES that any additional contextual
processing is first performed, including undoing higher-level
escapings or encodings in the protocol or format that carries an
IRI. This preprocessing is usually done when the protocol or format is
parsed.</t>
<t>Examples of such escapings or encodings are entities and
numeric character references in <xref target="HTML4"></xref> and <xref
target="XML1"></xref>. As an example,
"http://example.org/rosé" (in HTML),
"http://example.org/rosé" (in HTML or XML), and
<vspace/>"http://example.org/rosé" (in HTML or XML) are all
resolved into what is denoted in this document (see 'Notation' section of <xref
target="RFC3987bis" />) as "http://example.org/rosé"
(the "é" here standing for the actual e-acute character, to
compensate for the fact that this document cannot contain non-ASCII
characters).</t>
<t>Similar considerations apply to encodings such as Transfer Codings
in HTTP (see <xref target="RFC2616"></xref>) and Content Transfer
Encodings in MIME (<xref target="RFC2045"></xref>), although in these
cases, the encoding is based not on characters but on octets, and
additional care is required to make sure that characters, and not just
arbitrary octets, are compared (see <xref
target="stringcomp"></xref>).</t>
</section> <!-- preparation -->
<section title="Comparison Ladder" anchor="ladder">
<t>In practice, a variety of methods are used to test IRI
equivalence. These methods fall into a range distinguished by the
amount of processing required and the degree to which the probability
of false negatives is reduced. As noted above, false negatives cannot
be eliminated. In practice, their probability can be reduced, but this
reduction requires more processing and is not cost-effective for all
applications.</t>
<t>If this range of comparison practices is considered as a ladder,
the following discussion will climb the ladder, starting with
practices that are cheap but have a relatively higher chance of
producing false negatives, and proceeding to those that have higher
computational cost and lower risk of false negatives.</t>
<section title="Simple String Comparison" anchor="stringcomp">
<t>If two IRIs, when considered as character strings, are identical,
then it is safe to conclude that they are equivalent. This type of
equivalence test has very low computational cost and is in wide use in
a variety of applications, particularly in the domain of parsing. It
is also used when a definitive answer to the question of IRI
equivalence is needed that is independent of the scheme used and that
can be calculated quickly and without accessing a network. An example
of such a case is XML Namespaces (<xref
target="XMLNamespace"></xref>).</t>
<t>Testing strings for equivalence requires some basic precautions.
This procedure is often referred to as "bit-for-bit" or
"byte-for-byte" comparison, which is potentially misleading. Testing
strings for equality is normally based on pair comparison of the
characters that make up the strings, starting from the first and
proceeding until both strings are exhausted and all characters are
found to be equal, until a pair of characters compares unequal, or
until one of the strings is exhausted before the other.</t>
<t>This character comparison requires that each pair of characters be
put in comparable encoding form. For example, should one IRI be stored
in a byte array in UTF-8 encoding form and the second in a UTF-16
encoding form, bit-for-bit comparisons applied naively will produce
errors. It is better to speak of equality on a character-for-character
rather than on a byte-for-byte or bit-for-bit basis. In practical
terms, character-by-character comparisons should be done codepoint by
codepoint after conversion to a common character encoding form.
When comparing character by character, the comparison function MUST
NOT map IRIs to URIs, because such a mapping would create additional
spurious equivalences. It follows that an IRI SHOULD NOT be modified
when being transported if there is any chance that this IRI might be
used in a context that uses Simple String Comparison.</t>
<t>False negatives are caused by the production and use of IRI
aliases. Unnecessary aliases can be reduced, regardless of the
comparison method, by consistently providing IRI references in an
already normalized form (i.e., a form identical to what would be
produced after normalization is applied, as described below).
Protocols and data formats often limit some IRI comparisons to simple
string comparison, based on the theory that people and implementations
will, in their own best interest, be consistent in providing IRI
references, or at least be consistent enough to negate any efficiency
that might be obtained from further normalization.</t>
</section> <!-- stringcomp -->
<section title="Syntax-Based Normalization">
<figure><preamble>Implementations may use logic based on the
definitions provided by this specification to reduce the probability
of false negatives. This processing is moderately higher in cost than
character-for-character string comparison. For example, an application
using this approach could reasonably consider the following two IRIs
equivalent:</preamble>
<artwork>
example://a/b/c/%7Bfoo%7D/rosé
eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9
</artwork></figure>
<t>Web user agents, such as browsers, typically apply this type of IRI
normalization when determining whether a cached response is
available. Syntax-based normalization includes such techniques as case
normalization, character normalization, percent-encoding
normalization, and removal of dot-segments.</t>
<section title="Case Normalization">
<t>For all IRIs, the hexadecimal digits within a percent-encoding
triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
should be normalized to use uppercase letters for the digits A-F.</t>
<t>When an IRI uses components of the generic syntax, the component
syntax equivalence rules always apply; namely, that the scheme and
US-ASCII only host are case insensitive and therefore should be
normalized to lowercase. For example, the URI
"HTTP://www.EXAMPLE.com/" is equivalent to
"http://www.example.com/". Case equivalence for non-ASCII characters
in IRI components that are IDNs are discussed in <xref
target="schemecomp"></xref>. The other generic syntax components are
assumed to be case sensitive unless specifically defined otherwise by
the scheme.</t>
<t>Creating schemes that allow case-insensitive syntax components
containing non-ASCII characters should be avoided. Case normalization
of non-ASCII characters can be culturally dependent and is always a
complex operation. The only exception concerns non-ASCII host names
for which the character normalization includes a mapping step derived
from case folding.</t>
</section> <!-- casenorm -->
<section title="Character Normalization" anchor="normalization">
<t>The Unicode Standard <xref target="UNIV6"></xref> defines various
equivalences between sequences of characters for various
purposes. Unicode Standard Annex #15 <xref target="UTR15"></xref>
defines various Normalization Forms for these equivalences, in
particular Normalization Form C (NFC, Canonical Decomposition,
followed by Canonical Composition) and Normalization Form KC (NFKC,
Compatibility Decomposition, followed by Canonical Composition).</t>
<t> IRIs already in Unicode MUST NOT be normalized before parsing or
interpreting. In many non-Unicode character encodings, some text
cannot be represented directly. For example, the word "Vietnam" is
natively written "Việt Nam" (containing a LATIN SMALL
LETTER E WITH CIRCUMFLEX AND DOT BELOW) in NFC, but a direct
transcoding from the windows-1258 character encoding leads to
"Việt Nam" (containing a LATIN SMALL LETTER E WITH
CIRCUMFLEX followed by a COMBINING DOT BELOW). Direct transcoding of
other 8-bit encodings of Vietnamese may lead to other
representations.</t>
<t>Equivalence of IRIs MUST rely on the assumption that IRIs are
appropriately pre-character-normalized rather than apply character
normalization when comparing two IRIs. The exceptions are conversion
from a non-digital form, and conversion from a non-UCS-based character
encoding to a UCS-based character encoding. In these cases, NFC or a
normalizing transcoder using NFC MUST be used for interoperability. To
avoid false negatives and problems with transcoding, IRIs SHOULD be
created by using NFC. Using NFKC may avoid even more problems; for
example, by choosing half-width Latin letters instead of full-width
ones, and full-width instead of half-width Katakana.</t>
<t>As an example,
"http://www.example.org/résumé.html" (in XML
Notation) is in NFC. On the other hand,
"http://www.example.org/résumé.html" is not in
NFC.</t>
<t>The former uses precombined e-acute characters, and the latter uses
"e" characters followed by combining acute accents. Both usages are
defined as canonically equivalent in <xref target="UNIV6"></xref>.</t>
<t><list style="hanging">
<t hangText="Note:">
Because it is unknown how a particular sequence of characters is being
treated with respect to character normalization, it would be
inappropriate to allow third parties to normalize an IRI
arbitrarily. This does not contradict the recommendation that when a
resource is created, its IRI should be as character normalized as
possible (i.e., NFC or even NFKC). This is similar to the
uppercase/lowercase problems. Some parts of a URI are case
insensitive (for example, the domain name). For others, it is unclear
whether they are case sensitive, case insensitive, or something in
between (e.g., case sensitive, but with a multiple choice selection if
the wrong case is used, instead of a direct negative result). The
best recipe is that the creator use a reasonable capitalization and,
when transferring the URI, capitalization never be
changed.</t></list></t>
<t>Various IRI schemes may allow the usage of Internationalized Domain
Names (IDN) <xref target="RFC5890"/> either in the ireg-name
part or elsewhere. Character Normalization also applies to IDNs, as
discussed in <xref target="schemecomp"/>.</t>
</section> <!-- charnorm -->
<section title="Percent-Encoding Normalization">
<t>The percent-encoding mechanism (Section 2.1 of <xref
target="RFC3986"></xref>) is a frequent source of variance among
otherwise identical IRIs. In addition to the case normalization issue
noted above, some IRI producers percent-encode octets that do not
require percent-encoding, resulting in IRIs that are equivalent to
their nonencoded counterparts. These IRIs should be normalized by
decoding any percent-encoded octet sequence that corresponds to an
unreserved character, as described in section 2.3 of <xref
target="RFC3986"></xref>.</t>
<t>For actual resolution, differences in percent-encoding (except for
the percent-encoding of reserved characters) MUST always result in the
same resource. For example, "http://example.org/~user",
"http://example.org/%7euser", and "http://example.org/%7Euser", must
resolve to the same resource.</t>
<t>If this kind of equivalence is to be tested, the percent-encoding
of both IRIs to be compared has to be aligned; for example, by
converting both IRIs to URIs (see Section 3.1), eliminating escape
differences in the resulting URIs, and making sure that the case of
the hexadecimal characters in the percent-encoding is always the same
(preferably upper case). If the IRI is to be passed to another
application or used further in some other way, its original form MUST
be preserved. The conversion described here should be performed only
for local comparison.</t>
</section> <!-- pctnorm -->
<section title="Path Segment Normalization">
<t>The complete path segments "." and ".." are intended only for use
within relative references (Section 4.1 of <xref
target="RFC3986"></xref>) and are removed as part of the reference
resolution process (Section 5.2 of <xref target="RFC3986"></xref>).
However, some implementations may incorrectly assume that reference
resolution is not necessary when the reference is already an IRI, and
thus fail to remove dot-segments when they occur in non-relative
paths. IRI normalizers should remove dot-segments by applying the
remove_dot_segments algorithm to the path, as described in Section
5.2.4 of <xref target="RFC3986"></xref>.</t>
</section> <!-- pathnorm -->
</section> <!-- ladder -->
<section title="Scheme-Based Normalization" anchor="schemecomp">
<t>The syntax and semantics of IRIs vary from scheme to scheme, as
described by the defining specification for each
scheme. Implementations may use scheme-specific rules, at further
processing cost, to reduce the probability of false negatives. For
example, because the "http" scheme makes use of an authority
component, has a default port of "80", and defines an empty path to be
equivalent to "/", the following four IRIs are equivalent:</t>
<figure><artwork>
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/</artwork></figure>
<t>In general, an IRI that uses the generic syntax for authority with
an empty path should be normalized to a path of "/". Likewise, an
explicit ":port", for which the port is empty or the default for the
scheme, is equivalent to one where the port and its ":" delimiter are
elided and thus should be removed by scheme-based normalization. For
example, the second IRI above is the normal form for the "http"
scheme.</t>
<t>Another case where normalization varies by scheme is in the
handling of an empty authority component or empty host
subcomponent. For many scheme specifications, an empty authority or
host is considered an error; for others, it is considered equivalent
to "localhost" or the end-user's host. When a scheme defines a default
for authority and an IRI reference to that default is desired, the
reference should be normalized to an empty authority for the sake of
uniformity, brevity, and internationalization. If, however, either the
userinfo or port subcomponents are non-empty, then the host should be
given explicitly even if it matches the default.</t>
<t>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.</t>
<t>Some IRI schemes allow the usage of Internationalized Domain
Names (IDN) <xref target='RFC5890'></xref> either in their ireg-name
part or elswhere. When in use in IRIs, those names SHOULD
conform to the definition of U-Label in <xref
target='RFC5890'></xref>. An IRI containing an invalid IDN cannot
successfully be resolved. For legibility purposes, they
SHOULD NOT be converted into ASCII Compatible Encoding (ACE).</t>
<t>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".</t><t>Other scheme-specific
normalizations are possible.</t>
</section> <!-- schemenorm -->
<section title="Protocol-Based Normalization">
<t>Substantial effort to reduce the incidence of false negatives is
often cost-effective for web spiders. Consequently, they implement
even more aggressive techniques in IRI comparison. For example, if
they observe that an IRI such as</t>
<figure><artwork>
http://example.com/data</artwork></figure>
<t>redirects to an IRI differing only in the trailing slash</t>
<figure><artwork>
http://example.com/data/</artwork></figure>
<t>they will likely regard the two as equivalent in the future. This
kind of technique is only appropriate when equivalence is clearly
indicated by both the result of accessing the resources and the common
conventions of their scheme's dereference algorithm (in this case, use
of redirection by HTTP origin servers to avoid problems with relative
references).</t>
</section> <!-- protonorm -->
</section> <!-- equivalence -->
<section title="Security Considerations" anchor="security">
<t>The primary security difficulty comes from applications choosing the
wrong equivalence relationship, or two different parties disagreeing
on equivalence. This is especially a problem when IRIs are used in
security protocols.</t>
<t>Besides the large character repertoire of Unicode, reasons for
confusion include different forms of normalization and different normalization
expectations, use of percent-encoding with various legacy encodings,
and bidirectionality issues. See also <xref target='UTR36'/>.</t>
</section><!-- security -->
<section title="Acknowledgements">
<t>This document was originally derived from <xref target="RFC3986"/>
and <xref target="RFC3987"/>, based on text contributed by Tim
Bray.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC3987bis"
target="http://tools.ietf.org/id/draft-ietf-iri-3987bis">
<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author initials="M." surname="Duerst"/>
<author initials="L." surname="Masinter" fullname="Larry Masinter"/>
<author initials="M." surname="Suignard"/>
<date year="2011"/>
</front>
</reference>
&rfc2119;
&rfc3490;
&rfc3491;
&rfc3629;
&rfc3986;
&rfc5890;
<reference anchor="UNIV6">
<front>
<title>The Unicode Standard, Version 6.0.0 (Mountain View, CA, The Unicode Consortium, 2011, ISBN 978-1-936213-01-6)</title>
<author><organization>The Unicode Consortium</organization></author>
<date year="2010" month="October"/>
</front>
</reference>
<reference anchor="UTR15" target="http://www.unicode.org/unicode/reports/tr15/tr15-23.html">
<front>
<title>Unicode Normalization Forms</title>
<author initials="M." surname="Davis" fullname="Mark Davis"><organization/></author>
<author initials="M.J." surname="Duerst" fullname="Martin Duerst"><organization/></author>
<date year="2008" month="March"/>
</front>
<seriesInfo name="Unicode Standard Annex" value="#15"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="HTML4" target="http://www.w3.org/TR/html401/appendix/notes.html#h-B.2">
<front>
<title>HTML 4.01 Specification</title>
<author initials="D." surname="Raggett" fullname="Dave Raggett"><organization/></author>
<author initials="A." surname="Le Hors" fullname="Arnaud Le Hors"><organization/></author>
<author initials="I." surname="Jacobs" fullname="Ian Jacobs"><organization/></author>
<date year="1999" month="December" day="24"/>
</front>
<seriesInfo name="World Wide Web Consortium" value="Recommendation"/>
</reference>
&rfc2045;
&rfc3987;
&rfc2616;
<reference anchor="UTR36" target="http://unicode.org/reports/tr36/">
<front>
<title>Unicode Security Considerations</title>
<author initials="M." surname="Davis" fullname="Mark Davis"><organization/></author>
<author initials="M." surname="Suignard" fullname="Michel Suignard"><organization/></author>
<date year="2010" month="August" day="4"/>
</front>
<seriesInfo name="Unicode Technical Report" value="#36"/>
</reference>
<reference anchor="XML1" target="http://www.w3.org/TR/REC-xml">
<front>
<title>Extensible Markup Language (XML) 1.0 (Forth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"><organization/></author>
<author initials="J." surname="Paoli" fullname="Jean Paoli"><organization/></author>
<author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
<organization/></author>
<author initials="E." surname="Maler" fullname="Eve Maler"><organization/></author>
<author initials="F." surname="Yergeau" fullname="Francois Yergeau"><organization/></author>
<date day="16" month="August" year="2006"/>
</front>
<seriesInfo name="World Wide Web Consortium" value="Recommendation"/>
</reference>
<reference anchor="XMLNamespace" target="http://www.w3.org/TR/REC-xml-names">
<front>
<title>Namespaces in XML (Second Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"><organization/></author>
<author initials="D." surname="Hollander" fullname="Dave Hollander"><organization/></author>
<author initials="A." surname="Layman" fullname="Andrew Layman"><organization/></author>
<author initials="R." surname="Tobin" fullname="Richard Tobin"><organization></organization></author>
<date day="16" month="August" year="2006"/>
</front>
<seriesInfo name="World Wide Web Consortium" value="Recommendation"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:49:53 |