DOC

xri-requirements-and-glossary-v10doc - OASIS Advancing open

By Alicia Ward,2014-05-06 11:07
17 views 0
xri-requirements-and-glossary-v10doc - OASIS Advancing open

1

    2 XRI Requirements and Glossary

    3 Version 1.0 12 June 2003

    4 Document identifier:

    5 xri-requirements-and-glossary-v1.0

    6 Location:

    7 http://www.oasis-open.org/committees/xri/spec/ 8 Editors:

    9 Gabe Wachob, Visa International <gwachob@visa.com> 10 Drummond Reed, OneName <drummond.reed@onename.com> 11 Marc LeMaitre, OneName <marc.lemaitre@onename.com> 12 Dave McAlpin, Epok <dave.mcalpin@epokinc.com> 13 Davis McPherson, Epok <davism@epokinc.com> 14 Abstract:

    15 This document describes architectural motivations and requirements for development of

    16 the Extensible Resource Identifier (XRI) specifications. It also includes a normative

    17 glossary of terms used in this document and other XRI deliverables.

    18 Status:

    19 This document is a committee requirements specification. It may be updated periodically

    20 on no particular schedule. Send comments to the editors.

    21 Committee members should send comments on this specification to the xri@lists.oasis-22 open.org list. Others should subscribe to and send comments to the xri-23 comment@lists.oasis-open.org list. To subscribe, send an email message to xri-

    24 comment-request@lists.oasis-open.org with the word "subscribe" as the body of the

    25 message.

    26 For information on whether any patents have been disclosed that may be essential to

    27 implementing this specification, and any offers of patent licensing terms, please refer to

    28 the Intellectual Property Rights section of the XRI TC web page (http://www.oasis-29 open.org/committees/xri/).

    30

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 1 of 28

    31 Table of Contents

    132 Introduction ......................................................................................................................... 4 1.1 Terminology ...................................................................................................................... 433 234 Motivations ......................................................................................................................... 5 2.1 Introduction ....................................................................................................................... 535 2.2 Persistent Identification...................................................................................................... 736 2.3 Human-Friendly vs. Machine-Friendly Identification ........................................................... 737 2.4 Cross-Context Identification ............................................................................................... 938 2.5 Resource Attribute and Version Identification ................................................................... 1039 2.6 Delegation, Federation, and Extensibility ......................................................................... 1040 2.7 Security and Privacy ........................................................................................................ 1141 342 XRI Syntax Requirements ................................................................................................. 12 3.1 URI and URN Requirements............................................................................................ 1243 3.1.1 URI Conformance .................................................................................................... 1244 3.1.2 URN Conformance ................................................................................................... 1245 3.2 Abstraction and Independence ........................................................................................ 1246 3.2.1 Location-Independence ............................................................................................ 1247 3.2.2 Application-Independence ........................................................................................ 1348 3.2.3 Transport-Independence .......................................................................................... 1349 3.2.4 Type-Independence ................................................................................................. 1350 3.2.5 Security Method-Independence ................................................................................ 1351 3.3 Persistent Identification.................................................................................................... 1352 3.3.1 Persistent Identifiers ................................................................................................. 1353 3.3.2 Reassignable Identifiers ........................................................................................... 1354 3.3.3 Combining Persistent and Reassignable Identifiers .................................................. 1455 3.4 Human-Friendly and Machine-Friendly Identification ........................................................ 1456 3.4.1 Human-Friendly Identifiers (HFIs) ............................................................................. 1457 3.4.2 Machine-Friendly Identifiers (MFIs)........................................................................... 1458 3.4.3 Combining HFIs and MFIs ........................................................................................ 1459 3.4.4 Identifier Mapping ..................................................................................................... 1460 3.4.5 Explicit Non-Resolvability ......................................................................................... 1461 3.4.6 Internationalization ................................................................................................... 1462 3.4.7 Character Encoding.................................................................................................. 1563 3.5 Cross-Context Identification ............................................................................................. 1564 3.5.1 Cross-References .................................................................................................... 1565 3.5.2 URIs as Cross-References ....................................................................................... 1566 3.6 Attribute and Version Identification................................................................................... 1567 3.6.1 Attribute Identification ............................................................................................... 1568 3.6.2 Version Identification ................................................................................................ 1569

    70

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 2 of 28

    71 3.7 Authority, Delegation, Federation, & Extensibility ............................................................. 16

    3.7.1 Unlimited Root Authorities ........................................................................................ 1672

    3.7.2 Unlimited Topologies ................................................................................................ 1673

    3.7.3 Unlimited Delegation and Federation ........................................................................ 1674

    3.7.4 Scheme Extensibility ................................................................................................ 1675

    3.7.5 Specializations ......................................................................................................... 1676 3.8 Data Protection and Security ........................................................................................... 1677

    3.8.1 Identifier Security ..................................................................................................... 1678

    3.8.2 Identifier Privacy....................................................................................................... 1779 480 XRI Resolution Requirements ........................................................................................... 18 4.1 Non-Resolvability ............................................................................................................ 1881 4.2 Semantic Mapping ........................................................................................................... 1882 4.3 Resolution Mechanism-Independence ............................................................................. 1883 4.4 Internet Resolution Mechanism........................................................................................ 1884 4.5 Unlimited Federation ....................................................................................................... 1885 4.6 Interoperability of Specializations ..................................................................................... 1886 4.7 Scalability ........................................................................................................................ 1887 4.8 Redundancy .................................................................................................................... 1888 4.9 Trusted Resolution .......................................................................................................... 1989 4.10 Proxy Resolution ........................................................................................................... 1990 591 Glossary ........................................................................................................................... 20 5.1 Normative Glossary ......................................................................................................... 2092 5.2 Informative Glossary........................................................................................................ 2593 694 References ....................................................................................................................... 26 Appendix A. Acknowledgments ................................................................................................. 2795 Appendix B. Notices .................................................................................................................. 2896

    97

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 3 of 28

98 1 Introduction

    99 This document is divided into four major sections:

    100 ? Motivations describes why the XRI TC was chartered and the major problems the XRI

    101 specifications are intended to address.

    102 ? XRI Syntax Requirements enumerates the requirements for the XRI URI scheme. 103 ? XRI Resolution Requirements enumerates the requirements for XRI resolution. 104 ? Glossary contains a listing of the key terms used in this document and the rest of the XRI

    105 TC deliverables.

    106 1.1 Terminology

    107 The key words must, must not, required, shall, shall not, should, should not, recommended,

    108 may, and optional in this document are to be interpreted as described in IETF RFC 2119

    109 [Keywords].

    110 Other terms used in this document are defined in the Glossary (Section 5).

    111

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 4 of 28

112 2 Motivations

    113 2.1 Introduction

    114 Internet architecture today is based primarily on two layers of identifiers, as shown in Figure 1:

    115

    Human-friendly identifiersDNS Names

    Machine-friendly identifiersIP Addresses

    Local Area Network ResourceLocal Area Network Resource116

    117 Figure 1: The two layers of Internet identifiers in predominant use today.

    118 The first layer, IP (Internet Protocol) addressing, defines the Internet itself. IP was developed to

    119 standardize packet exchange between local area networks, a task that required a layer of globally

    120 unique identifiers for every network segment and host. Since the goal was highly efficient packet

    121 routing, IP addresses were designed to be very machine-friendlya series of decimal numbers

    122 (IPv4) or hex characters (IPv6) representing fixed-byte addressing segments.

    123 172.14.206.73

    124 :AE46:83F2::9B15:2287

    125 A second layer, the DNS (Domain Name System), was subsequently developed to provide a

    126 name service for IP hosts. This abstraction layer solved two problems: a) it provided human-

    127 friendly identifiers for IP-addressable hosts, making them much easier for people to remember

    128 and use, and b) it allowed Internet hosts or users to have a logical identity that transcended a

    129 particular IP address.

    130 www.example.com

    131 mary.smith@example.com

    132 These two layers of identifiers, when combined with local area network identifiers, can uniquely

    133 identify any resource on the Internet. Tim Berners-Lee and other architects took full advantage of

    134 this when creating the World Wide Web. They developed an identifier syntax originally called URL 1(Uniform Resource Locator) and now called URI (Uniform Resource Identifier)135 that allowed a

    136 combination of DNS names, IP addresses, and local identifiers to serve as a hyperlink between

    137 resources. The syntactic rules for URI schemes (e.g., HTTP URIs, FTP URIs, email URIs, etc.) 2were most recently specified in IETF RFC 2396 in August 1998 [URI].138

    139 http://www.example.com/pages/products/widget.html

    140 mailto:mary.smith@example.com

    141 The phenomenal success of the Web meant that URIs became the fastest-growing new address

    142 in history. As the Web grew, it encountered the problem of links breaking because the resource

     1 The term "URL" is no longer in use by the IETF and W3C. See IETF RFC 3305, "Uniform Resource

    Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations". 2 A revision to the URI specification, RFC2396bis, is under preparation by Roy Fielding. See

    http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html.

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 5 of 28

