Xri Syntax V2.0 CD 01

1
Extensible Resource Identifier (XRI)

Syntax V2.0
Committee Draft 01, 14 March 2005
5
6
Document identifier:
xri-syntax-V2.0-cd-01
7
8
Location:
http://docs.oasis-open.org/xri/xri/V2.0
9
10
11
Editors:
Drummond Reed, Cordance <[email protected]>
Dave McAlpin, Epok <[email protected]>
12
13
14
15
16
Contributors:
Peter Davis, Neustar <[email protected]>
Nat Sakimura, NRI <[email protected]>
Mike Lindelsee, Visa International <[email protected]>
Gabe Wachob, Visa International <[email protected]>
17
18
19
20
21
22
23
Abstract:
This document is the normative technical specification for XRI generic syntax. For a nonnormative introduction to the uses and features of XRIs, see Introduction to XRIs at
[XRIIntro]. For the HTTP-based XRI resolution protocol, see Extensible Resource
Identifier (XRI) Resolution V2.0 at [XRIResolution]. For the set of XRIs defined to
provide metadata about other XRIs, see Extensible Resource Identifier (XRI) Metadata
V2.0 at [XRIMetadata].
24
25
26
27
28
Status:
This document was last revised or approved by the XRI Technical Committee on the
above date. The level of approval is also listed above. Check the current location noted
above for possible later revisions of this document. This document is updated periodically
on no particular schedule.
29
30
31
32
Technical Committee members should send comments on this specification to the

