LRDD Update (Resource Descriptor Discovery) and Proposed Changes

(LRDD and /host-meta were previously discussed on www-talk@w3.org. Moving forward, this discussion is being relocated to the IETF Application area discussion list. This will be indicated in future drafts.)

- A quick (re)introduction

I am working on a proposal called LRDD [1] which attempts to define how a descriptor (metadata, information about, etc.) can be attached or associated with a resource. LRDD, which stands for Link-based Resource Description Discovery (and pronounced 'lard') uses the Link Relation framework proposed by the Link Header draft [2]. LRDD does not define the document format of the descriptor itself, just how to obtain it if the URI of the resource is known. Existing descriptor formats include XRDS, XRD, POWDER, Metalink, etc.

As previously proposed, LRDD includes three methods for linking a resource (identified by a URI) to another resource which describes it:

1. HTTP Link: header
2. <LINK> element where supported (HTML, XTHML, ATOM)
3. Link-Pattern: records [3] in the proposed /host-meta well-known-location document [4]

The first two methods simply link to the location of the descriptor document from the resource itself (<LINK> element) or via the transport protocol used to retrieve it (HTTP Link: header). The third option provides a simple mechanism to map between the resource URI to the descriptor URI using a basic URI template syntax (removing the need to GET a representation of the resource or even have one available).

The obvious issue with regard to the third option is where to store the template used for mapping between resource URIs and descriptor URIs. What was previously proposed was to create a new well-known-location resource called /host-meta which will have a similar semantic meaning as an HTTP header for the abstract 'host' entity (the combination of domain and port). A long discussion of terms (host, site, origin, domain, etc.) was held on the Apps list [5]. A discussion about placing the mapping template in a DNS record did not mature into a proposal but is still desired by many people.

For a complete discussion of other (non link-based) methods considered see LRDD Appendix B: Methods Suitability Analysis [6].

- Proposed changes

Focusing on the third method using /host-meta, two separate discussions took place. The first was about the security of using a /host-meta file which can be easily created on many social networking sites by creating an account called 'host-meta' or on URI shortners [7]. The second was about the need in some use cases (namely OpenID) to sign the /host-meta document with some certificate to establish trust (this is part of a much bigger discussion but for the purpose of this thread, we can just assume that the document needs to be signed somehow).

These two discussions (and the focus on current use cases that are waiting for this to be resolved to move forward), has led to the following proposed changes:

* Introduce a new I-D called 'Well-Known' which will establish the path prefix /.well-known/ as a home for all future well-known-location solutions. We were already committing a namespace sin by curving out /host-meta as (yet) another well-known-location document so this will simply replace that with a path prefix and a lightweight registry for documents under that path. The main reason for this is that people are still concerned that a list registry under /host-meta will not be enough to deter future protocols from creating more well-known-location documents.

* Move /host-meta into this new /.well-known/ directory (http://example.com/.well-known/host-meta) and replace its text-based document format with XRD [8]. Since host-meta will no longer be needed as a generic link registry with the introduction of a well-known directory and registry, the only use case left for it is to store the URI template defined by LRDD. XRD already has a <URITemplate> element under <Link>, and will support document signatures (which is an important requirement for some use cases). Since most use cases at the moment will need to speak XRD anyway, and XRD is truly a lightweight schema, it makes sense to use it for host-meta instead of inventing another format just for that. We might drop the name host-meta altogether and name this XRD document under /.well-known/ something else.

- Next steps

* Submit a proposal for /.well-known as an I-D
* Publish the first committee draft (OASIS XRI TC) of XRD
* Update LRDD to use /.well-known and XRD as the third method instead of /host-meta

Both XRD and LRDD depend on the Link I-D to be published as RFC.

Any comments, feedback, or concerns are requested.

EHL

[1] http://tools.ietf.org/html/draft-hammer-discovery
[2] http://tools.ietf.org/html/draft-nottingham-http-link-header
[3] http://tools.ietf.org/html/draft-hammer-discovery-03#section-6
[4] http://tools.ietf.org/html/draft-nottingham-site-meta
[5] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00227.html
[6] http://tools.ietf.org/html/draft-hammer-discovery-03#appendix-B
[7] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00556.html
[8] http://www.hueniverse.com/hueniverse/2009/03/xrd-document-structure.html

Received on Thursday, 25 June 2009 18:31:15 UTC