143 referenced by a URI changed its location on the network. Berners-Lee and others recognized that

    144 solving this problem would require another level of abstractiona layer of persistent URIs that

    145 would remain the same even when the resources they referenced changed their locations. They

    146 called this new type of location-independent identifier a URN (Uniform Resource Name). The URI 3scheme for URNs was specified by IETF RFC 2141 in May 1997 [URN].147

    148 urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882

    149 urn:isbn:0-395-36341-1

    150 Since the completion of the IETF URN work, a number of new technologies have appeared for

    151 modeling human semantics and data exchange relationships over the Internet, including the

    152 Semantic Web, Topic Maps, Web services, digital identity, and digital rights management. While

    153 many of these technologies require persistent identifiers, they have also generated a number of

    154 other new requirements for abstract identifiers that are not addressed by URNs. These

    155 requirements form the primary motivations for XRIs as discussed in the following sections.

    156 The overall goal of the XRI specifications is to establish a standard syntax and resolution protocol

    157 for fully abstract identifiersin short, to enable a third layer of Internet identifiers similar to the 158 DNS naming and IP addressing layers that exist today, as shown in Figure 2:

    159

    XRI Abstract Identifiers

    DNS Names

    IP Addresses

    Local Area Network ResourceLocal Area Network Resource160

    161 Figure 2: XRIs are designed to provide a uniform third layer of abstract identifiers for Internet resources.

    162 The potential for this new layer goes beyond just the Internet. With the growing convergence of

    163 the Web with other networks such as wired and wireless phone networks, satellite networks,

    164 package delivery networks, etc., an XRI can serve as a true unified addressa single abstract

    165 identifier that can be resolved (with the appropriate data protections) to any concrete address or

    166 attribute associated with the target resource. Unified addresses represent an enormous potential

    167 savings in laborboth in people spending time looking up phone numbers, fax numbers, email

    168 addresses, etc., and in developers spending time coding and testing routines to locate and verify

    169 the current address of a target resource.

    170

    XRI

    DNSTelephonePostalFutureNumbersAddressesAddressesIP

    Web Web ResourcesResources171

    172 Figure 3: XRIs can serve as true unified addresses across all communications networks.

     3 The full scope of the IETF URN work is summarized at http://www.ietf.org/html.charters/urn-

    charter.html.

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 6 of 28

