idnits 2.17.1 draft-hammer-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 664 has weird spacing: '... scheme aut...' -- The document date (January 9, 2009) is 5557 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-' is mentioned on line 1094, but not defined == Outdated reference: A later version (-10) exists of draft-nottingham-http-link-header-03 == Outdated reference: A later version (-05) exists of draft-nottingham-site-meta-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Hammer-Lahav 3 Internet-Draft Yahoo! 4 Intended status: Informational January 9, 2009 5 Expires: July 13, 2009 7 HTTP-based Resource Descriptor Discovery 8 draft-hammer-discovery-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 13, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This memo describes an HTTP-based process for obtaining information 48 about a resource identified by a URI. The 'information about a 49 resource' - a resource descriptor - typically provides machine- 50 readable information that aims to assist and enhance the interaction 51 with the resource. This memo only defines the process for locating 52 and obtaining the descriptor, but leaves the descriptor format and 53 its interpretation out of scope. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Resource Discovery and Service Discovery . . . . . . . . . . . 3 61 5. Discovery Workflow . . . . . . . . . . . . . . . . . . . . . . 5 62 6. 'describedby' Link Relationship . . . . . . . . . . . . . . . 6 63 7. Method Selection . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. Obtaining Descriptor Location . . . . . . . . . . . . . . . . 9 65 8.1. Element . . . . . . . . . . . . . . . . . . . . . . 9 66 8.2. HTTP Link Header . . . . . . . . . . . . . . . . . . . . . 10 67 8.3. Site-Meta Document . . . . . . . . . . . . . . . . . . . . 11 68 8.3.1. Site-Wide Links . . . . . . . . . . . . . . . . . . . 12 69 8.3.2. Element . . . . . . . . . . . . . . . 12 70 8.3.3. DNS Verification for Non-HTTP(S) URIs . . . . . . . . 14 71 8.3.4. Method Workflow . . . . . . . . . . . . . . . . . . . 14 72 9. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 Appendix A. Method Suitability Analysis . . . . . . . . . . . 16 76 Appendix A.1. Requirements . . . . . . . . . . . . . . . . . . 16 77 Appendix A.2. Analysis . . . . . . . . . . . . . . . . . . . . 18 78 Appendix A.2.1. HTTP Response Header . . . . . . . . . . . . . . 18 79 Appendix A.2.2. HTTP Response Header Via HEAD . . . . . . . . . . 19 80 Appendix A.2.3. HTTP Content Negotiation . . . . . . . . . . . . 19 81 Appendix A.2.4. HTTP Header Negotiation . . . . . . . . . . . . . 20 82 Appendix A.2.5. Element . . . . . . . . . . . . . . . . . 21 83 Appendix A.2.6. HTTP OPTIONS Method . . . . . . . . . . . . . . . 22 84 Appendix A.2.7. WebDAV PROPFIND Method . . . . . . . . . . . . . 22 85 Appendix A.2.8. Custom HTTP Method . . . . . . . . . . . . . . . 23 86 Appendix A.2.9. Static Resource URI Transformation . . . . . . . 23 87 Appendix A.2.10. Dynamic Resource URI Transformation . . . . . . . 24 88 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . 25 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 This memo aims to provide a uniform and easily implementable process 97 for locating resource descriptors. With the development of 98 interoperability specifications comes the need to enable compliant 99 services and resources to declare their conformance to these 100 specifications. There is a growing need to describe resources in a 101 way that does not depend on their internal structure, or even the 102 availability of an HTTP-accessible representation of these resources. 104 For example, while an end-user is reading a web page such as a blog 105 article, the user-agent can discover whether the content of this page 106 has generated from an Atom feed or Atom entry and whether that feed 107 supports Atom authoring. It can discover whether there is an 108 iCalendar-formatted or CalDAV calendar associated with the page, or 109 where other content by the same page author might be found. 111 In an example related to the identity space, an end-user can use a 112 URI as an identifier for signing into web services, and in turn, the 113 web service can discover more information about the user's resources 114 and preferences such as who did the user delegate their identity 115 management to, where they keep their address book or list of social 116 network friends, where their profile information is stored to reduce 117 signup registration requirements, and what other services they use 118 which may enhance their interaction with the web service. 120 2. Notational Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Scope 128 The scope of this memo is intentionally restricted to locating 129 resource descriptors, leaving out their format. Given the wide range 130 of use cases and information that can be provided 'about a resource', 131 no single descriptor format can adequately accommodate all needs. 132 However, the process in which the desired descriptor is located 133 should be consistent across use cases and formats. 135 4. Resource Discovery and Service Discovery 137 Resource discovery provides a process for obtaining information about 138 a resource identified with a URI. It allows resource-providers to 139 describe their resources in a machine-readable format, enabling 140 automatic interoperability by user-agents and resource-consuming 141 applications. Discovery enables applications to utilize a wide range 142 of web services and resources across multiple providers without the 143 need to know about their capabilities in advance, reducing the need 144 for manual configuration and resource-specific software. 146 When discussing discovery, it is important to differentiate between 147 resource discovery and service discovery. Both types attempts to 148 associate capabilities with resources, but they approach it from 149 opposite ends. 151 Service discovery centers around identifying the location of 152 qualified resources, typically finding an endpoint capable of certain 153 protocols and capabilities. In contrast, resource discovery begins 154 with a resource, trying to find which capabilities it supports. 156 A simple way to distinguish between the two types of discovery is to 157 define the questions they are each trying to answer: 159 Resource-Discovery: Given a resource, what are its attributes: 160 capabilities, characteristics, and relationships to other 161 resources? 163 Service-Discovery: Given a set of attributes, which available 164 resources match the desired set and what is their location? 166 While this memo deals exclusively with resource discovery, it is 167 important to note that the two discovery types are closely related 168 and are usually used in tandem. In fact, a typical use case will 169 switch between service discovery and resource discovery multiple 170 times in a single workflow, and can start with either one. 172 One reason for this dependency between the two discovery types is 173 that resource descriptors usually contain not only a list of 174 capabilities, but also relationships to other resources. Since those 175 relationships are usually typed, the process in which an application 176 chooses which links to use is in fact service discovery. 178 Applications use resource discovery to obtain the list of links, and 179 service discovery to choose the relevant links. In another common 180 example, the application uses service discovery to find a resource 181 with a given capability, then uses resource discovery to find out 182 what other capabilities it supports. 184 Unless otherwise noted, the term 'discovery' is used in this memo to 185 mean resource discovery. 187 5. Discovery Workflow 189 Discovery can be performed before or after a resource is obtained. 190 Performing discovery ahead of accessing the resource allows a 191 resource-consumer to learn more about the properties of the resource. 192 For example, a consumer can learn about the protocols supported by 193 the resource and if understood, utilize them to interact with it. 195 In many cases, discovery is performed after the resource has been 196 obtained, based on the content of the resource and the way in which 197 the user-agent interacts with it (or based on human interactions). 198 Most web applications make strong assumptions about the resources 199 they interact with, mostly due to lack of a standard discovery 200 protocol for web resources. Such assumptions are not likely to 201 disappear even with the introduction of a discovery workflow. In 202 many cases, discovery will be used as a secondary step for enhancing 203 the interaction with a resource rather than the first step of 204 determining how to interact with it at all. 206 The focus of this memo is on the first step in discovery: identifying 207 the location of the resource descriptors. The overall discovery 208 workflow includes two additional steps: 210 1. The location of the resource descriptor document is obtained 211 using the resource URI. It does not matter how the resource URI 212 has been obtained, just that a URI is known. Once the descriptor 213 location has been identified, the descriptor document is 214 retrieved. 216 2. The resource descriptor document is parsed based on the 217 descriptor document format used. For example, two such formats 218 are POWDER (Protocol for Web Description Resources c) and XRD 219 (Extensible Resource Descriptor [XRD] [[replace with new XRD 220 specification reference]]). 222 3. The information about the resource contained within the 223 descriptor document is processed to find out its capabilities, 224 characteristics, and relationships to other resources. 225 Capabilities are usually described with identifiers or 226 description languages that the consuming application can match to 227 a database of known capabilities or process via an interpreter. 229 While the process described in this memo utilizes the HTTP protocol 230 [RFC2616] for locating descriptors, it can be used with any URI 231 scheme and is not limited to just the 'http' and 'https' URI schemes. 232 HTTP is an ideal framework for performing discovery activities on web 233 resources, but it does not clearly define a mechanism for attaching a 234 descriptor or metadata to a resource identified with a URI. 236 6. 'describedby' Link Relationship 238 The first step when performing discovery is to identify the location 239 of the resource descriptor document for the desired resource. This 240 can be simply described as a link between the URI of the resource and 241 the URI of the descriptor. Links are one of the most fundamental 242 building blocks of the web, and provide all that is necessary to 243 define the relationship between a resource and its descriptors. 245 The purpose of this memo is to define a consistent set of methods 246 using HTTP through which this link information is obtained when 247 performing discovery. The web provides a large number of methods for 248 defining links between resources, but in order to achieve 249 interoperability, the selection has to be narrowed down to a much 250 smaller set of options. 252 Since a single resource can have many descriptors, the descriptor 253 link relationship has a one-to-many structure. In the case of 254 multiple descriptors, selecting which descriptor to use is 255 application-specific. It can involve factors such as the descriptor 256 document format, accessibility, and other typed relationships, and as 257 such is beyond the scope of this memo. 259 All the methods described in this memo build directly on the typed- 260 relationships framework defined in [I-D.nottingham-http-link-header]. 261 The relationship type between a resource and its descriptor used for 262 discovery is 'describedby' which was originally defined by [POWDER] 263 as a generic relationship type as follows: 265 Relationship type: describedby 267 Purpose: To link a resource to a description that applies to that 268 resource 270 Documentation: http://www.w3.org/TR/powder-dr/#assoc-linking 272 Note: The relationship A 'describedby' B does not imply that B is 273 a POWDER file (the Media Type does that), simply that B provides a 274 description of A. This is the only constraint placed on A and B by 275 asserting the describedby relationship. 277 [[NOTE: the link type 'describedby' Link Relationship has been 278 submitted to IANA for review, approval, and inclusion in the Atom 279 Link Relations registry. The Atom Link Relations registry is 280 expected to be replaced by a generic Link Relations registry as 281 defined in [I-D.nottingham-http-link-header] section 4.2.]]. 283 For example, the following HTTP response header (fragment) returned 284 with the HTTP representation of the resource 285 http://example.com/resource/1: 287 HEAD /resource/1 HTTP/1.1 288 Server: example.com 290 Link: ; 291 rel="describedby"; type="application/xrd+xml" 293 defines a link between the resource http://example.com/resource/1 and 294 its descriptor located at http://example.com/resource/1;about and is 295 hinted to be using the XRD [XRD] document format. 297 The methods described in this memo all result in one or more link 298 relationships with type 'describedby'. Two out of the three methods 299 use existing link mechanisms as-is, by simply specifying the 300 relationship type used. The third defines a new mechanism for 301 dynamically constructing links using templates. 303 7. Method Selection 305 Due to the wide range of use cases requiring resource descriptors, 306 and the desire to reuse as much as possible, no single solution has 307 been found to sufficiently cover the requirements for linking between 308 the resource URI and the descriptor URI. An analysis of the 309 potential methods considered and the reason for their inclusion or 310 rejection can be found in Appendix A. A discussion regarding the 311 architectural issues around discovery can be found in [Uniform 312 Access]. 314 Obtaining the link information between the resource URI and the 315 descriptor URI is accomplished using one of three methods. The 316 criteria used to determine which methods a resource-provider SHOULD 317 support and resource-consumer SHOULD attempt to use are based on a 318 combination of factors: 320 o The document type of the available resource representation (text/ 321 html, application/atom+xml, image/png, unknown, etc.). 323 o The URI scheme (http, https, mailto, xmpp, etc.). 325 o The availability of an HTTP-accessible representation for the 326 resource (a representation of the resource that can be retrieved 327 using an HTTP GET request). 329 o The ability, desire, or applicability of the resource-consumer to 330 directly interact and retrieve a resource representation (which 331 might be unknown to it). 333 When selecting a method to use, the following requirement of each 334 method are considered (each method is described in details in 335 Section 8): 337 o Element: Limited to resources with an accessible markup 338 representation with direct support for typed-relationships using 339 the element, such as HTML [W3C.REC-html401-19991224] and 340 Atom [RFC4287]. Other document types are allowed as long as the 341 semantics of their element are fully compatible with the 342 link framework defined in [I-D.nottingham-http-link-header]. This 343 method requires full retrieval of the resource representation 344 before any discovery information about it is available. While 345 HTTP is the most common transport for HTML and Atom documents, 346 this method is transport independent. 348 o HTTP Link Header: Limited to resources with an accessible 349 representation using the HTTP protocol [RFC2616], or resources for 350 which an HTTP GET or HEAD request returns a valid HTTP response 351 header. This method uses the Link header defined in 352 [I-D.nottingham-http-link-header]. This method requires the 353 retrieval of the resource representation header (using an HTTP GET 354 or HEAD request). 356 o Site-Meta Document: A known-location based solution used for any 357 resources identified by a URI with a DNS-resolvable authority 358 component (i.e. an authority that can be directly mapped to an IP 359 address). This method uses the Site-Meta document defined in 360 [I-D.nottingham-site-meta]. This method does not require any 361 direct interaction with the resource. 363 The order in which the methods are listed is based on their 364 applicability specialization, from the most restrictive method to the 365 most generic method. This ordering however does not imply the order 366 in which multiple applicable methods should be attempted (which is 367 application specific). Because different methods are more 368 appropriate in different circumstances, all three methods described 369 are considered equal and can be attempted in any order. To ensure 370 interoperability, the following rules MUST be observed: 372 o Resource-providers MUST support at least one of the three methods 373 for each resource for which discovery information is to be made 374 available. If more than one method is supported, all methods MUST 375 produce the same resource descriptor location (either by returning 376 the same descriptor URI or a different descriptor URI that leads 377 to the same descriptor URI after following HTTP redirections). 379 o Resource-consumers SHOULD support all three methods and attempt 380 each in their preferred order until a descriptor URI is obtained 381 successfully. Resource-consumers SHOULD NOT attempt additional 382 methods after a previous method has concluded successfully. 384 8. Obtaining Descriptor Location 386 To obtain the location of the resource descriptor using the resource 387 URI, the resource-consumer SHALL proceed as follows: 389 1. Select one of the three methods as defined in Section 7. In many 390 cases, only some of the methods will be applicable. If more than 391 one method is available, the resource-consumer SHOULD pick the 392 method most efficient for its needs. 394 2. Perform the steps described below for the selected method. If 395 successful, the method will produce the descriptor location. If 396 the method fails, repeat the process from the previous step by 397 selecting another method. If no method is left, the discovery 398 process fails. 400 3. Once the desired descriptor URI has been obtained, the descriptor 401 document is obtained via an HTTP GET request to the identified 402 URI. The resource-consumer MUST obey all HTTP 301 and 302 403 redirects and the descriptor document is considered valid only if 404 contained within an HTTP response with the HTTP 200 response 405 code. 407 8.1. Element 409 Resources with an HTML [W3C.REC-html401-19991224] or an Atom 410 [RFC4287] representations MAY include a element with the 411 'describedby' relationship type to link between the resource and its 412 descriptor. 414 For example: 416 419 A resource-consumer trying to obtain the location of the resource's 420 descriptor using this method SHALL: 422 1. Retrieve a valid representation of the resource using the 423 applicable transport for that resource URI. If the resource 424 representation is obtained using HTTP, the resource-consumer MUST 425 only use it if the HTTP response containing the representation 426 carries a valid HTTP 200 response code. If any other response 427 code is returned, the method fails. [[This is written 428 specifically about the request producing the representation, 429 ignoring any potential redirects that might have occurred prior. 430 Should redirects be explicitly mentioned here?]] 432 2. Parse the document as defined by the document specification and 433 look for elements with a 'rel' attribute value containing 434 the 'describedby' relationship (a multiple relationship 'rel' 435 attribute value is allowed and MUST be handled by the consumer, 436 for example 'rel="describedby copyright"'). 438 3. The resource-consumer SHOULD examine any available 'type' 439 attributes as hints for the document format used by the 440 descriptor document. If more than one link is found, the 441 descriptor mime-type SHOULD be used to narrow down the selection. 443 4. The descriptor location is obtained from the value of the 'href' 444 attribute on the selected element. 446 8.2. HTTP Link Header 448 Resources with an accessible HTTP representation MAY include a Link 449 header in the HTTP response header as defined by 450 [I-D.nottingham-http-link-header] with a 'rel' parameter value set to 451 'describedby'. 453 For example: 455 Link: ; rel="describedby"; 456 type="application/powder+xml" 458 A resource-consumer trying to obtain the location of the resource's 459 descriptor using this method SHALL: 461 1. Retrieve a valid HTTP response header for the representation of 462 the resource using an HTTP GET or HEAD request. The resource- 463 consumer MUST follow HTTP redirections 301 and 302. The 464 resulting header MUST only be used for the purpose of discovery 465 if the HTTP response containing the header has one of the 466 following HTTP response codes: 200, 303, and 401. If any other 467 response code is returned, the method fails. 469 2. Parse the HTTP response header and look for a Link header with a 470 'rel' parameter value containing the 'describedby' relationship 471 (a multiple relationship 'rel' parameter value is allowed and 472 MUST be handled by the consumer, for example 'rel="describedby 473 copyright";'). 475 3. The resource-consumer SHOULD examine any available 'type' 476 parameters as hints for the document format used by the 477 descriptor document. If more than one link is found, the 478 descriptor mime-type SHOULD be used to narrow down the selection. 480 4. The descriptor location is obtained from the URI-reference 481 locating between the '<>' characters of the selected Link header. 483 If the HTTP response code is 303, any descriptor location is defined 484 to be between the requested resource and the descriptor and not 485 between the 'See other' resource indicated by a Location header. If 486 the response code is 401, any descriptor location MUST only be used 487 in association with obtaining access to the resource, which once 488 obtained, must be queried again for its descriptor location which MAY 489 be different from the unauthorized response. 491 8.3. Site-Meta Document 493 The descriptor location of resources identified with a URI which 494 contains a DNS-resolvable authority component MAY be obtained from 495 the Site-Meta document [I-D.nottingham-site-meta] via a templatized 496 map used to transform the resource URI to the descriptor URI. The 497 templatized link is provided by an extension (defined by this memo) 498 to the Site-Meta schema for describing link templates. Using a 499 template provided by Site-Meta for URIs under its authority, a 500 resource URI can be deconstructed and then reconstructed to form the 501 URI of the descriptor location. 503 For example, given the resource identified by http://example.com/r/1, 504 the Site-Meta document for its authority example.com is obtained from 505 http://example.com/site-meta. The Site-Meta document defines a 506 template in which the resource URI is converted to the descriptor URI 507 by appending ';about' to the URI: 509 510 513 515 resulting in the descriptor location URI 516 http://example.com/r/1;about. 518 8.3.1. Site-Wide Links 520 Site-Meta defines a method for locating site-wide metadata for web 521 sites. Its primary objective is to avoid the need of further known- 522 location solutions by creating one last such resource which can point 523 to other resources. It can be considered a registry for "known- 524 location" resources to avoid further intrusion into the site's naming 525 authority, hopefully the last such resource. 527 In the context of discovery, Site-Meta offers a convenient location 528 for storing information about how to map between resource URIs and 529 their descriptor URIs at an authority level. Site-Meta provides a 530 method for obtaining descriptor locations that does not depend on the 531 availability of an HTTP representation (or 303 See Other response) 532 for resources. It can also, with an additional authority 533 verification step (described in Section 8.3.3), provide descriptor 534 locations for URIs with schemes other than 'http' and 'https'. 536 The elements defined by Site-Meta are meant to contain site-wide 537 information. Unlike Link headers included in the HTTP response to 538 requests for the domain root resource (obtained via 'GET / HTTP/1.1' 539 or 'HEAD / HTTP/1.1') which are specific to the root resource, links 540 in Site-Meta are between the abstract 'web site' entity and the 541 linked resources. It is critical not to confuse the root resource of 542 a domain authority with the abstract 'web site' entity described by 543 Site-Meta. 545 For this reason, any elements containing linked resources with 546 relationship type 'describedby', identify the location of the 547 abstract 'web site' entity description which by itself cannot be 548 described using a URI. While this is a valid application of the 549 'describedby' relationship type, it is beyond the scope of this memo. 551 8.3.2. Element 553 The element is defined as a child of the root 554 element and identical to the Site-Meta element with 555 the following differences: 557 o It cannot contain any value or child elements and must be self- 558 closing. 560 o The 'href' attribute in the element is replaced by the 561 'template' attribute. 563 o The OPTIONAL 'scheme' attribute is added. 565 o The resulting relationship is defined as between the individual 566 resource used as an input to the template and the resulting 567 descriptor URI, and do not in relation to the abstract 'web site' 568 entity. 570 The 'scheme' attribute serves as a filter indicating which URI scheme 571 are meant to be transformed using the provided template. This 572 OPTIONAL attribute is meant to allow different handling of different 573 URI schemes. The attribute value is a space separated list of 574 lowercase scheme names. If omitted, the template is meant to be 575 applied to any URI schemes. 577 The 'template' attribute defines a URI template with a very simple 578 syntax. The attribute value is used to construct a valid URI by 579 substituting the variable enclosed in '{}' with the value of the 580 variable. 582 In the example above, the 'uri' variable is replaced with the actual 583 resource URI (the resource URI http://example.com replaces the 584 '{uri}' string which results in http://example.com;about). If the 585 variable name is prefixed by a '%' character, any character other 586 than unreserved in variable value MUST be percent-encoded per 587 [RFC3986]. 589 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 591 For example, the following template when used with the resource URI 592 http://example.com: 594 595 599 601 produces the descriptor URI: 602 http://example.com?describe=http%3A%2F%2Fexample.com. 604 [[This initial draft only defines a single 'uri' variable. However, 605 it is expected that future revision will define a larger template 606 vocabulary which will be based on the URI structure definition and 607 include: uri, scheme, authority, domain, port, path, query, fragment, 608 and username (for 'mailto' URIs).]] 610 [[Site-Meta is pending a major revision of its document format which 611 is likely to replace its XML structure with a simpler text based 612 structure. This memo will be revised as soon as the new Site-Meta 613 draft is published to reflect these changes. However, the changes 614 are expected to only change the document formatting.]] 616 8.3.3. DNS Verification for Non-HTTP(S) URIs 618 Site-Meta uses the HTTP protocol for providing metadata about the 619 abstract 'web site' entity. This raises the issue whether an HTTP 620 server can speak authoritatively for a non-HTTP resource, namely, a 621 resource identified by a URI with a scheme other than 'http' or 622 'https'. 624 From a deployment perspective, many organizations separate the 625 administration responsibilities of their HTTP resources from other 626 resources such as email (SMTP) or instant messaging (XMPP). It would 627 be an unexpected behavior in such organizations if the HTTP server 628 provides authoritative information about identifiers belonging to 629 other departments. 631 The process defined in this memo was design with ease of deployment 632 as one of its top priorities. Since it is unlikely that protocols 633 such as SMTP will introduce their own discovery extensions (which 634 will realize any significant deployment in the foreseeable future), 635 Site-Meta must be able to provide authoritative information regarding 636 the descriptor location of non-HTTP(S) resources. 638 To obtain such authority, the owner of the domain (as represented by 639 the administrator of its DNS records) MUST declare that Site-Meta is 640 indeed allowed to provide such information. To do so, the domain DNS 641 records MUST include, for each domain or sub-domain for which the 642 HTTP server has such authority, a TXT record with the exact value of 643 '/site-meta non-http delegation enabled'. [[The DNS record type and 644 value are included in this draft only as a straw man proposal and are 645 likely to change based on feedback received from the DNS community. 646 Proposals for such record are requested.]] 648 Resource-consumers MUST verify the existence of such DNS record 649 before obtaining and utilizing the Site-Meta document for the 650 discovery of non-HTTP(S) resources. If no such record is found, the 651 method fails. 653 8.3.4. Method Workflow 655 A resource-consumer trying to obtain the location of the resource's 656 descriptor using this method SHALL: 658 1. Examine the resource URI and extract its authority component as 659 defined by [RFC3986] section 3: 661 foo://example.com:8042/over/there?name=ferret#nose 662 \_/ \______________/\_________/ \_________/ \__/ 663 | | | | | 664 scheme authority path query fragment 666 If the authority contains an '@' character, the '@' character and 667 everything to its left is removed. For example, in the URI 668 mailto:username@example.com the authority component 669 username@example.com is stripped of the '@' character and the 670 characters to its left, leaving example.com as the extracted 671 authority value used in follow-up steps. 673 2. If the URI scheme being discovered is not 'http' or 'https', the 674 resource-consumer MUST perform DNS verification as described in 675 Section 8.3.3 to ensure that the HTTP protocol service for that 676 domain has the authority to relay discovery location for other 677 schemes. 679 3. Retrieve the Site-Meta document for the extracted authority as 680 defined by [I-D.nottingham-site-meta] section 4, by making an 681 HTTP GET request: 683 GET /site-meta HTTP/1.1 684 Host: example.com 686 If the request fails to retrieve a valid Site-Meta document, the 687 method fails. [[Should the method require the use of HTTPS when 688 retrieving the Site-Meta document when performing discovery on 689 'https' scheme URIs?]] 691 4. Parse Site-Meta document and look for elements 692 with a 'rel' attribute value containing the 'describedby' 693 relationship (a multiple relationship 'rel' attribute value is 694 allowed and MUST be handled by the consumer, for example 695 'rel="describedby copyright"'). 697 5. The resource-consumer SHOULD examine any available 'type' 698 attributes as hints for the document format used by the 699 descriptor document. If more than one link template is found, 700 the descriptor mime-type SHOULD be used to narrow down the 701 selection. 703 6. The descriptor location is constructed by applying the template 704 obtained from the 'template' attribute of the selected element on the resource URI. 707 9. Caching 709 Resource-consumers MUST obey all HTTP caching headers and directives 710 and discard any cached descriptor location as defined by the 711 resource-provider. The ability to cache descriptor locations was a 712 key requirement in selecting which methods to include in the 713 discovery workflow. It is critical that such information is cached 714 as defined by HTTP. 716 10. Security Considerations 718 The methods used to perform discovery are not secure, private or 719 integrity-guaranteed, and due caution should be exercised when using 720 them. Applications that perform discovery should consider the attack 721 vectors opened by automatically following, trusting, or otherwise 722 using links gathered from elements, HTTP Link headers, or 723 Site-Meta documents. 725 11. IANA Considerations 727 This memo includes no request to IANA. The relationship type 728 'describedby' used by this memo is pending approval by the IANA and 729 must be fully registered before this memo can become final. If for 730 any reason the 'describedby' relationship type fails to register with 731 the IANA, it is expected that this memo will define a new 732 relationship type. 734 Appendix A. Method Suitability Analysis 736 The following analysis attempts to list all the method proposed for 737 addressing resource discovery. It has been previously published as 738 an article at [Discovery and HTTP] and is included here to provide 739 background information as to why certain methods have been selected 740 while others rejected from the discovery process. It has been 741 updated to match the terms used in this memo and its structure. 743 Appendix A.1. Requirements 745 Getting from a resource URI to its descriptor document can be 746 implemented in many ways. The problem is that none of the current 747 methods address all of the requirements presented by the common use 748 cases. The requirements are simple, but the more we try to address, 749 the less elegant and accessible the process becomes. While working 750 on the now defunct XRDS-Simple specification [XRDS-Simple] and 751 talking to companies and individual about it, the following 752 requirements emerged for any proposed process: 754 Self Declaration: 756 Allow resources to declare the availability of descriptor 757 information and its location. When a resource is accessed, it 758 needs to have a way to communicate to the resource-consumer 759 that it supports the discovery protocol and to indicates the 760 location of such descriptor. 762 This is useful when the consumer is able or is already 763 interacting with the resource but can enhance its interaction 764 with additional information. For example, accessing a blog 765 page enhanced if it was generated from an Atom feed or Atom 766 entry and that feed supports Atom authoring. 768 Direct Descriptor Access: 770 Enable direct retrieval of the resource descriptor without 771 interacting with the resource itself. Before a resource is 772 accessed, the resource-consumer should have a way to obtain the 773 resource descriptor without accessing the resource. This is 774 important for two reasons. 776 First, accessing an unknown resource may have undesirable 777 consequences. After all, the information contained in the 778 descriptor is supposed to inform the consumer how to interact 779 with the resource. The second is efficiency - removing the 780 need to first obtain the resource in order to get its 781 descriptor (reducing HTTP round-trips, network bandwidth, and 782 application latency). 784 Web Architecture Compliant: 786 Work with well-established web infrastructure. This may sound 787 obvious but it is in fact the most complex requirement. 788 Deploying new extensions to the HTTP protocol is a complicated 789 endeavor. Beside getting applications to support a new header, 790 method, or content negotiation, existing caches and proxies 791 must be enhanced to properly handle these requests, and they 792 must not fail performing their normal duties without such 793 enhancements. 795 For example, a new content negotiation method may cause an 796 existing cache to serve the wrong data to a non-discovery 797 consumer due to its inability to distinguish the metadata 798 request from the resource representation request. 800 Scale and Technology Agnostic: 802 Support large and small web providers regardless of the size of 803 operations and deployment. Any solution must work for a small 804 hosted web site as well as the world largest search engine. It 805 must be flexible enough to allow developers with restricted 806 access to the full HTTP protocol (such as limited access to 807 request or response headers) to be able to both provide and 808 consume resource descriptors. Any solution should also support 809 caching as much as possible and allow reuse of source code and 810 data. 812 Extensible: 814 Accommodate future enhancements and unknown descriptor formats. 815 It should support the existing set of descriptor formats such 816 as XRD and POWDER, as well as new descriptor relationships that 817 might emerge in the future. In addition, the solution should 818 not depend on the descriptor format itself and work equally 819 well with any document format - it should aim to keep the road 820 and destination separate. 822 Appendix A.2. Analysis 824 The following is a list of proposed and implemented methods trying to 825 address resource discovery. Each method is reviewed for its 826 compliance with the requirements identified previously. The [-], 827 [+], or [+-] symbols next to each requirement indicate how well the 828 method complies with the requirement. 830 Appendix A.2.1. HTTP Response Header 832 When a resource representation is retrieved using and HTTP GET 833 request, the server includes in the response a header pointing to the 834 location of the descriptor document. For example, POWDER uses the 835 'Link' response header to create an association between the resource 836 and its descriptor. XRDS [XRDS] (based on the Yadis protocol 837 [Yadis]) uses a similar approach, but since the Link header was not 838 available when Yadis was first drafted, it defines a custom header 839 X-XRDS-Location which serves a similar but less generic purpose. 841 [+] Self Declaration - using the Link header, any resource can point 842 to its descriptor documents. 844 [-] Direct Descriptor Access - the header is only accessible when 845 requesting the resource itself via an HTTP GET request. While 846 HTTP GET is meant to be a safe operation, it is still possible for 847 some resource to have side-effects. 849 [+] Web Architecture Compliant - uses the Link header which is an 850 IETF Internet Standard [[Currently a standard-track draft]], and 851 is consistent with HTTP protocol design. 853 [-] Scale and Technology Agnostic - since discovery accounts for a 854 small percent of resource requests, the extra Link header is 855 wasteful. For some hosted servers, access to HTTP headers is 856 limited and will prevent implementation. 858 [+] Extensible - the Link header provides built-in extensibility by 859 allowing new link relationships, mime-types, and other extensions. 861 Minimum roundtrips to retrieve the resource descriptor: 2 863 Appendix A.2.2. HTTP Response Header Via HEAD 865 Same as the HTTP Response Header method but used with an HTTP HEAD 866 request. The idea of using the HEAD method is to solve the wasteful 867 overhead of including the Link header in every reply. By limiting 868 the appearance of the Link header only to HEAD responses, typical GET 869 requests are not encumbered by the extra bytes. 871 [+] Self Declaration - Same as the HTTP Response Header method. 873 [-] Direct Descriptor Access - Same as the HTTP Response Header 874 method. 876 [-] Web Architecture Compliant - HTTP HEAD should return the exact 877 same response as HTTP GET with the sole exception that the 878 response body is omitted. By adding headers only to the HEAD 879 response, this solution violates the HTTP protocol and might not 880 work properly with proxies as they can return the header of the 881 cached GET request. 883 [+] Scale and Technology Agnostic - solves the wasted bandwidth 884 associated with the HTTP Response Header method, but still suffers 885 from the limitation imposed by requiring access to HTTP headers. 887 [+] Extensible - Same as the HTTP Response Header method. 889 Minimum roundtrips to retrieve the resource descriptor: 2 891 Appendix A.2.3. HTTP Content Negotiation 893 Using the Accept request header, the consumer informs the server it 894 is interested in the descriptor and not the resource itself, to which 895 the server responds with the descriptor document or its location. In 896 Yadis, the consumer sends an HTTP GET (or HEAD) request to the 897 resource URI with an Accept header and content-type application/ 898 xrds+xml. This informs the server of the consumer's discovery 899 interest, which in turn may reply with the descriptor document 900 itself, redirect to it, or return its location via the X-XRDS- 901 Location response header. 903 [-] Self Declaration - does not address as it focuses on the 904 consumer declaring its intentions. 906 [+] Direct Descriptor Access - provides a simple method for directly 907 requesting the descriptor document. 909 [-] Web Architecture Compliant - while it can be argued that the 910 descriptor can be considered another representation of the 911 resource, it is very much external to it. Using the Accept header 912 to request a separate resource (as opposed to a different 913 representation of the same resource) violates web architecture. 914 It also prevents using the discovery content-type as a valid 915 (self-standing) web resource having its own descriptor. 917 [-] Scale and Technology Agnostic - requires access to HTTP request 918 and response headers, as well as the registration of multiple 919 handlers for the same resource URI based on the Accept header. In 920 addition, improper use or implementation of the Vary header in 921 conjunction with the Accept header will cause caches to serve the 922 descriptor document instead of the resource itself - a great 923 concern to large providers with frequently visited front-pages. 925 [-] Extensible - applies an implicit relationship type to the 926 descriptor mime-type, limiting descriptor formats to a single 927 purpose. It also prevents using existing mime-types from being 928 used as a descriptor format. 930 Minimum roundtrips to retrieve the resource descriptor: 1 932 Appendix A.2.4. HTTP Header Negotiation 934 Similar to the HTTP Content Negotiation method, this solution uses a 935 custom HTTP request header to inform the server of the consumer's 936 discovery intentions. The server responds by serving the same 937 resource representation (via an HTTP GET or HEAD requests) with the 938 relevant Link headers. It attempts to solve the HTTP Response Header 939 waste issue by allowing the consumer to explicitly request the 940 inclusion of Link headers. One such header can be called 'Request- 941 links' to inform the server the consumer would like it to include 942 certain Link headers of a given 'rel' type in its reply. 944 [+] Self Declaration - same as HTTP Response Header with the option 945 of selective inclusion. 947 [-] Direct Descriptor Access - does not address. 949 [-] Web Architecture Compliant - HTTP does not include any mechanism 950 for header negotiation and any custom solution will break existing 951 caches. 953 [+-] Scale and Technology Agnostic - Requires advance access to HTTP 954 headers on both the consumer and provider sides, but solves the 955 bandwidth waste issue of the HTTP Response Header method. 957 [+] Extensible - builds on top of Link header extensibility. 959 Minimum roundtrips to retrieve the resource descriptor: 2 961 Appendix A.2.5. Element 963 Embeds the location of the descriptor document within the resource 964 representation by leveraging the HTML header element (as 965 opposed to the HTTP header). Applies to HTML resource 966 representations or similar markup-based formats with support for 967 'Link'-like elements such as Atom. POWDER uses the element in 968 this manner, while XRDS uses the HTML element with an 'http- 969 equiv' attribute equals to X-XRDS-Location (to create an embedded 970 version of the X-XRDS-Location custom header). 972 [+] Self Declaration - similar to HTTP Response Header method but 973 limited to HTML resources. 975 [-] Direct Descriptor Access - the method requires fetching the 976 entire resource representation in order to obtain the descriptor 977 location. In addition, it requires changing the resource HTML 978 representation which makes discovery an intrusive process. 980 [+] Web Architecture Compliant - uses the element as 981 designed. 983 [+] Scale and Technology Agnostic - while this solution requires 984 direct retrieval of the resource and manipulation of its content, 985 it is extremely accessible in many platforms. 987 [-] Extensible - extensibility is restricted to HTML representations 988 or similar markup formats with support for a similar element. 990 Minimum roundtrips to retrieve the resource descriptor: 2 992 Appendix A.2.6. HTTP OPTIONS Method 994 The HTTP OPTIONS method is used to interact with the HTTP server with 995 regard to its capabilities and communication-related information 996 about its resources. The OPTIONS method, together with an optional 997 request header, can be used to request both the descriptor location 998 and descriptor content itself. 1000 [-] Self Declaration - does not address. 1002 [+] Direct Descriptor Access - provides a clean mechanism for 1003 requesting descriptor information about a resource without 1004 interacting with it. 1006 [+] Web Architecture Compliant - uses an existing HTTP featured. 1008 [-] Scale and Technology Agnostic - requires consumer and provider 1009 access to the OPTIONS HTTP method. Also does not support caching 1010 which makes this solution inefficient. 1012 [+] Extensible - built-into the OPTIONS method. 1014 Minimum roundtrips to retrieve the resource descriptor: 1 1016 Appendix A.2.7. WebDAV PROPFIND Method 1018 Similar to the HTTP OPTIONS method, the WebDAV PROPFIND method 1019 defined in [RFC4918] can be used to request resource specific 1020 properties, one of which can hold the location of the descriptor 1021 document. PROPFIND, unlike OPTIONS, cannot return the descriptor 1022 itself, unless it is returned in the required PROPFIND schema (a 1023 multi-status XML element). Other alternatives include URIQA [URIQA], 1024 an HTTP extension which defines a method called MGET, and ARK 1025 (Archival Resource Key) [ARK] - a method similar to PROPFIND that 1026 allows the retrieval of resource attributes using keys (which 1027 describe the resource). 1029 [-] Self Declaration - does not address. 1031 [+-] Direct Descriptor Access - does not require interaction with 1032 the resource, but does require at least two requests to get the 1033 descriptor (get location, get document). 1035 [+] Web Architecture Compliant - uses an HTTP extension with less 1036 support than core HTTP, but still based on published standards. 1038 [-] Scale and Technology Agnostic - same as the HTTP OPTIONS Method. 1040 [+-] Extensible - uses extensible protocols but at the same time 1041 depends on solutions that have already gone beyond the standard 1042 HTTP protocol, which makes further extensions more complex and 1043 unsupported. 1045 Minimum roundtrips to retrieve the resource descriptor: 2 1047 Appendix A.2.8. Custom HTTP Method 1049 Similar to the HTTP OPTIONS Method, a new method can be defined (such 1050 as DISCOVER) to return (or redirect to) the descriptor document. The 1051 new method can allow caching. 1053 [-] Self Declaration - does not address. 1055 [+] Direct Descriptor Access - same as the HTTP OPTIONS Method. 1057 [-] Web Architecture Compliant - depends heavily on extending every 1058 platform to support the extension. Unlikely to be supported by 1059 existing proxy services and caches. 1061 [-] Scale and Technology Agnostic - same as HTTP OPTIONS Method with 1062 the additional burden on smaller sites requiring access to the new 1063 protocol. 1065 [+] Extensible - new protocol that can extend as needed. 1067 Minimum roundtrips to retrieve the resource descriptor: 1 1069 Appendix A.2.9. Static Resource URI Transformation 1071 Instead of using HTTP facilities to access the descriptor location, 1072 this method defines a template to transform any resource URI to the 1073 descriptor document URI. This can be done by adding a prefix or 1074 suffix to the resource URI, which turns it into a new resource URI. 1075 The new URI points to the descriptor document. For example, to fetch 1076 the descriptor document for http://example.com/resource, the consumer 1077 makes an HTTP GET request to http://example.com/resource;about using 1078 a static template that adds the ';about' suffix. 1080 [-] Self Declaration - does not address. 1082 [+] Direct Descriptor Access - creates a unique URI for the 1083 descriptor document. 1085 [+-] Web Architecture Compliant - uses basic HTTP facilities but 1086 intrudes on the domain authority namespace as it defines a static 1087 template for URI transformation that is not likely to be 1088 compatible with many existing URI naming conventions. 1090 [+-] Scale and Technology Agnostic - depending on the static mapping 1091 chosen. Some hosted environment will have a problem gaining 1092 access to the mapped URI based on the URI format chosen. 1094 [-] Extensible - provides a very specific and limited method to map 1095 between resources and their descriptor, since each relationship 1096 type must mint its own static template. 1098 Minimum roundtrips to retrieve the resource descriptor: 1 1100 Appendix A.2.10. Dynamic Resource URI Transformation 1102 Same as the Static Resource URI Transformation method but with the 1103 ability for each domain authority to specify its own discovery 1104 transformation template. This can done by placing a configuration 1105 file at a known location (such as robots.txt) which contains the 1106 template needed to perform the URL mapping. The consumer first 1107 obtains the configuration document (which may be cached using normal 1108 HTTP facilities), parses it, then uses that information to transform 1109 the resource URI and access the descriptor document. 1111 [+-] Self Declaration - does not address individual resources, but 1112 allows entire domains to declare their support (and how to use 1113 it). 1115 [+-] Direct Descriptor Access - once the mapping template has been 1116 obtained, descriptors can be accessed directly. 1118 [+-] Web Architecture Compliant - uses an existing known-location 1119 design pattern (such as robots.txt) and standard HTTP facilities. 1120 The use of a known-location if not ideal and is considered a 1121 violation of web architecture but if it serves as the last of its 1122 kind, can be tolerated. An alternative to the known-location 1123 approach can be using DNS to store either the location of the 1124 mapping or the map template itself, but DNS adds a layer of 1125 complexity not always available. 1127 [+-] Scale and Technology Agnostic - works well at the URI authority 1128 level (domain) but is inefficient at the URI path level (resource 1129 path) and harder to implement when different paths within the same 1130 domain need to use different templates. With the decreasing cost 1131 of custom domains and sub-domains hosting, this will not be an 1132 issue for most services, but it does require sharing configuration 1133 at the domain/sub-domain level. 1135 [+-] Extensible - can be, depending on the schema used to format the 1136 known-location configuration document. 1138 Minimum roundtrips to retrieve the resource descriptor: initially 2, 1139 1 after caching 1141 Appendix B. Acknowledgments 1143 With the exception of the Site-Meta template extension, very little 1144 of this memo is original work. Many communities and individuals have 1145 been working on solving discovery for many years and this work is a 1146 direct result of their hard and dedicated efforts. 1148 Inspiration for this memo derived from previous work on a descriptor 1149 format called XRDS-Simple, which in turn derived from another 1150 descriptor format, XRDS. Previous discovery workflows include Yadis 1151 which is currently used by the OpenID community. While suffering 1152 from significant shortcomings, Yadis was a breakthrough approach to 1153 performing discovery using extremely restricted hosting environments, 1154 and this memo has strived to preserve as much of that spirit as 1155 possible. 1157 The use of Link elements and headers and the introduction of the 1158 'describedby' relationship type in this memo is a direct result of 1159 the dedicated work and contribution of Phil Archer to the W3C POWDER 1160 specification and Jonathan Rees to the W3C review of Uniform Access 1161 to Information About. The Site-Meta approach was first proposed by 1162 Mark Nottingham as an alternative to attaching links directly to 1163 resource representations. 1165 The author wishes to thanks the OASIS XRI community for their 1166 support, encouragement, and enthusiasm for this work. Special thanks 1167 go to Lisa Dusseault, Mark Nottingham, Drummond Reed, John Panzer, 1168 and Joseph Holsten for their invaluable feedback. 1170 The author takes all responsibility for errors and omissions. 1172 12. References 1174 12.1. Normative References 1176 [I-D.nottingham-http-link-header] 1177 Nottingham, M., "Link Relations and HTTP Header Linking", 1178 draft-nottingham-http-link-header-03 (work in progress), 1179 November 2008. 1181 [I-D.nottingham-site-meta] 1182 Nottingham, M. and E. Hammer-Lahav, 1183 "draft-nottingham-site-meta-00", 1184 draft-nottingham-site-meta-00 (work in progress), 1185 October 2008. 1187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, March 1997. 1190 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1191 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1192 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1194 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1195 Resource Identifier (URI): Generic Syntax", STD 66, 1196 RFC 3986, January 2005. 1198 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1199 Syndication Format", RFC 4287, December 2005. 1201 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 1202 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1204 [W3C.REC-html401-19991224] 1205 Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 1206 Specification", World Wide Web Consortium 1207 Recommendation REC-html401-19991224, December 1999, 1208 . 1210 12.2. Informative References 1212 [ARK] Kunze, J. and R. Rodgers, "The ARK Identifier Scheme", 1213 . 1215 [Discovery and HTTP] 1216 Hammer-Lahav, E., "Discovery and HTTP", . 1220 [POWDER] Archer, P., Ed., Smith, K., Ed., and A. Perego, Ed., 1221 "POWDER: Protocol for Web Description Resources", 1222 . 1224 [URIQA] Nokia, "The URI Query Agent Model", 1225 . 1227 [Uniform Access] 1228 Rees, J., "Uniform Access to Information About", 1229 . 1231 [XRD] Hammer-Lahav, E., Ed., "XRD 1.0". 1233 [XRDS] Wachob, G., Reed, D., Chasen, L., Tan, W., and S. 1234 Churchill, "Extensible Resource Identifier (XRI) 1235 Resolution V2.0", . 1238 [XRDS-Simple] 1239 Hammer-Lahav, E., "XRDS-Simple 1.0", 1240 . 1242 [Yadis] Miller, J., "Yadis Specification 1.0", 1243 . 1245 Author's Address 1247 Eran Hammer-Lahav 1248 Yahoo! 1250 Email: eran@hueniverse.com 1251 URI: http://hueniverse.com