Technical Committee's email list. Others should send comments to the Technical
Committee by using the "Send A Comment" button on the Technical Committee's web
page at http://www.oasis-open.org/committees/xri.
33
34
35
36
For information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing terms, please refer to
the Intellectual Property Rights section of the Technical Committee web page
(http://www.oasis-open.org/committees/xri/ipr.php.
37
38
The non-normative errata page for this specification is located at http://www.oasisopen.org/committees/xri.
Copyright OASIS Open 2005. All Rights Reserved.
14 March 2005
Page 1 of 34
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
Table of Contents
Introduction ...................................................................................................................................... 4
1.1 Overview of XRIs................................................................................................................... 4
1.1.1 Generic Syntax .............................................................................................................. 4
1.1.2 URI, URL, URN, and XRI............................................................................................... 5
1.2 Terminology and Notation ..................................................................................................... 6
1.2.1 Keywords ....................................................................................................................... 6
1.2.2 Syntax Notation.............................................................................................................. 6
2
Syntax ..................................................................................................................................... 7
2.1 Characters............................................................................................................................. 7
2.1.1 Character Encoding ....................................................................................................... 7
2.1.2 Reserved Characters ..................................................................................................... 7
2.1.3 Unreserved Characters.................................................................................................. 7
2.1.4 Percent-Encoded Characters ........................................................................................ 8
2.1.4.1 Encoding XRI Metadata........................................................................................................ 8
2.1.5 Excluded Characters...................................................................................................... 8

2.2 Syntax Components.............................................................................................................. 9
2.2.1 Authority......................................................................................................................... 9
2.2.1.1 XRI Authority........................................................................................................................10
2.2.1.2 Global Context Symbol (GCS) Authority..............................................................................10
2.2.1.3 IRI Authority .........................................................................................................................10
2.2.2 Cross-References ........................................................................................................ 11

2.2.3 Path.............................................................................................................................. 11
2.2.4 Query ........................................................................................................................... 12
2.2.5 Fragment...................................................................................................................... 12
2.3 Transformations .................................................................................................................. 13
2.3.1 Transforming XRI References into IRI and URI References ....................................... 13
2.3.2 Escaping Rules for XRI Syntax.................................................................................... 13
2.3.3 Transforming IRI References into XRI References ..................................................... 15
2.4 Relative XRI References..................................................................................................... 15
2.4.1 Reference Resolution .................................................................................................. 15
2.4.2 Reference Resolution Examples ................................................................................. 16
2.4.2.1 Normal Examples ................................................................................................................16
2.4.2.2 Abnormal Examples.............................................................................................................16
2.4.3 Leading Segments Containing a Colon ....................................................................... 17

2.4.4 Leading Segments Beginning with a Cross-Reference ............................................... 17
2.5 Normalization and Comparison........................................................................................... 17
2.5.1 Case............................................................................................................................. 17
2.5.2 Encoding, Percent-Encoding, and Transformations .................................................... 18
2.5.3 Optional Syntax............................................................................................................ 18
2.5.4 Cross-References ........................................................................................................ 18
2.5.5 Canonicalization........................................................................................................... 18
3
Security and Data Protection Considerations ....................................................................... 20
14 March 2005
Page 2 of 34
82
83
84
85
86
87
88
89
90
91
92
93
94
95
3.1 Cross-References ............................................................................................................... 20

3.2 XRI Metadata ...................................................................................................................... 20
3.3 Spoofing and Homographic Attacks.................................................................................... 20
3.4 UTF-8 Attacks ..................................................................................................................... 20
3.5 XRI Usage in Evolving Infrastructure .................................................................................. 21
4
References............................................................................................................................ 22
4.1 Normative ............................................................................................................................ 22
4.2 Informative........................................................................................................................... 23
Appendix A. Collected ABNF for XRI (Normative) ........................................................................ 24
Appendix B. Transforming HTTP IRIs to XRIs (Non-Normative) .................................................. 27
Appendix C. Glossary.................................................................................................................... 28
Appendix D. Acknowledgments..................................................................................................... 33
Appendix E. Notices ...................................................................................................................... 34
14 March 2005
Page 3 of 34
96
Introduction
97
1.1 Overview of XRIs
98
99
100
Extensible Resource Identifiers (XRIs) provide a standard means of abstractly identifying a

resource independent of any particular concrete representation of that resourceor, in the case
of a completely abstract resource, of any representation at all.
101
102
103
As shown in Figure 1, XRIs build on the foundation established by URIs (Uniform Resource
Identifiers) and IRIs (Internationalized Resource Identifiers) as defined by [URI] and [IRI],
respectively.
Abstract
XRI
Internationalized
IRI
Uniform
URI
Extends syntax
Extends character set
Base specification
104
105
Figure 1: The relationship of XRIs, IRIs, and URIs
106
107
108
109
110
111
The IRI specification created a new identifier by extending the unreserved character set to include
characters beyond those allowed in generic URIs. It also defined rules for transforming this
identifier into a syntactically legal URI. Similarly, this specification creates a new identifier, an
XRI, that extends the syntactic elements (but not the character set) allowed in IRIs. To
accommodate applications that expect IRIs or URIs, this specification also defines rules for
transforming an XRI reference into a valid IRI or URI reference.
112
113
114
Although an XRI is not a Uniform Resource Name (URN) as defined in URN Syntax [RFC2141],
an XRI consisting entirely of persistent segments is designed to meet the requirements set out in
Functional Requirements for Uniform Resource Names [RFC1737].
115
116
This document specifies the normative syntax for XRIs, along with associated normalization,
processing and equivalence rules. Two additional specifications complete the XRI 2.0 suite:
117
118
119
XRI Resolution [XRIResolution] specifies both a standard and a trusted HTTP-based

resolution protocol for XRIs. Use of these protocols is not required; XRIs may also be
resolved using other protocols or resolution mechanisms.
120
121
122
XRI Metadata [XRIMetadata] specifies a small set of standard metadata identifiers registered
under the XRI global context symbol "$" that may be used to describe the contents of an XRI
reference.
123
124
See also An Introduction to XRIs [XRIIntro] for a non-normative introduction to XRI 2.0 syntax,
resolution, and metadata via a set of practical examples.
125
1.1.1 Generic Syntax
126
127
XRI syntax follows the same basic pattern as IRI and URI syntax. A fully-qualified XRI consists of
the prefix xri:// followed by the same four components as a generic authority-based IRI or URI.
128
xri://
authority
/ path
? query
# fragment
14 March 2005
Page 4 of 34
129
130
131
132
133
The definitions of these components are, for the most part, supersets of the equivalent
components in the generic IRI or URI syntax. One advantage of this approach is that the vast
majority of HTTP URIs and IRIs, which derive directly from generic URI syntax, can be
transformed to valid XRIs simply by changing the scheme from http to xri. This transformation
is discussed in Appendix B, Transforming HTTP IRIs to XRIs.
134
XRI syntax extends generic IRI syntax in the following four ways:
135
136
137
1. Persistent and reassignable segments. Unlike generic URI syntax, XRI syntax allows the
internal components of an XRI reference to be explicitly designated as either persistent or
reassignable.
138
139
140
141
142
143
144
145
2. Cross-references. Cross-references allow XRI references to contain other XRI references

or IRIs as syntactically-delimited sub-segments. This provides syntactic support for
compound identifiers, i.e., the use of well-known, fully-qualified identifiers within the
context of another XRI reference. Typical uses of cross-references include using wellknown types of metadata in an XRI reference (such as versioning metadata as defined in
the XRI Metadata specification [XRIMetadata]), or the use of globally-defined identifiers
to mark parts of an XRI reference as having application- or vocabulary-specific
semantics.
146
147
148
3. Global context symbols. While XRI syntax supports the same generic syntax used in IRIs
for DNS and IP authorities, it also provides shorthand symbols for establishing the
abstract global context of an identifier.
149
150
151
152
153
4. Standardized federation. Federated identifiers are those delegated across multiple

authorities, such as DNS names. Generic URI syntax leaves the syntax for federated
identifiers up to individual URI schemes, with the exception of explicit support for IP
addresses. XRI syntax standardizes federation of both persistent and reassignable
identifiers at any level of the path.
154
1.1.2 URI, URL, URN, and XRI
155
156
157
158
The evolution and interrelationships of the terms URI, URL, and URN are explained in a
report from the Joint W3C/IETF URI Planning Interest Group, Uniform Resource Identifiers
(URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations
[RFC3305]. According to section 2.1:
159
160
161
162
163
164
165
166
167
168
During the early years of discussion of web identifiers (early to mid 90s), people assumed
that an identifier type would be cast into one of two (or possibly more) classes. An identifier
might specify the location of a resource (a URL) or its name (a URN), independent of
location. Thus a URI was either a URL or a URN.
This view has since changed, as the report goes on to state in section 2.2:
Over time, the importance of this additional level of hierarchy seemed to lessen; the view
became that an individual scheme did not need to be cast into one of a discrete set of URI
types, such as URL, URN, URC, etc. Web-identifier schemes are, in general, URI
schemes, as a given URI scheme may define subspaces.
This conclusion is shared by [URI] which states in section 1.1.3:
169
170
171
172
An individual [URI] scheme does not have to be classified as being just one of name or
locator. Instances of URIs from any given scheme may have the characteristics of names or
locators or both, often depending on the persistence and care in the assignment of identifiers
by the naming authority, rather than on any quality of the scheme.
173
174
175
XRIs are consistent with this philosophy. Although XRIs are designed to fulfill the requirements of
abstract names that are resolved into concrete locators, the XRI syntax does not distinguish
between identifiers that represent names, locators or characteristics.
14 March 2005
Page 5 of 34
176
1.2 Terminology and Notation
177
1.2.1 Keywords
178
179
180
181
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY and OPTIONAL in this document are to be
interpreted as described in [RFC2119]. When these words are not capitalized in this document,
they are meant in their natural language sense.
182
1.2.2 Syntax Notation
183
184
185
186
187
188
189
This specification uses the syntax notation employed in [IRI]: Augmented Backus-Naur Form
(ABNF), defined in [RFC2234]. Although the ABNF defines syntax in terms of the US-ASCII
character encoding, XRI syntax should be interpreted in terms of the character that the ASCIIencoded octet represents, rather than the octet encoding itself, as explained in [URI]. As with
URIs, the precise bit-and-byte representation of an XRI reference on the wire or in a document is
dependent upon the character encoding of the protocol used to transport it, or the character set of
the document that contains it.
190
191
192
The following core ABNF productions are used by this specification as defined by section 6.1 of
[RFC2234]: ALPHA, CR, CTL, DIGIT, DQUOTE, HEXDIG, LF, OCTET and SP. The complete
XRI ABNF syntax is collected in Appendix A.
193
194
195
To simplify comparison between generic XRI syntax and generic IRI syntax, the ABNF
productions that are unique to XRIs are shown with light green shading, while those inherited
from [IRI] are shown with light yellow shading.
196
This is an example of ABNF specific to XRI.
197
This is an example of ABNF inherited from IRI.
198
199
Lastly, because the prefix xri:// is optional in absolute XRIs that use a global context symbol
(see section 2.2.1.2), some example XRIs are shown without this prefix.
14 March 2005
Page 6 of 34
200
2 Syntax
201
202
203
204
This section defines the normative syntax for XRIs. Note that additional constraints are inherited
from [IRI] and [URI], as defined in section 2.2. Also note that some productions in the XRI ABNF
are ambiguous. As with IRIs and URIs, a first-match-wins rule is used to disambiguate
ambiguous productions. See [URI] for more details.
205
2.1 Characters
206
207
XRI character set and encoding are inherited from [IRI], which is a superset of generic URI
syntax as defined in [URI].
208
2.1.1 Character Encoding
209
210
211
212
213
The standard character encoding of XRI is UTF-8, as recommended by [RFC2718]. When an XRI
reference is presented as a human-readable identifier, the representation of the XRI reference in
the underlying document may use the character encoding of the underlying document. However,
this representation must be converted to UTF-8 before the XRI can be processed outside the
document.
214
2.1.2 Reserved Characters
215
216
217
218
219
220
221
The overall XRI reserved character set is the same as the reserved character set defined by
[URI] and [IRI]. Due to the extended syntax of XRIs, however, the allocation of reserved
characters between the general delimiters and sub-delimiters productions is different. Those
characters that have defined semantics in generic XRI syntax appear in the xri-gen-delims
production. Those characters that do not have defined semantics but that are reserved for use as
implementation-specific delimiters appear in the xri-sub-delims production. The rgcs-char
production that appears in xri-gen-delims below is discussed in section 2.2.1.2.
222
xri-reserved
= xri-gen-delims / xri-sub-delims
223
224
xri-gen-delims
= ":" / "/" / "?" / "#" / "[" / "]" / "(" / ")"

/ "*" / "!" / rgcs-char
225
xri-sub-delims
= "&" / ";" / "," / ""
226
227
228
If an XRI reserved character is used as a data character and not as a delimiter, the character
MUST be percent-encoded per the rules in section 2.1.4, Percent-Encoded Characters. XRI
references that differ in the percent-encoding of a reserved character are not equivalent.
229
2.1.3 Unreserved Characters
230
231
The characters allowed in XRI references that are not reserved are called unreserved. XRI has
the same set of unreserved characters as the "iunreserved" production in [IRI].
232
iunreserved
= ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
233
234
235
236
237
238
ucschar
=
/
/
/
/
/
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF

%x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
%xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
%xD0000-DFFFD / %xE1000-EFFFD
14 March 2005
Page 7 of 34
239
240
241
Percent-encoding unreserved characters in an XRI does not change what resource is identified
by that XRI. However, it may change the result of an XRI comparison (see section 2.5,
Normalization and Comparison), so unreserved characters SHOULD NOT be percent-encoded.
242
2.1.4 Percent-Encoded Characters
243
244
245
246
247
XRIs follow the same rules for percent-encoding as IRIs and URIs. That is, any data character in
an XRI reference MUST be percent-encoded if it does not have a representation using an
unreserved character but SHOULD NOT be percent-encoded if it does have a representation
using an unreserved character. Delimiters in an XRI reference that have a representation using a
reserved character MUST NOT be percent-encoded.
248
249
250
251
252
253
An XRI reference thus percent-encoded is said to be in XRI-normal form. Not all XRI references
in XRI-normal form are syntactically legal IRI or URI references. Rules for converting an XRI
reference to a valid IRI or URI reference are discussed in section 2.3.1. An XRI reference is in
XRI-normal form if it is minimally percent-encoded and matches the ABNF provided in this
document, but it is a valid IRI or URI reference only after it is percent-encoded according to the
transformation described in section 2.3.1.
254
255
A percent-encoded octet is a character triplet consisting of the percent character % followed by

the two hexadecimal digits representing that octet's numeric value.
256
escaped
= "%" HEXDIG HEXDIG
257
258
259
260
The uppercase hexadecimal digits A through F are equivalent to the lowercase digits a
through f, respectively. XRI references that differ only in the case of hexadecimal digits used in
percent-encoded octets are equivalent. For consistency, XRI generators and normalizers
SHOULD use uppercase hexadecimal digits for percent-encoded triplets.
261
262
Note that a % symbol used to represent itself in an XRI reference (i.e., as data and not to
introduce a percent-encoded triplet) must be percent-encoded.
263
2.1.4.1 Encoding XRI Metadata
264
265
266
267
268
In some cases, the transformation of an identifier in its native language and display format into an
XRI reference in XRI-normal form may lose information that cannot be retained through percentencoding. For example, in certain languages, displaying the glyph of a UTF-8 encoded character
requires additional language and font information not available in UTF-8. The loss of this
information during UTF-8 encoding might cause the resulting XRI to be ambiguous.
269
270
271
272
273
XRI syntax offers an option for encoding this language metadata using a cross-reference
beginning with the GCS $ symbol (see section 2.2.1.2). The top level authority for $l language
metadata is the XRI Metadata Specification [XRIMetadata], specifically section 2. See also
section 3 for "$d" date/time metadata, section 4 for "$v" version metadata, and section 5 for "$-"
annotation metadata.
274
2.1.5 Excluded Characters
275
276
277
278
279
Certain characters, such as space, are excluded from the XRI syntax and must be percentencoded in order to be represented within an XRI. Systems responsible for accepting or
presenting XRI references may choose to percent-encode excluded characters on input and/or
decode them prior to display, as described in section 2.1.4. A string that contains these
characters in a non-percent-encoded form, however, is not a valid XRI.
280
281
282
283
284
285
Note that presenting space or other whitespace characters in a non-percent-encoded form is not
recommended for several reasons. First, it is often difficult to visually determine the number of
spaces or other characters composing a block of whitespace, leading to transcription errors.
Second, the space character is often used to delimit an XRI reference, so non-percent-encoded
whitespace characters can make it difficult or impossible to determine where the identifier ends.
Finally, non-percent-encoded whitespace can be used to maliciously construct subtly different
14 March 2005
Page 8 of 34
286
287
288
identifiers intended to mislead the reader. For these reasons, non-percent-encoded whitespace
characters SHOULD be avoided in presentation, and alternatives to whitespace as a logical
separator within XRIs (such as dots or hyphens) SHOULD be used whenever possible.
289
290
[IRI] provides the following guidance concerning other characters that should be avoided. This
guidance applies to XRIs as well.
291
292
293
294
295
The UCS contains many areas of characters for which there are strong visual
look-alikes. Because of the likelihood of transcription errors, these also should be
avoided. This includes the full-width equivalents of Latin characters, half-width
Katakana characters for Japanese, and many others. This also includes many
look-alikes of space, delims, and unwise, characters excluded in [RFC3491].
296
297
298
Additional information is available from [UniXML]. [UniXML] is written in the

context of running text rather than in the context of identifiers. Nevertheless, it
discusses many of the categories of characters not appropriate for IRIs.
299
2.2 Syntax Components
300
301
302
303
304
305
306
XRI syntax builds on generic IRI (and ultimately, URI) syntax. However because XRI syntax
includes syntactic elements other than those defined in [IRI] and [URI], this specification defines
a new protocol element, "XRI", along with rules for transforming XRI references into generic IRI or
URI references for applications that expect them (see section 2.3.1, Transforming XRI
References into IRI and URI References). An XRI reference MUST be constructed such that it
qualifies as a valid IRI as defined by [IRI] when converted to IRI-normal form and such that it
qualifies as a valid URI as defined by [URI] when converted to URI-normal form.
307
308
As with URIs, an XRI must be in absolute form, while an XRI reference may be either an XRI or a
relative XRI reference.
309
XRI-reference
= XRI / relative-XRI-ref
310
311
XRI
= [ "xri://" ] xri-hier-part [ "?" iquery ]

[ "#" ifragment ]
312
absolute-XRI
313
xri-value
= xri-no-scheme / relative-XRI-ref
314
315
xri-no-scheme
= xri-hier-part [ "?" iquery ]

[ "#" ifragment ]
316
relative-XRI-ref
= xri-path [ "?" iquery ] [ "#" ifragment ]
317
318
xri-hier-part
= ( xri-authority / iauthority )
[ xri-path-absolute ] / ipath-empty
319
320
321
322
323
An XRI begins with an optional prefix xri:// followed by the same set of hierarchical components
as a URI authority, path, query, and fragment. An XRI is always in absolute form. A relative XRI
reference consists of an XRI path followed by an optional XRI query and optional XRI fragment.
The absolute-XRI production is provided for contexts that require an XRI in absolute form but that
do not allow the fragment identifier.
324
325
Finally, in certain contexts where XRIs are used exclusively, the prefix xri:// is redundant. These
contexts can use the xri-value production, which includes all levels of XRI paths.
326
2.2.1 Authority
327
328
XRIs support the same types of authorities as generic IRIs, called IRI authorities. XRIs also
support an additional type of abstract identification authority called an XRI authority.
14 March 2005
Page 9 of 34
329
2.2.1.1 XRI Authority
330
331
There are two ways to express an XRI authority: using a global context symbol (GCS), or using a
cross-reference (abbreviated in the ABNF as xref). Cross-references are covered in section 2.2.2.
332
xri-authority
= gcs-authority / xref-authority
333
2.2.1.2 Global Context Symbol (GCS) Authority
334
335
XRIs offer a simple, compact syntax for indicating the logical global context of an identifier: a
single prefix character called a global context symbol.
336
gcs-authority
= pgcs-authority / rgcs-authority
337
pgcs-authority
= "!" xri-subseg-pt-nz *xri-subseg
338
rgcs-authority
= rgcs-char xri-segment
339
rgcs-char
= "=" / "@" / "+" / "$"
340
341
342
343
344
345
The global context symbol characters were selected from the set of symbol characters that are
valid in a URI under [URI]. The bang character, !, which is used uniformly in XRI syntax to
indicate a persistent identifier segment, serves as the GCS character for global persistent
identifiers. The other GCS characters may be used to indicate the global context of either a
persistent or a reassignable identifier as shown in Table 1 below:
Establishes Global Context For
Symbol
Character
Authority
Type
Person
Identifiers for whom the authority is an individual person.
Organization
Identifiers for whom the authority is an organization or a

resource in an organizational context.
General
public
Identifiers for whom the authority is the general public, i.e.,

that represent generic dictionary concepts for which
there is no specific authority. (In the English language, for
example, these would be the generic nouns.)
Standards
body
Identifiers for whom the authority is a specification from a

standards body, for example, other XRI specifications
(such as XRI Resolution [XRIResolution] and XRI
Metadata [XRIMetadata]), other OASIS specifications, or
(using cross-references) other standards bodies.
346
Table 1: XRI global context symbols.
347
2.2.1.3 IRI Authority
348
XRIs support the same type of authority defined by the iauthority production of [IRI].
349
iauthority
= [ iuserinfo "@" ] ihost [ ":" port ]
350
iuserinfo
= *( iunreserved / pct-encoded / sub-delims / ":" )
351
ihost
= IP-literal / IPv4address / ireg-name
352
port
= *DIGIT
14 March 2005
Page 10 of 34
353
354
355
356
The syntax is inherited directly from [IRI]. First, the iuserinfo sub-component permits the
identification of a user in the context of a host. Next, the ihost sub-component has three options
for identifying the host: a registered name (such as a domain name), an IPv4 address, or an IPv6
literal.
357
358
359
360
A host identifier can be followed by an optional port number. The XRI syntax specification does
not define a default port because it is expected this will be inherited from the resolution protocol,
such as the HTTP/HTTPS protocol specified in [XRIResolution]. Therefore, if the port is omitted
in an XRI, it is undefined.
361
362
363
364
365
Note that authority segments that begin with GCS characters or cross-references (see below)
may match both the iauthority and the xri-authority productions. For instance, !!1,
@example, =example, +example, $example and (=example) all match both productions.
As with all XRI syntax, the first-match-wins rule is used to resolve ambiguities. Consequently, all
the examples listed above would be considered XRI authorities, not IRI authorities.
366
2.2.2 Cross-References
367
368
369
370
Cross-references are the primary extensibility mechanism in XRI. They allow an identifier
assigned in one context to be reused in another context, permitting identifiers to be shared across
contexts. This simplifies identifying logically equivalent resources across hierarchies (a directory
concept referred to as polyarchy).
371
372
373
A cross-reference is syntactically delimited by enclosing it in parentheses, similar to the way an

IPv6 literal is encapsulated in square brackets as specified in [RFC2732]. A cross-reference may
contain either an XRI reference or an absolute IRI.
374
xref
= "(" ( XRI-reference / IRI ) ")"
375
376
377
It is important that the value of a cross-reference be syntactically unambiguous, whether it is an

absolute IRI or one of the various forms of an XRI reference. Therefore special attention must be
paid to relative XRI references to avoid ambiguity, as discussed in section 2.4.3.
378
379
A cross-reference may appear at any node of any XRI except within an IRI authority segment. A
cross-reference as the very first sub-segment in an XRI is a valid top-level XRI authority.
380
381
382
383
384
xref-authority
= xref *xri-subseg
This syntax allows any globally-unique identifier in any URI scheme (e.g., an HTTP URI, mailto
URI, URN etc.) to specify a global XRI authority.
xri://(mailto:[email protected])/favorites/home
--example of using a URI as an XRI global authority
385
2.2.3 Path
386
387
388
389
390
391
As with IRIs, the XRI path component is a hierarchal sequence of path segments separated by
slash (/) characters and terminated by the first question-mark (?) or number sign (#)
character, or by the end of the XRI reference. But while an IRI path segment is considered
opaque by a generic URI processor, an XRI path segment can be parsed by an XRI processor
into two types of sub-segments: * segments (pronounced star segments) and ! segments
(pronounced bang segments).
392
393
394
xri-path
395
xri-path-absolute = "/" [ xri-segment-nz *( "/" xri-segment ) ]
= xri-path-absolute
/ xri-path-noscheme
/ ipath-empty
14 March 2005
Page 11 of 34
396
397
xri-path-noscheme = xri-subseg-od-nx *xri-subseg-nc

*( "/" xri-segment )
398
xri-segment
= xri-subseg-od *xri-subseg
399
xri-segment-nz
= xri-subseg-od-nz *xri-subseg
400
xri-subseg
= ( "*" / "!" ) (xref / *xri-pchar)
401
xri-subseg-nc
= ( "*" / "!" ) (xref / *xri-pchar-nc)
402
xri-subseg-od
= [ "*" / "!" ] (xref / *xri-pchar)
403
xri-subseg-od-nz
= [ "*" / "!" ] (xref / 1*xri-pchar)
404
xri-subseg-od-nx
= [ "*" / "!" ] 1*xri-pchar-nc
405
xri-subseg-pt-nz
= "!" (xref / 1*xri-pchar)
406
407
408
409
410
* segments are used to specify reassignable identifiersidentifiers that may be reassigned by an

identifier authority to represent a different resource at some future date. ! segments are used to
specify persistent identifiersidentifiers that are permanently assigned to a resource and will not
be reassigned at a future date. The default is a * segment, so no leading star (*) is required for
the first (or only) sub-segment.
411
412
413
414
415
416
An XRI path segment may contain the same characters as a URI path segment plus the
expanded UCS character set inherited from [IRI]. If a star (*) or bang (!) appears in a path of
an XRI reference, it will be interpreted as a sub-segment delimiter. If this interpretation is not
desired for these characters, or for any other special XRI delimiters, these characters MUST be
percent-encoded when they appear in the path segment. See section 2.1.4, Percent-Encoded
Characters.
417
xri-pchar
= iunreserved / pct-encoded / xri-sub-delims / ":"
418
xri-pchar-nc
= iunreserved / pct-encoded / xri-sub-delims
419
420
421
422
With the exception of star (*), bang (!) and cross-reference delimiters, an XRI path segment is
considered opaque by generic XRI syntax. As with IRIs, XRI extensions or generating
applications may define special meanings for other XRI reserved characters for the purpose of
delimiting extension-specific or generator-specific sub-components.
423
424
Note that XRI syntax is slightly more restrictive than URI syntax in that the first segment of an
absolute XRI path may never be empty, even in the absolute form of an XRI.
425
2.2.4 Query
426
427
The XRI query component is identical to the IRI query component as described in section 2.2 of
[IRI].
428
iquery
= *( ipchar / iprivate / "/" / "?" )
429
2.2.5 Fragment
430
XRI syntax also supports fragments as described in section 2.2 of [IRI].
431
ifragment
= *( ipchar / "/" / "?" )
14 March 2005
Page 12 of 34
432
433
434
435
Since XRI federation syntax can inherently address attributes or sub-resources to any depth,
fragments are supported primarily for compatibility with generic URI syntax. XRIs can also employ
cross-references to identify media types or other alternative representations of a resource. See
section 2.2.2
436
2.3 Transformations
437
2.3.1 Transforming XRI References into IRI and URI References
438
439
440
441
Although XRIs are intended to be used by applications that understand them natively, it may also
be desirable to use them in contexts that do not recognize an XRI reference but that allow an
Internationalized Resource Identifier reference as described in [IRI], or a fully-conformant URI
reference as defined by [URI].
442
443
444
445
This section specifies the steps for transforming an XRI reference into a valid IRI reference. At
the completion of these steps, the XRI reference is in IRI-Normal Form. An XRI reference in IRINormal Form may then be mapped into a valid URI reference by following the algorithms defined
in section 3.1 of [IRI]. After that mapping, the XRI reference is in URI-Normal Form.
446
447
448
Applications MUST transform XRI references to IRI references using the following steps (or a
process that achieves exactly the same result). Before applying these steps, the XRI reference
must be in XRI-normal form as defined in section 2.1.4.
449
450
451
1. If the XRI reference is not encoded in UTF-8, convert the XRI reference to a sequence of
characters encoded in UTF-8, normalized according to Normalization Form C (NFC) as
defined in [UTR15].
452
453
2. If the XRI reference is not relative (i.e., if it matches the XRI ABNF production) and the
optional xri:// prefix has been omitted, prepend xri:// to the XRI reference.
454
455
456
457
458
3. Optionally add XRI metadata using cross-references as defined in section 2.1.4.1. Note
that the addition of XRI metadata may change the resulting IRI or URI reference for the
purposes of comparison. The significance or insignificance of specific types of XRI
metadata is specified in Extensible Resource Identifier (XRI) Metadata V2.0
[XRIMetadata].
459
460
461
462
4. Apply the XRI escaping rules defined in section 2.3.2. Note that this step is not
idempotent (i.e., it may yield a different result if applied more than once), so it is very
important that implementers not apply this step more than once to avoid changing the
semantics of the identifier.
463
464
At the completion of step 4, the percent-encoded XRI reference may be used as an IRI reference.
An XRI reference in this form is said to be in IRI-normal form.
465
466
Applying this conversion does not change the equivalence of the identifier, with the possible
exception of the addition of XRI metadata as discussed in Step 3.
467
468
469
470
471
In general, an application SHOULD use the least-transformed version appropriate for the context
in which the identifier appears. For example, if the context allows an XRI reference directly, the
identifier SHOULD be an XRI reference in XRI-normal form as described in section 2.1.4. If the
context allows an IRI reference but not an XRI reference, the identifier SHOULD be in IRI-normal
form. Only when context allows neither XRI nor IRI references should URI-normal form be used.
472
2.3.2 Escaping Rules for XRI Syntax
473
474
This section defines rules for preventing misinterpretation of XRI syntax when an XRI reference is
evaluated by a non-XRI-aware parser.
475
476
477
The first rule deals with cross-references as explained in section 2.2.2. Since a cross-reference
contains either an IRI or an XRI reference (which itself may contain further nested IRIs or XRI
references), it may include characters that, if not escaped, would cause misinterpretation when
14 March 2005
Page 13 of 34
478
479
480
481
482
483
484
485
486
487
488
489
490
491
the XRI reference is used in a context that expects an IRI or URI reference. Consider the
following XRI:
xri://@example/(xri://@example2/abc?id=1)
The generic parsing algorithm described in [URI] would separate the above XRI into the following
components:
scheme = xri
authority = @example
path = /(xri://@example2/abc
query = id=1)
The desired separation is:

scheme = xri
authority = @example
path = /(xri://@example2/abc?id=1)
query = <undefined>
492
493
494
495
To avoid this type of misinterpretation, certain characters in a cross-reference must be percentencoded when transforming an XRI reference into IRI-normal form. In particular, the question
mark (?) character must be percent-encoded as %3F and the number sign # character must
be percent-encoded as %28.
496
Following this rule, the above example would be expressed as:
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
xri://@example/(xri://@example2%3Fid=1)
In addition, the slash / character in a cross-reference may also be misinterpreted by a non-XRIaware parser. Consider:
xri://@example.com/(@example/abc)
If this were used as a base URI as defined in section 5 of [URI], the algorithm described in
section 5.2 of [URI] would append a relative-path reference to:
xri://@example.com/(@example/
instead of the intended:

xri://@example.com/
This is because the merge algorithm in section 5.2.3 of [URI] is defined in terms of the last
(right-most) slash character. This problem is avoided by encoding slashes within cross-references
as %2F. Following this rule, the above example would be expressed as:
xri://@example.com/(@example%2Fabc)
Ambiguity is also possible if an XRI reference in XRI-normal form contains characters that have
been percent-encoded to indicate that they should not be interpreted as delimiters. For example,
consider the following XRI in XRI-normal form:
xri://@example.com/(@example/abc%2Fd/ef)
This slash character between c and d is percent-encoded to show that its not a syntactical
element of the XRI, i.e., that it should be interpreted as data and not as a delimiter. To preserve
14 March 2005
Page 14 of 34
516
517
518
519
520
521
522
523
524
525
526
527
528
this type of distinction when converting an XRI reference to an IRI reference, the percent %
character must be percent-encoded as %25. Following this rule, the above example fully
converted would be:
xri://@example.com/(@example%2Fabc%252Fd%2Fef)
To summarize, the following four special rules MUST be applied during step 4 of section 2.3.1.
Before applying these rules, the XRI reference MUST be in XRI-normal form and all IRIs in crossreferences MUST be in a percent-encoded form appropriate to their schemes.
1. Percent-encode all percent % characters as %25 across the entire XRI reference.
2. Percent-encode all number sign # characters that appear within a cross-reference as
%23.
3. Percent-encode all question mark ? characters that appear within a cross-reference as
%3F.
4. Percent-encode all slash / characters that appear within a cross-reference as %2F.
529
2.3.3 Transforming IRI References into XRI References
530
531
Transformation of an XRI reference in IRI-normal form into an XRI reference in XRI-normal form
MUST use the following steps (or a process that achieves the same result).
532
533
534
1. If the XRI reference is not encoded in UTF-8, convert the XRI reference to a sequence of
characters encoded in UTF-8, normalized according to Normalization Form C (NFC) as
defined in [UTR15].
535
2. Perform the following special conversions for XRI syntax:
536
537
538
539
540
541
542
543
544
545
546
a. Convert all percent-encoded slash (/) characters to their corresponding octets.

b. Convert all percent-encoded question mark (?) characters to their
corresponding octets.
c. Convert all percent-encoded number sign (#) characters to their corresponding
octets.
d. Convert all percent-encoded percent (%) characters to their corresponding
octets.
Note that this process is not idempotent (i.e., it may yield a different result if applied more than
once), so it is very important that implementers only apply this process to XRI references in IRInormal form. If it is applied to an XRI reference in XRI-normal form, the resulting identifier may
not be equivalent to the XRI reference before transformation.
547
2.4 Relative XRI References
548
2.4.1 Reference Resolution
549
550
551
552
For XRI references in IRI-normal form or URI-normal form, resolving a relative XRI reference into
an absolute XRI reference is straightforward. If the base XRI and the relative XRI reference are in
IRI-normal form, section 6.5 of [IRI] applies. If the base XRI and the relative XRI reference are in
URI-normal form, section 5 of [URI] applies.
553
554
555
556
557
It is important that XRI references appear in a form appropriate to their context (i.e., in URInormal form in contexts that expect URI references and in IRI-normal form in contexts that expect
IRI references), since the algorithms described in [IRI] and [URI] may produce incorrect results
when applied to XRI references in XRI-normal form, particularly when those XRI references
contain cross-references.
558
559
560
561
562
In contexts that allow a native XRI reference (i.e., an XRI reference in XRI-normal form), it may
be useful to perform relative reference resolution without first converting to IRI- or URI-normal
form. In fact, it may be difficult or impossible to convert to IRI- or URI-normal form without first
resolving the relative XRI reference to an absolute XRI. The algorithms described in section 5 of
[URI] apply to XRI references in XRI-normal form provided that the processor:
14 March 2005
Page 15 of 34
563
564
treats the characters allowed in IRI references but not in URI references the same as it
treats unreserved characters in URI references (as required by section 5 of [IRI]) and
565
566
567
treats all characters within all cross-references the same as unreserved characters in URI
references (i.e., treats cross-references as opaque with respect to relative reference
resolution).
568
2.4.2 Reference Resolution Examples
569
570
571
572
The following are examples of relative XRI reference resolution. These examples are very similar
to the examples for resolving relative references in [URI]. Starting with the following base XRI in
XRI-normal form:
xri://@a*a/!b!b/c*c/(xri://@d*d/e)?q
573
a relative reference is transformed to its target XRI as shown in the following examples.
574
2.4.2.1 Normal Examples
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
!g!g
./!g!g
!g!g/
/!g!g
//@!g!g
?y
!g!g?y
#s
!g!g#s
!g!g?y#s
;x
!g!g;x
!g!g;x?y#s
.
./
..
../
../!g!g
../..
../../
../../!g!g
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
xri://@a*a/!b!b/c*c/!g!g
xri://@a*a/!b!b/c*c/!g!g
xri://@a*a/!b!b/c*c/!g!g/
xri://@a*a/!g!g
Not a legal relative XRI reference
xri://@a*a/!b!b/c*c/(xri://@d*d/e)?y
xri://@a*a/!b!b/c*c/!g!g?y
xri://@a*a/!b!b/c*c/(xri://@d*d/e)?q#s
xri://@a*a/!b!b/c*c/!g!g#s
xri://@a*a/!b!b/c*c/!g!g?y#s
xri://@a*a/!b!b/c*c/;x
xri://@a*a/!b!b/c*c/!g!g;x
xri://@a*a/!b!b/c*c/!g!g;x?y#s
xri://@a*a/!b!b/c*c/(xri://@d*d/e)?q
xri://@a*a/!b!b/c*c/
xri://@a*a/!b!b/c*c/
xri://@a*a/!b!b/
xri://@a*a/!b!b/
xri://@a*a/!b!b/!g!g
xri://@a*a/
xri://@a*a/
xri://@a*a/!g!g
597
2.4.2.2 Abnormal Examples
598
As in IRIs and URIs, the ".." syntax cannot be used to change the authority component of an XRI.
599
600
601
602
603
604
605
606
607
608
609
610
../../../!g!g
=
../../../../!g!g =
xri://@a*a/!g!g
xri://@a*a/!g!g
As in IRIs and URIs, "." and ".." have a special meaning only when they appear as complete path
segments.
/./!g!g
/../!g!g
!g!g.
.!g!g
!g!g..
..!g!g
=
=
=
=
=
=
xri://@a*a/!g!g
xri://@a*a/!g!g
xri://@a*a/!b!b/c*c/!g!g.
xri://@a*a/!b!b/c*c/.!g!g
xri://@a*a/!b!b/c*c/!g!g..
xri://@a*a/!b!b/c*c/..!g!g
XRI parsers, like IRI and URI parsers, must be prepared for superfluous or nonsensical uses of
"." and "..".
14 March 2005
Page 16 of 34
611
612
613
614
615
616
617
618
619
./../!g!g
./!g!g/.
!g!g/./h
!g!g/../h
!g!g;x=1/./y
!g!g;x=1/../y
=
=
=
=
=
=
xri://@a*a/!b!b/!g!g
xri://@a*a/!b!b/c*c/!g!g/
xri://@a*a/!b!b/c*c/!g!g/h
xri://@a*a/!b!b/c*c/h
xri://@a*a/!b!b/c*c/!g!g;x=1/y
xri://@a*a/!b!b/c*c/y
XRI parsers, like IRI and URI parsers, must take care to separate the references query and/or
fragment components from the path component before merging it with the base path and
removing dot-segments.
620
621
622
623
!g!g?y/./x
!g!g?y/../x
!g!g#s/./x
!g!g#s/../x
=
=
=
=
xri://@a*a/!b!b/c*c/!g!g?y/./x
xri://@a*a/!b!b/c*c/!g!g?y/../x
xri://@a*a/!b!b/c*c/!g!g#s/./x
xri://@a*a/!b!b/c*c/!g!g#s/../x
624
2.4.3 Leading Segments Containing a Colon
625
626
[URI] points out that relative URI references with an initial segment containing a colon may be
subject to misinterpretation:
627
628
629
630
A path segment that contains a colon character (e.g., this:that) cannot be used
as the first segment of a relative-path reference because it would be mistaken for
a scheme name. Such a segment must be preceded by a dot-segment (e.g.,
./this:that) to make a relative-path reference.
631
632
633
Relative XRI references can be similarly misinterpreted. If any segment prior to the first slash (/)
character in a relative XRI reference contains a colon, the relative XRI reference must be
rewritten to begin either with *, if appropriate, or ./. Thus, a:b becomes either *a:b or ./a:b.
634
2.4.4 Leading Segments Beginning with a Cross-Reference
635
636
637
A path segment that begins with a cross-reference cannot be used as the first segment of a
relative reference because it would be mistaken for an xref-authority. As with a leading segment
containing a colon, such a segment must be preceded with ./ to make a relative XRI reference.
638
2.5 Normalization and Comparison
639
640
641
642
643
644
In general, the normalization and comparison rules for generic IRIs and URIs specified in Section
5 of [IRI] and Section 6 of [URI] apply to XRIs. This section describes a number of additional XRIspecific rules for normalization and comparison. To reduce the requirements imposed upon a
minimally conforming processor, the majority of these rules are RECOMMENDED rather than
REQUIRED. An implementation that fails to observe them, however, may frequently treat two
XRIs as non-equal when in fact they are equal.
645
646
647
648
Each application that uses XRI references MAY define additional equivalence rules as
appropriate. Due to the level of abstraction XRIs provide, such higher-order equivalence rules
may be based on indirect comparisons or specified XRI-to-XRI mappings (for example, mappings
of reassignable XRIs to persistent XRIs).
649
2.5.1 Case
650
The following rules regarding case sensitivity SHOULD be applied in XRI comparisons.
651
652
Comparison of the scheme component of XRIs and all IRIs used as cross-references is caseinsensitive.
653
Comparison of authority components (section 2.2.1) is case-insensitive as defined in [IRI].
654
655
As specified in section 2.1.4, comparison of characters in a percent-encoding construction is

case-insensitive for the hexadecimal digits A through F, i.e. %ab is equivalent to %AB.
14 March 2005
Page 17 of 34
656
2.5.2 Encoding, Percent-Encoding, and Transformations
657
658
659
Two XRIs MUST be considered equivalent if they are character-for-character equivalent.

Therefore, they are also equivalent if they are byte-for-byte equivalent and use the same
character encoding.
660
661
662
663
Two XRIs that differ only in whether unreserved characters are percent-encoded SHOULD be
considered equivalent. If one XRI percent-encodes one or more unreserved characters, and
another XRI differs only in that the same characters are not percent-encoded, they are
equivalent.
664
665
666
All forms of an XRI during the transformation process described in section 2.3.1 SHOULD be
considered equivalent, assuming the same XRI metadata is inserted as described in section
2.3.1.
667
2.5.3 Optional Syntax
668
669
670
671
2.5.4 Cross-References
672
673
674
An xri-segment (section 2.2.3) that omits the optional leading star (*) SHOULD be
considered equivalent to the same xri-segment prefixed with an star. For example the
segment /foo*bar is equivalent to the segment /*foo*bar.
If an XRI contains a cross-reference, the rules in this section SHOULD be applied recursively
to each cross-reference. For example, the following two XRIs should be considered
equivalent:
675
676
xri://@example/(+example/(+foo))
xri://@example/(+Example/(+FOO))
677
678
679
680
681
2.5.5 Canonicalization
682
683
684
685
686
In general, XRI references do not have a single canonical form. This is particularly true for XRI
references that contain IRI cross-references, since many URI schemes, including the HTTP
scheme, do not define a canonical form. Additionally, the authority for a particular segment of an
XRI reference may define its own rules with respect to case-sensitivity, optional or implicit syntax
etc., so canonicalization of those segments is outside the scope of this specification.
687
688
689
690
It is nevertheless useful to define guidelines for making XRI references reasonably canonical. XRI
references that follow these guidelines will be more consistent in presentation, simpler to process,
less prone to false-negative comparisons, and more easily cached. To that end, unless there is a
compelling reason to do otherwise, XRI references SHOULD be provided in a form in which:
From the standpoint of XRI syntax, all cross-references beginning with the GCS $ symbol
SHOULD be considered significant unless stated otherwise in the governing specification, for
example Extensible Resource Identifier (XRI) Metadata V2.0 [XRIMetadata]. See section
2.1.4.1.
691
The optional xri:// prefix is included,
692
The scheme is specified in lowercase,
693
The authority component is specified in lowercase,
694
Percent-encoding uses uppercase A through F,
695
If optional, the leading star in xri-segments is omitted,
696
Unnecessary percent-encoding is not present,
697
/./ and /../ are absent in absolute XRIs, and
698
Cross-references are reasonably canonical with respect to their schemes.
14 March 2005
Page 18 of 34
699
700
701
702
Table 2 illustrates the application of these rules. Although the XRIs in the first and second
columns are equivalent, the form in the second column is recommended.
Avoid
Recommended
Comment
@example
xri://@example
Add optional xri://
XRI://@example
xri://@example
Lowercase xri
xri://@Example
xri://@example
Lowercase authority
xri://@example%2f
xri://@example%2F
Uppercase percent-encoding
xri://@example/*abc
xri://@example/abc
Remove optional leading star
xri://@ex%61mple
xri://@example
Remove unnecessary percentencoding
xri://@example/./abc
xri://@example/abc
Avoid /./ and /../ in absolute XRIs
Table 2: Examples of XRI canonicalization recommendations.
14 March 2005
Page 19 of 34
703
3 Security and Data Protection Considerations
704
705
706
To a great extent, XRI syntax has the same security considerations as [IRI] and [URI]. In
particular the material in [URI], section 7, Security Considerations, includes a discussion of the
following topics:
707
Reliability and Consistency
708
Malicious Construction
709
Back-End Transcoding
710
Rare IP Address Formats
711
Sensitive Information
712
Semantic Attacks
713
714
715
716
This material notes that a URI does not in itself pose a direct security threat. In the case of
XRIs, this statement remains true only in legacy environments. As noted below, it may not be true
for new infrastructure that builds on the extensibility of XRI architecture. In particular the following
features of XRIs deserve special mention.
717
3.1 Cross-References
718
719
Since cross-references in an XRI can reference other URI schemes, implementation must
carefully consider the relevant security considerations for those referenced schemes.
720
3.2 XRI Metadata
721
722
723
724
The use of cross-references employing the GCS $ symbol for encoding XRI metadata in an XRI
(section 2.1.4.1) may involve other security and data protection considerations that are outside
the scope of this specification. These considerations are addressed in Extensible Resource
Identifier (XRI) Metadata V2.0 [XRIMetadata].
725
3.3 Spoofing and Homographic Attacks
726
727
728
729
730
731
One particularly important security consideration is spoofing, covered first in [URI] and more
thoroughly in [IRI] Section 7.5. Spoofing is a semantic attack in which an identifier is deliberately
constructed to deceive the user into believing it represents one resource when in fact it
represents another. With IRIs in particular, a common example of such an attack is using
homographic characters (characters from different scripts whose visual appearance is nearly or
perfectly identical, e.g., the Latin "A", the Greek "Alpha", and the Cyrillic "A".)
732
733
734
735
736
Spoofing has already been used extensively in email "phishing" attacks. As more browsers add
support for Internationalized Domain Names (IDN), it is also beginning to appear in online Web
links ("pharming"). Not only are some users less suspicious of URIs on the Web, but the attacker
may even obtain a corresponding SSL/TLS certificate for the deceptive URI or IRI to make the
fraudulent site look completely secure and legitimate.
737
738
739
To help prevent this problem, XRI registries SHOULD institute policies preventing the registration
of deceptive XRIs, and user agents that process XRIs SHOULD incorporate safeguards such as
warning users when XRIs contain common homographic characters.
740
3.4 UTF-8 Attacks
741
742
Since XRIs incorporate the use of UTF-8 as specified by [IRI], they can also be subject to UTF-8
parsing attacks as described in section 10 of [RFC3629]:
14 March 2005
Page 20 of 34
743
744
745
746
Implementers of UTF-8 need to consider the security aspects of how they

handle illegal UTF-8 sequences. It is conceivable that in some circumstances an
attacker would be able to exploit an incautious UTF-8 parser by sending it an
octet sequence that is not permitted by the UTF-8 syntax.
747
For more information on these attacks, see section 10 of [RFC3629].
748
3.5 XRI Usage in Evolving Infrastructure
749
750
751
752
As XRIs are adopted as abstract identifiers, it is anticipated that new services will be developed
that take advantage of their extensibility. In particular, XRIs may enable new solutions to security
and data protection problems at the resource identifier level that are not possible using existing
URI schemes.
753
754
755
756
For example, XRI cross-reference syntax permits the inclusion of identifier metadata such as an
encrypted or integrity-checked path, query or fragment. Cross-references can also be used to
indicate methods of obfuscating, proxying or redirecting resolution to prevent the exposure of
private or sensitive data.
757
758
759
760
761
A complete discussion of this topic is beyond the scope of this document. However, as a
consequence of XRI extensibility, it is not possible to make definitive statements regarding all
security and data protection considerations related to XRIs. New XRI-producing or consuming
applications should include independent security reviews for the specific contexts in which they
will be used.
14 March 2005
Page 21 of 34
762
4 References
763
4.1 Normative
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
[IRI]
[RFC1737]
[RFC2119]
[RFC2141]
[RFC2234]
[RFC2718]
[RFC2732]
[RFC3305]
M. Duerst, M. Suignard, Internationalized Resource Identifiers (IRIs),

http://www.ietf.org/rfc/rfc3987.txt, RFC 3987, January 2005.
K. Sollins, L. Masinter, Functional Requirements for Uniform Resource
Names, http://www.ietf.org/rfc/rfc1737.txt, RFC 1737, December 1994.
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,
http://www.ietf.org/rfc/rfc2119.txt, RFC 2119, March 1997.
R. Moats, URN Syntax, http://www.ietf.org/rfc/rfc2141.txt, IETF RFC
2141, May 1997.
D. H. Crocker and P. Overell, Augmented BNF for Syntax Specifications:
ABNF, http://www.ietf.org/rfc/rfc2234.txt, RFC 2234, November 1997.
L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, Guidelines for New
URL Schemes, http://www.ietf.org/rfc/rfc2718.txt, RFC 2718, November
1999.
R. Hinden, B. Carpenter, L. Masinter, Format for Literal IPv6 Addresses
in URL's, http://www.ietf.org/rfc/rfc2732.txt, RFC 2732, December,
1999.
M. Mealing, R. Denenberg, Uniform Resource Identifiers (URIs), URLs,
and Uniform Resource Names (URNs): Clarifications and

Recommendations, http://www.ietf.org/rfc/rfc3305.txt, RFC 3305,
August 2002.
[RFC3491]
P. Hoffman, M. Blanchet, Nameprep: A Stringprep Profile for
Internationalized Domain Names (IDN), http://www.ietf.org/rfc/rfc3491,
RFC 3491, March 2003.
[RFC3629]
F. Yergeau, UTF-8, A Transformation Format of ISO 10646,
http://www.faqs.org/rfcs/rfc3629.html, RFC 3629, November, 2003.
[UniXML]
Duerst, M. and A. Freytag, Unicode in XML and other Markup Languages,
Unicode Technical Report #20, World Wide Web Consortium Note,
February 2002.
[URI]
T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier
(URI): Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt, STD 66, RFC
3986, January 2005.
[UTR15]
M. Davis, M. Duerst, Unicode Normalization Forms,
http://www.unicode.org/unicode/reports/tr15/tr15-23.html, April 17,
2003.
[XRIMetadata] D. Reed, Extensible Resource Identifier (XRI) Metadata V2.0,
http://docs.oasis-open.org/xri/xri/V2.0/xri-metadata-V2.0-cd-01.pdf,
March 2005.
[XRIResolution] G. Wachob, Extensible Resource Identifier (XRI) Resolution V2.0,
http://docs.oasis-open.org/xri/xri/V2.0/xri-resolution-V2.0-cd-01.pdf,
March 2005.
14 March 2005
Page 22 of 34
804
805
806
807
808
809
810
811
812
4.2 Informative
[XRIIntro]
[XRIReqs]
D. Reed, D. McAlpin, Introduction to XRIs, http://docs.oasisopen.org/xri/xri/V2.0/xri-intro-V2.0.pdf, Work-In-Progress, March 2005.

G. Wachob, D. Reed, M. Le Maitre, D. McAlpin, D. McPherson, Extensible
Resource Identifier (XRI) Requirements and Glossary v1.0,
http://www.oasisopen.org/apps/org/workgroup/xri/download.php/2523/xri-requirementsand-glossary-v1.0.doc, June 2003.
14 March 2005
Page 23 of 34
813
814
815
816
Appendix A. Collected ABNF for XRI (Normative)

This section contains the complete ABNF for XRI syntax. XRI productions use green shading,
while productions inherited from IRI use yellow shading. A valid XRI MUST conform to this ABNF.
817
818
XRI

[ "#" ifragment ]
819
820
xri-hier-part
= ( xri-authority / iauthority ) [ xri-path-absolute ]

/ ipath-empty
821
822
XRI-reference
= XRI
/ relative-XRI-ref
823
absolute-XRI
824
xri-value
= xri-no-scheme / relative-XRI-ref
825
826
xri-no-scheme
= xri-hier-part [ "?" iquery ]

[ "#" ifragment ]
827
relative-XRI-ref
= xri-path [ "?" iquery ] [ "#" ifragment ]
828
829
xri-authority
= gcs-authority
/ xref-authority
830
gcs-authority
= pgcs-authority / rgcs-authority
831
pgcs-authority
= "!" xri-subseg-pt-nz *xri-subseg
832
rgcs-authority
= rgcs-char xri-segment
833
rgcs-char
= "=" / "@" / "+" / "$"
834
xref-authority
= xref *xri-subseg
835
xref
= "(" ( XRI-reference / IRI ) ")"
836
837
838
xri-path
= xri-path-absolute
/ xri-path-noscheme
/ ipath-empty
839
xri-path-absolute = "/" [ xri-segment-nz *( "/" xri-segment ) ]
840
xri-path-noscheme = xri-subseg-od-nx *xri-subseg-nc *( "/" xri-segment )
841
xri-segment
= xri-subseg-od *xri-subseg
842
xri-segment-nz
= xri-subseg-od-nz *xri-subseg
843
xri-subseg
= ( "*" / "!" ) (xref / *xri-pchar)
844
xri-subseg-nc
= ( "*" / "!" ) (xref / *xri-pchar-nc)
845
xri-subseg-od
= [ "*" / "!" ] (xref / *xri-pchar)
14 March 2005
Page 24 of 34
846
xri-subseg-od-nz
= [ "*" / "!" ] (xref / 1*xri-pchar)
847
xri-subseg-od-nx
= [ "*" / "!" ] 1*xri-pchar-nc
848
xri-subseg-pt-nz
= "!" (xref / 1*xri-pchar)
849
xri-pchar
= iunreserved / pct-encoded / xri-sub-delims / ":"
850
xri-pchar-nc
= iunreserved / pct-encoded / xri-sub-delims
851
xri-reserved
= xri-gen-delims / xri-sub-delims
852
853
xri-gen-delims
= ":" / "/" / "?" / "#" / "[" / "]" / "("

/ ")" / "*" / gcs-char
854
xri-sub-delims
= "&" / ";" / "," / "'"
855
856
IRI
= scheme ":" ihier-part [ "?" iquery ]

[ "#" ifragment ]
857
scheme
= ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
858
859
860
861
ihier-part
=
/
/
/
862
iauthority
= [ iuserinfo "@" ] ihost [ ":" port ]
863
iuserinfo
= *( iunreserved / pct-encoded / sub-delims / ":" )
864
ihost
= IP-literal / IPv4address / ireg-name
865
IP-literal
= "[" ( IPv6address / IPvFuture
866
IPvFuture
= "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
867
868
869
870
871
872
873
874
875
IPv6address
=
/
/
/
/
/
/
/
/
876
ls32
= ( h16 ":" h16 ) / IPv4address
877
h16
= 1*4HEXDIG
878
IPv4address
= dec-octet "." dec-octet "." dec-octet "." dec-octet
879
880
881
882
883
dec-octet
=
/
/
/
/
"//" iauthority ipath-abempty

ipath-abs
ipath-rootless
ipath-empty
[
[
[
[
[
[
[
*1(
*2(
*3(
*4(
*5(
*6(
h16
h16
h16
h16
h16
h16
":"
":"
":"
":"
":"
":"
)
)
)
)
)
)
h16
h16
h16
h16
h16
h16
h16
DIGIT
%x31-39 DIGIT
"1" 2DIGIT
"2" %x30-34 DIGIT
"25" %x30-35
]
]
]
]
]
]
]
"::"
"::"
"::"
"::"
"::"
"::"
"::"
"::"
;
;
;
;
;
6(
5(
4(
3(
2(
) "]"
h16
h16
h16
h16
h16
h16
":"
":"
":"
":"
":"
":"
)
)
)
)
)
ls32
ls32
ls32
ls32
ls32
ls32
ls32
h16
0-9
10-99
100-199
200-249
250-255
14 March 2005
Page 25 of 34
884
ireg-name
= *( iunreserved / pct-encoded / sub-delims )
885
port
= *DIGIT
886
ipath-abempty
= *( "/" isegment )
887
ipath-abs
= "/" [ isegment-nz *( "/" isegment ) ]
888
ipath-rootless
= isegment-nz *( "/" isegment )
889
ipath-empty
= 0<ipchar>
890
isegment
= *ipchar
891
isegment-nz
= 1*ipchar
892
iquery
= *( ipchar / iprivate / "/" / "?" )
893
iprivate
= %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
894
ifragment
= *( ipchar / "/" / "?" )
895
ipchar
= iunreserved / pct-encoded / sub-delims / ":" / "@"
896
iquery
= *( ipchar / iprivate / "/" / "?" )
897
ifragment
= *( ipchar / "/" / "?" )
898
iunreserved
= ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
899
pct-encoded
= "%" HEXDIG HEXDIG
900
901
902
903
904
905
ucschar
=
/
/
/
/
/
906
reserved
= gen-delims / sub-delims
907
gen-delims
= ":" / "/" / "?" / "#" / "[" / "]" / "@"
908
909
sub-delims
= "!" / "$" / "&" / "'" / "(" / ")"

/ "*" / "+" / "," / ";" / "="
910
unreserved
= ALPHA / DIGIT / "-" / "." / "_" / "~"
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF

%xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
%xD0000-DFFFD / %xE1000-EFFFD
14 March 2005
Page 26 of 34
912
Appendix B. Transforming HTTP IRIs to XRIs

(Non-Normative)
913
914
915
916
917
918
919
To leverage existing infrastructure, it may sometimes be useful to convert HTTP IRIs into XRIs.
Because XRI syntax is, for the most part, a superset of generic IRI syntax, the majority of HTTP
IRIs can be converted to valid XRIs simply by replacing the scheme name http with xri.
Generally the authority component of the resulting XRI will be properly interpreted as an IRI
authority. There are some cases, however, in which a legal authority component in an IRI will be
interpreted as an XRI authority rather than an IRI authority when the IRI is converted to an XRI.
For example,
911
920
921
922
http://!!1/example
is a legal IRI. Converted to an XRI, it would become

xri://!!1/example
923
924
925
926
927
928
The authority !!1 matches both the xri-authority and the iauthority ABNF productions. It would
be interpreted as an XRI authority, however, based on the first-match-wins rule used to resolve
ambiguities in the ABNF. Section 2.2.1.2 provides other examples of legal IRI authorities that
would be interpreted as XRI authorities when used in an XRI. Note, however, that these cases
are unlikely to arise in practice, since they typically result in an invalid URI when converted from
an IRI.
929
930
931
932
933
934
935
936
Special consideration must also be given to HTTP IRIs employing those characters in common
between the sub-delims production of [IRI] and the xri-gen-delims production of this
specification, namely opening parenthesis ((), closing parenthesis ()), star (*), bang (!),
dollar sign ($), plus sign (+) and equals sign (=). These characters are reserved as delimiters
in HTTP IRIs but have no scheme-specific meaning (i.e., they are only used as delimiters in a
manner defined by a local authority). In XRIs, however, these characters do have defined
semantics that may or may not match the meaning intended by an IRI author. Conversion of such
IRIs to XRIs must be handled on a case-by-case basis.
14 March 2005
Page 27 of 34
937
Appendix C. Glossary
938
939
940
The following definitions are common to this specification, the XRI Resolution specification
[XRIResolution], and the XRI Metadata specification [XRIMetadata].) Note that this glossary
supercedes the glossary in [XRIReqs].
941
Absolute Identifier
942
943
944
An identifier that refers to a resource independent of the current context, i.e., one that
establishes a global context. Mutually exclusive with Relative Identifier.
Abstract Identifier
945
An identifier that is not directly resolvable to a resource, but is either:
946
947
a) a self-reference, because it completely represents a non-network resource and is not

further resolvable (see Self-Reference), or
948
949
b) an indirect reference to a resource, because it must first be resolved to another

identifier (either another abstract identifier or a concrete identifier).
950
951
952
953
A URN as described in [RFC2141] is one kind of abstract identifier. Compared to

concrete identifiers, abstract identifiers permit additional levels of indirection in
referencing resources, which can be useful for a variety of purposes, including
persistence, equivalence, human-friendliness, and data protection.
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
Authority (or Identifier Authority)

In the context of identifiers, an authority is a resource that assigns identifiers to other
resources. Note that in URI syntax as defined in [URI], the authority production refers
explicitly to the top-level authority identified by the segment beginning with //. Since XRI
syntax supports unlimited federation, the term authority can technically refer to an
identifier authority at any level. However, in the xri-authority and iauthority productions
(section 2.2.1), it explicitly refers to the top-level identifier authority. See also IRI
Authority and XRI Authority
In the context of identifier resolution, an authority is a resource (typically a server) that
responds to resolution requests from another resource (typically a client). From this
perspective, each sub-segment in the authority segment of an XRI identifies a separate
authority.
Base Identifier
An absolute identifier that identifies a context for a relative identifier. Changing the base
identifier changes the context of the relative identifier. See Relative Identifier.
Canonical Form
The form of an identifier after applying transformation rules for the purpose of determining
equivalence. See also Normal Form.
Community (or Identifier Community)
A set of resources that share a common identifier authority, often (but not always) a
common root authority. Technically, a set of resources whose identifiers form a directed
graph or tree.
Concrete Identifier
An identifier that can be directly resolved to a resource or resource representation, rather
than to another identifier. Examples include the MAC address of a networked computer
and a phone number that rings directly to a specific device. All concrete identifiers are
intended to be resolvable. Contrast with Abstract Identifier.
14 March 2005
Page 28 of 34
982
983
984
985
986
987
988
989
Context (or Identifier Context)

The resource of which an identifier is an attribute. For example, in the string of identifiers
a/b/c, the context of the identifier b is the resource identified by a/, and the context of
the identifier c is the resource identified by a/b/. Since multiple resources may assign
an identifier for a target resource, the resource can be said to be identified in multiple
contexts. For absolute identifiers, the context is global, i.e., there is a known starting
point, or root. For relative identifiers, the context is implicit. See also Base Identifier.
Cross-reference
990
991
992
993
994
995
996
997
998
An identifier assigned in one context that is reused in another context. Cross-references

enable the expression of polyarchical relationships (relationships that cross multiple
hierarchies see Polyarchy.) Cross-references can be used to identify logically
equivalent resources in different domains, authorities, or physical locations. For example,
a cross-reference may be used to identify the same logical invoice stored in two
accounting systems (the originating system and the receiving system), the same logical
Web document stored on multiple proxy servers, the same logical datatype used in
multiple databases or XML schemas, or the same logical concept used in multiple
taxonomies or ontologies.
999
1000
1001
1002
1003
1004
In XRI syntax, cross-references are syntactically delimited by enclosing them in

parentheses. This is analogous to enclosing a word or phrase in quotation marks in a
natural language, such as English, to indicate that the author is referring to it independent
of the current context. For example, the phrase love bird is quoted in this sentence to
indicate that we are mentioning, rather than using, the phrase - that is, we are referring to
it independent of the context of this glossary.
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
Delegated Identifier
A multi-segment identifier in which segments are assigned by more than one identifier
authority. Namespace authority is delegated from one identifier authority to the next.
Mutually exclusive with Local Identifier.
Federated Identifier
A delegated identifier that spans multiple independent identifier authorities. See also
Delegated Identifier.
Global Context Symbol (GCS)
A reserved character used at the start of the authority segment of an XRI to establish the
global context of an XRI authority. XRI 2.0 defines four Global Context Symbols, which
are used to represent persons, organizations, the public, and standards specifications.
See section 2.2.1.2.
Hierarchy
A branching tree structure in which all primary relationships are parent-child. (Sibling
relationships in a hierarchy are secondary, derived from the parent-child relationships.)
URI and IRI syntax has explicit support for hierarchical paths. XRI syntax supports both
hierarchical and polyarchical paths. See Polyarchy and Cross-reference.
Human-Friendly Identifier (HFI)
An identifier containing words or phrases intended to convey meaning in a specific
human language which is therefore easy for people to remember and use. Contrast with
"Machine-Friendly Identifier."
Identifier
Per [URI], anything that embodies the information required to distinguish what is being
identified from all other things within its scope of identification. In UML terms, an
identifier is an attribute of a resource (the identifier context) that forms an association with
14 March 2005
Page 29 of 34
1030
1031
1032
1033
1034
another resource (the identifier target). The general term identifier does not specify
whether the identifier is abstract or concrete, absolute or relative, persistent or
reassignable, human-friendly or machine-friendly, delegated or local, hierarchical or
polyarchical, or resolvable or self-referential.
I-name
1035
1036
1037
An informal term used to refer to a reassignable XRI; more specifically, an XRI in which
at least one sub-segment is reassignable.
I-number
1038
1039
1040
1041
An informal term used to refer to a persistent XRI; more specifically, an XRI in which all
sub-segments are persistent. Note that a persistent XRI is not required to be numeric - it
may be any text string meeting the XRI ABNF requirements.
IRI (Internationalized Resource Identifier)
1042
1043
1044
1045
1046
1047
IRI is a specification for internationalized URIs developed by the W3C. IRIs specify how
to include characters from the Universal Character Set (Unicode/ISO10646) in URIs. The
IRI specification [IRI] provides a mapping from IRIs to URIs, which allows IRIs to be used
instead of URIs where appropriate. This XRI specification defines a similar transformation
from XRIs to IRIs for the same reason.
IRI Authority
1048
1049
1050
1051
An identifier authority (see Authority) represented by the authority segment of an XRI

that does not match the xri-authority production but matches the iauthority production
from [IRI]. See section 2.2.1.3. Mutually exclusive with XRI Authority.
Local Identifier
1052
1053
1054
1055
Any identifier, or any set of segments in a multi-segment identifier, that is assigned by the
same identifier authority. Each of these segments is local to that authority. Mutually
exclusive with Delegated Identifier.
Machine-Friendly Identifier (MFI)
1056
1057
1058
1059
1060
An identifier containing digits, hexadecimal values, or other character sequences

optimized for efficient machine indexing, searching, routing, caching, and resolvability.
MFIs generally do not contain human semantics. Compare with "Human-Friendly
Identifier."
Normal Form
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
The character-by-character format of an identifier after encoding, escaping, or other

character transformation rules have been applied in order to satisfy syntactic
requirements. Three normal forms are defined for XRIsXRI-normal form, IRI-normal
form, and URI-normal form. See section 2.3.1 for details. See also Canonical Form.
Path
The relationships between resources defined by a multi-segment identifier. In less strict
contexts, the word path often refers to the multi-segment identifier itself, or to the
resources it represents (such as filesystem directories).
Persistent Identifier
An identifier that is permanently assigned to a resource and intended never to be
reassigned to another resource - even if the original resource goes off the network, is
terminated, or ceases to exist. A URN as described in [RFC2141] is an example of a
persistent identifier. Persistent identifiers tend to be machine-friendly identifiers, since
human-friendly identifiers often reflect human semantic relationships that may change
over time. Mutually exclusive with Reassignable Identifier.
14 March 2005
Page 30 of 34
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
Polyarchy
A treelike structure composed of multiple intersecting hierarchies in which primary
relationships can cross hierarchies. A polyarchy allows one member to be connected or
linked to any other, although, in contrast to a web, the overall structure tends to remain
strongly hierarchical. XRIs support polyarchic paths through the use of cross-references.
See also Cross-reference and Hierarchy.
Reassignable Identifier
An identifier that may be reassigned from one resource to another. Example: the domain
name example.com may be reassigned from ABC Company to XYZ Company, or the
email address [email protected] may be reassigned from Mary Smith to Mary Jones.
Reassignable identifiers tend to be human-friendly because they often represent the
potentially transitory mapping of human semantic relationships onto network resources or
resource representations. Mutually exclusive with Persistent Identifier.
Relative Identifier
An identifier that refers to a resource only in relationship to a particular context (for
example, the current community, the current document, or the current position in a
delegated identifier). If the context changes, the identifiers meaning also changes. A
relative identifier can be converted into an absolute identifier by combining it with a base
identifier (an absolute identifier that is used to identify a context). See Base Identifier.
Mutually exclusive with Absolute Identifier.
Resolvable Identifier
An identifier that references a network resource or resource representation and that can
be resolved into a network endpoint for communicating with the target resource. Mutually
exclusive with Self-Reference.
Resource
Per [URI], anything that can be named or described. Resources are of two types:
network resources (those that are network-addressable) and non-network resources
(those that exist entirely independent of a network). Network resources are themselves of
two types: physical resources (resources physically attached to or operating on the
network) or resource representations (see Resource Representation).
Resource Representation
A network resource that represents the attributes of another resource. A resource
representation may represent either another network resource (such as a machine,
service, or application) or a non-network resource (such as a person, organization, or
concept).
Segment (or Identifier Segment)
Any syntactically delimited component of an identifier. In generic URI syntax, all
segments after the authority portion are delimited by forward slashes
(/segment1/segment2/). In XRI syntax, slash segments can be further subdivided into
sub-segments called star segments (for reassignable identifiers) and bang segments (for
persistent identifiers). See section 2.2.3. XRI also supports another type of segment
called a cross-reference, which is enclosed in parentheses. See Cross-Reference.
Self-Reference (or Self-Referential Identifier)
An identifier which is itself the representation of the resource it references. Selfreferences are typically used to represent non-network resources (e.g., love, Paris,
the planet Jupiter) in contexts where this identifier is not intended to be resolved to a
separate network representation of that resource. The primary purpose of self-references
is to establish equivalence across contexts (see Cross-References). Mutually exclusive
with Resolvable Identifier.
14 March 2005
Page 31 of 34
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
Sub-segment
A syntactically delimited component of an identifier segment (see Segment). While URI
and IRI syntax define only segments, XRI syntax defines both segments and subsegments. XRI sub-segments are used to distinguish among persistent identifiers,
reassignable identifiers, and cross-references. See sections 2.2.2 and 2.2.3.
Synonym (or Identifier Synonym)
An identifier that is asserted by an identifier authority to be equivalent to another identifier
not because of strict literal equivalence, but because it resolves to the same resource.
Target (or Identifier Target)
The resource referenced by an identifier. A target may be either a network resource
(including a resource representation) or a non-network resource.
URI (Uniform Resource Identifier)
The standard identifier used in World Wide Web architecture. Starting in 1998, RFC 2396
has been the authoritative specification for URI syntax. In January 2005 it was
superseded by RFC 3986 [URI].
XDI (XRI Data Interchange)
A generalized, extensible service for sharing, linking, and synchronizing XML data and
metadata associated with XRI-identified resources. XDI is being developed by the OASIS
XDI Technical Committee (http://www.oasis-open.org/committees/xdi).
XRI Authority
An identifier authority (see Authority) represented by the authority segment of an XRI
that begins with either a global context symbol or a cross-reference. See section 2.2.1.1.
Mutually exclusive with IRI Authority.
XRI Descriptor (XRID)
An XML document returned by an authority in the process of XRI resolution as defined in
section 2.2.2 of the XRI Resolution specification [XRIResolution].
XRI Reference
A term that includes both absolute and relative XRIs. Used in the same way as URI
reference and IRI reference. Note that to transform an XRI reference into an XRI, it
must first be converted to absolute form, which in the case of a relative XRI requires the
use of a base XRI to establish context.
14 March 2005
Page 32 of 34
1156
Appendix D. Acknowledgments
1157
1158
The editors would like to acknowledge the contributions of the OASIS XRI Technical Committee,
whose voting members at the time of publication were:
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
Geoffrey Strongin, Advanced Micro Devices

Ajay Madhok, AmSoft Systems
Jean-Jacques Dubray, Attachmate
William Barnhill, Booz Allen and Hamilton
Drummond Reed, Cordance Corporation
Marc Le Maitre, Cordance Corporation
Dave McAlpin, Epok
Loren West, Epok
Peter Davis, NeuStar
Masaki Nishitani, Nomura Research
Nat Sakimura, Nomura Research
Tetsu Watanabe, Nomura Research
Owen Davis, PlaNetwork
Victor Grey, PlaNetwork
Fen Labalme, PlaNetwork
Mike Lindelsee, Visa International
Gabriel Wachob, Visa International
Dave Wentker, Visa International
Bill Washburn, XDI.ORG
1178
1179
The editors also would like to acknowledge the following people for their contributions to previous
versions of the OASIS XRI specifications (affiliations listed for OASIS members):
1180
1181
1182
1183
1184
1185
1186
1187
Thomas Bikeev, EAN International; Krishna Sankar, Cisco; Winston Bumpus, Dell; Joseph
Moeller, EDS; Steve Green, Epok; Lance Hood, Epok; Adarbad Master, Epok; Davis McPherson,
Epok; Chetan Sabnis, Epok; Phillipe LeBlanc, GemPlus; Jim Schreckengast, Gemplus; Xavier
Serret, Gemplus; John McGarvey, IBM; Reva Modi, Infosys; Krishnan Rajagopalan, Novell;
Tomonori Seki, NRI; James Bryce Clark, OASIS; Marc Stephenson, TSO; Mike Mealling,
Verisign; Rajeev Maria, Visa International; Terence Spielman, Visa International; John Veizades,
Visa International; Lark Allen, Wave Systems; Michael Willett, Wave Systems; Matthew Dovey;
Eamonn Neylon; Mary Nishikawa; Lars Marius Garshol; Norman Paskin; Bernard Vatant.
1188
A special acknowledgement to Jerry Kindall (Epok) for a full editorial review.
1189
1190
Also, the authors of and contributors to the following documents and specifications are
acknowledged for the intellectual foundations of the XRI specification:
1191
RFC 1737
1192
RFC 2616
1193
RFC 2718
1194
RFC 3986 (STD 66) and its predecessor, RFC 2396
1195
RFC 3987
1196
XNS
1197
14 March 2005
Page 33 of 34
1198
Appendix E. Notices
1199
1200
1201
1202
OASIS takes no position regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such rights.
1203
1204
1205
1206
1207
Information on OASIS's procedures with respect to rights in OASIS specifications can be found at
the OASIS website. Copies of claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementors or users of this specification,
can be obtained from the OASIS President.
1208
1209
1210
OASIS invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology that may be required to
implement this specification. Please address the information to the OASIS President.
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
This document and translations of it may be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such copies and derivative works.
However, this document itself does not be modified in any way, such as by removing the
copyright notice or references to OASIS, except as needed for the purpose of developing OASIS
specifications, in which case the procedures for copyrights defined in the OASIS Intellectual
Property Rights document must be followed, or as required to translate it into languages other
than English.
1221
1222
The limited permissions granted above are perpetual and will not be revoked by OASIS or its
successors or assigns.
1223
1224
1225
1226
1227
This document and the information contained herein is provided on an "AS IS" basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
14 March 2005
Page 34 of 34

Xri Syntax V2.0 CD 01

Uploaded by

Copyright:

Available Formats

Xri Syntax V2.0 CD 01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Xri Syntax V2.0 CD 01

Uploaded by

Copyright:

Available Formats

1

Extensible Resource Identifier (XRI)

Committee Draft 01, 14 March 2005

Technical Committee members should send comments on this specification to the

The non-normative errata page for this specification is located at http://www.oasisopen.org/committees/xri.

2.1.5 Excluded Characters...................................................................................................... 8

2.2.2 Cross-References ........................................................................................................ 11

2.4.3 Leading Segments Containing a Colon ....................................................................... 17

3.1 Cross-References ............................................................................................................... 20

1.1 Overview of XRIs

Extensible Resource Identifiers (XRIs) provide a standard means of abstractly identifying a

Extends character set

Figure 1: The relationship of XRIs, IRIs, and URIs

XRI Resolution [XRIResolution] specifies both a standard and a trusted HTTP-based

1.1.1 Generic Syntax

2. Cross-references. Cross-references allow XRI references to contain other XRI references

4. Standardized federation. Federated identifiers are those delegated across multiple

1.1.2 URI, URL, URN, and XRI

1.2 Terminology and Notation

1.2.2 Syntax Notation

This is an example of ABNF specific to XRI.

This is an example of ABNF inherited from IRI.

2.1.1 Character Encoding

2.1.2 Reserved Characters

= ":" / "/" / "?" / "#" / "[" / "]" / "(" / ")"

= "&" / ";" / "," / ""

2.1.3 Unreserved Characters

= ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF

2.1.4 Percent-Encoded Characters

A percent-encoded octet is a character triplet consisting of the percent character % followed by

= "%" HEXDIG HEXDIG

2.1.4.1 Encoding XRI Metadata

2.1.5 Excluded Characters

Additional information is available from [UniXML]. [UniXML] is written in the

2.2 Syntax Components

= [ "xri://" ] xri-hier-part [ "?" iquery ]

= [ "xri://" ] xri-hier-part [ "?" iquery ]

= xri-hier-part [ "?" iquery ]

= xri-path [ "?" iquery ] [ "#" ifragment ]

2.2.1.1 XRI Authority

2.2.1.2 Global Context Symbol (GCS) Authority

= "!" xri-subseg-pt-nz *xri-subseg

= "=" / "@" / "+" / "$"

Identifiers for whom the authority is an individual person.

Identifiers for whom the authority is an organization or a

Identifiers for whom the authority is the general public, i.e.,

Identifiers for whom the authority is a specification from a

Table 1: XRI global context symbols.

2.2.1.3 IRI Authority

= [ iuserinfo "@" ] ihost [ ":" port ]

= *( iunreserved / pct-encoded / sub-delims / ":" )

= IP-literal / IPv4address / ireg-name

A cross-reference is syntactically delimited by enclosing it in parentheses, similar to the way an

= "(" ( XRI-reference / IRI ) ")"

It is important that the value of a cross-reference be syntactically unambiguous, whether it is an

xri-path-absolute = "/" [ xri-segment-nz *( "/" xri-segment ) ]

xri-path-noscheme = xri-subseg-od-nx *xri-subseg-nc

= ( "*" / "!" ) (xref / *xri-pchar)

= ( "*" / "!" ) (xref / *xri-pchar-nc)

= ( "" / "!" ) (xref / xri-pchar)

= ( "" / "!" ) (xref / xri-pchar-nc)

= [ "" / "!" ] (xref / xri-pchar)

= [ "" / "!" ] (xref / 1xri-pchar)

= [ "" / "!" ] 1xri-pchar-nc

xri-path-noscheme = xri-subseg-od-nx xri-subseg-nc ( "/" xri-segment )

= ( "" / "!" ) (xref / xri-pchar)

= ( "" / "!" ) (xref / xri-pchar-nc)

= [ "" / "!" ] (xref / xri-pchar)