173 2.2 Persistent Identification

    174 As discussed above, the original motivation for a new layer of abstract identifiers was the need for

    175 persistencethe ability to for an identifier to maintain its association with a resource independent 176 of the resource's current location on the network. The requirements for persistent identifiers

    177 URNswere set forth by the IETF in RFC 1737 [URNReqs].

    178 The IETF URN specification [URN] requires absolute persistence, i.e., that the entire identifier

    179 never be reassigned to another resource for all time. The IETF recognized that such a

    180 requirement can be difficult to enforce operationally, since it depends on factors that are not

    181 technical in nature (the longetivity and business practices of the identifier authority, for example).

    182 In practice, many identifiers need only relative persistence in one of two ways. First, persistence

    183 be required within the context of a top-level authority which may itself have a reassignable

    184 identifier such as a DNS name or IP address. This is the case for many URIs within large

    185 database-driven web sites.

    186 http://www.someportal.com/s/19821

    187 http://somenews.com/2010-1071-998513.html

    188 http://www.somestore.com/exec/tg/browse/-/1/002-9387661-7480836

    189 Secondly, persistence may only be needed for a relative period of time. Even very long-lived

    190 identifiers may be reassigned, particularly in fixed address spaces. As a general rule, the

    191 frequency of reassignment varies with the type and purpose of the identifier. Postal addresses,

    192 for example, are usually very long-lived, lasting for decades or even centuries. By contrast phone

    193 numbers and DNS domain names both have typical registration cycles of from one to ten years.

    194 At the other end of the spectrum IP addresses may (especially in the case of dynamic IP

    195 assignment mechanisms like DHCP) be reassigned to a different computer every online session.

    196 Persistence can thus be viewed along a gradient from absolute to relative, and XRI syntax and

    197 resolution mechanisms should be designed to accommodate this gradient.

    198 Supporting both absolute and relative persistent identifiers is a key 199 motivation of the XRI specifications.

    200 2.3 Human-Friendly vs. Machine-Friendly Identification

    201 A second key property of abstract identifiers is their human-friendliness. By this, we mean the

    202 ability of a human being to understand, remember, and use an identifier, vs. the ability of a

    203 machine to efficiently resolve, cache, and process it. Perhaps the best example of these two

    204 polarities is DNS names and IP addresses. DNS names are typically very semantically reflective

    205 of the resource they represent.

    206 www.yahoo.com

    207 www.ibm.com/products

    208 mary.smith@hotmail.com

    209 IP addresses are just the opposite they are pure numeric or hexadecimal strings which are

    210 generally not semantically reflective of the resource they represent.

    211 172.14.206.73

    212 :AE46:83F2::9B15:2287

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 7 of 28

