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