213 As with persistent vs. reassignable identifiers, there is a continuous gradient between human-

    214 friendly identifiers (HFIs) and machine-friendly identifiers (MFIs). In fact many composite 4identifiers, such as postal addresses, are typically a mixture of both HFI and MFI components.215

    216 Mary Smith, 4216 Corliss Ave North, Seattle WA 98133-8914

    217 The relationship of the HFI/MFI gradient and the persistent/reassignable gradient can be

    218 visualized by the following graph:

    219

    220

    221 Figure 4: The relationship of the persistent/reassignable gradient and the HFI/MFI gradient. 222 What this graph illustrates is that while an abstract identifier may theoretically fall anywhere in the

    223 spectrum above, in practice there is one quadrant where the two requirements conflictthe

    224 intersection of persistent identifiers and HFIs.

    225 The reason has nothing to do with technology and everything to do with the nature of human

    226 language. People are forever reassigning the meaning of words, names, and phrases. A filename

    227 assigned by a user to one file today may be reassigned to another file tomorrow. A domain name

    228 registered to one website this month may be reregistered to another next month. A trademark

    229 registered by one company this year could be sold to another the next. At the highest level, this

    230 constant redefinition of semantic identifiers manifests itself as the slow "semantic drift" of entire

    231 languagesthe primary reason many dictionaries are republished every year. 232 Semantic drift at any speed makes it difficult for HFIs to remain persistent. This is why most

    233 persistent identfiers tend to be partially or entirely MFIsstrings of numbers or "nonsense

    234 characters" that are unique but do not carry semantic meaning. Some URN systems, being the

    235 most persistent identifiers of all, are excellent examples.

    236 urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882

    237 urn:isbn:0-395-36341-1

    238 urn:ietf:rfc:2396

    239 Because of this inherent conflict between persistent and human-friendly identifiers, a second key

    240 requirement of XRIs is that:

    241 a. They must support any combination of persistent and reassignable HFIs and MFIs, and

    242 b. When a resource needs both a reassignable HFI and a persistent MFI, the XRI specifications

    243 must allow the former to be resolved to the latter.

     4 From an evolutionary standpoint, most early postal addresses consisted entirely of HFI components such

    as personal names, city names, state/province names, and country names. MFI components including

    routing numbers and postal codes were added later to support automated mail handling equipment.

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 8 of 28

244 This second scenario, called semantic mapping, mirrors the same two-layer model for abstract

    245 identifiers that DNS names and IP addresses provide for concrete identifiers as shown in Fig. 5.

    246

    Human-friendlyReassignable XRIDNS Name

    Persistent XRIIP AddressMachine-friendly

    Abstract IdentifiersConcrete Identifiers247

    248 Figure 5: XRIs can map reassignable HFIs to persistent MFIs the same way DNS names are mapped to IP

    249 addresses.

    250 Semantic mapping can solve a wide range of problems relating to human usability of network

    251 resources, ranging from smarter search technologies and simpler security systems to more

    252 intelligent user interfaces and natural language translation applications.

    253 Providing a unified syntax for both HFIs and MFIs and semantic mapping

    254 between the two is a key motivation of the XRI effort.

    255 2.4 Cross-Context Identification

    256 Another of the key advantages of fully abstract identifiers is that they are very useful for

    257 identifying resources that may have multiple concrete representations in different network

    258 locations. To borrow a real-world example, the English language concept of "President" has a

    259 concrete representation in many different companies. In fact a postal letter can usually be

    260 addressed to the president of a company simply by using the abstract identifier, "President,

    261 [postal address of company]".

    262 Yet this same generalization is the exception rather than the rule with network resources. To be

    263 sure, some username conventions like "postmaster", "info", "sales", or "support" are commonly

    264 used to route email messages to those well-known functions of an organization. But few such

    265 conventions exist for Web resources beyond the DNS server for a website having the name

    266 "www" or the home page of a web site having the name "index.htm" or "index.html".

    267 It can be very useful to have a standard way of identifying logically equivalent resources across

    268 multiple physical contextsfor example, being able to locate the same file stored on multiple file 269 servers, or the same invoice stored in multiple accounting systems. It would enable program-

    270 matic querying, indexing, and manipulation of these resources to a much higher degree of

    271 precision that is available today through keyword and other natural language search techniques.

    272

    Context AContext BContext C

    ConcreteResource XResource XResource XInstances

    AbstractResource XIdentifier273

    274 Figure 6: Sharing an abstract identifier across multiple concrete contexts.

    275 Note that doing this in a uniform manner requires a URI syntax that permits combining an

    276 abstract resource identifier created in one context (e.g., a dictionary or taxonomy authority) with a

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 9 of 28

277 concrete identifier that establishes the local contextexactly like combining the term "President"

    278 with a concrete postal address. For example, an XRI representing a concept such as

    279 "management team" could be combined with the URI of a home page to form a well-known

    280 address for this type of resource on any corporate website. This would enable the development of

    281 much smarter and more specialized spiders than crawl the Web today.

    282 Providing a standard means for identifying the same abstract resource

    283 across different concrete contexts is a key motivation of the XRI effort.

    284 2.5 Resource Attribute and Version Identification

    285 A corollary to the need for cross-context identification is the need to establish the equivalence of

    286 different concrete resources that correspond to the same abstract resource identifier. This is the

    287 classic problem of consistency and data synchronization. Solving this problem in a general

    288 manner requires not only sharing the same identifier for the abstract resource as a whole, but: a)

    289 being able to identify the attributes of the resource down to the lowest level at which consistency

    290 is to be maintained, and b) being able to unambiguously identify each version of an attribute.

    291 A common example of this problem is the long-promised electronic business card. If an individual

    292 were to share copies of an electronic business card with 100 contacts, the same logical resource

    293 might be stored in 100 electronic address books somewhere on the network. If the owner of the

    294 business card updated a phone number, this new value would need to be synchronized with all

    295 100 copies. To do so at the level of the phone number attribute (rather than the entire business

    296 card) requires the ability to identify this specific attribute and version.

    297

    Context AContext B

    Resource XResource X

    Attribute Y v1Attribute Y v1

    Attribute Y v2298

    299 Figure 7: The need to standardize attribute and version identification. 300 RFC 2396 [URI] establishes a standard delimiter for addressing a fragment of a resource in a 301 URI using the # character. However it does not specify any syntax for expressing either nested

    302 attributes or versions. This requires that every web site adopts its own local convention for

    303 accomplishing this, a significant hindrance to interoperability when data sharing is desired.

    304 Providing a standard means for addressing attributes and versions of a

    305 resource is a key motivation of the XRI effort. 306 2.6 Delegation, Federation, and Extensibility

    307 The success of the IP addressing and DNS naming layers has been largely due to their

    308 delegation models. Each requires a minimum of centralized control and permits delegation of

    309 identifier authority to any depth. These same requirements must be extended to any abstract

    310 identifier layer designed for Internet-scale deployment.

    311

    xri-requirements-1.0-draft-06.doc 3 June 2003 Copyright ? OASIS Open 2003. All Rights Reserved. Page 10 of 28

Report this document

For any questions or suggestions please email
cust-service@docsford.com