Discovery Coordination Report, Dec 5th 2008

Eran Hammer-Lahav eran at hueniverse.com
Fri Dec 5 21:04:38 UTC 2008


[Originally posted to the Metadata Discovery Coordination Group]


* Link Relations and HTTP Header Linking

Document: http://tools.ietf.org/html/draft-nottingham-http-link-header-03
Author: Mark Nottingham
List: ietf-http-wg at w3.org
Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/
Org: IETF

The Link draft revives the RFC 2068 Link header, as well as attempts to standardize link relationships between HTTP, HTML, and ATOM. The recently published revision of the spec switched the focus from the HTTP Link header to 'typed link relationships'. The new draft inspired an active debate on the list with focus on the following topics:

- Relationship between 'rel' and 'rev' and their semantic meaning
- The authoritative nature of the Link header and various attributes
- The context of the link to be between 'representation->resource' or 'resource->resource' (or even 'representation->representation')

The link concept is the most fundamental building block for discovery. With the draft taking a wider focus on typed links in general, not just the HTTP header, this work is now positioned as the centerpiece of the discovery discussion. A -04 draft is expected soon.


* /site-meta: Site-Wide Metadata for the Web

Document: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt
Authors: Mark Nottingham, Eran Hammer-Lahav
List: www-talk at w3.org
Archive: http://lists.w3.org/Archives/Public/www-talk/
Org: IETF

/site-meta provides a known-location-based solution for providing site-wide metadata. In practice this translate into a list of links for a given website at the authority level (domain name). Some view this solution as a registry to avoid new known-location solution by creating one final known-location document.

The /site-meta proposal came out of multiple discussions and as a result of trying to solve the 'dynamic mapping' option explained in 'Discovery and HTTP' [1]. Dynamic mapping is the idea of proving a map or template that can transform a resource URI to its descriptor URI. A map is simply a template-based link where the linked resource URI is generated using a template language instead of being explicitly specified. The overall idea is tightly coupled with typed links.

The discussion about /site-meta is currently focused on:

- The authority an HTTP server in general and /site-meta in particular have to provide descriptors/metadata about non-HTTP URIs. This is related to the OpenID use case of wanting to use email addresses (mailto URIs) as identity identifiers which requires a way to obtain a resource descriptor (currently OpenID uses the XRDS format) from a non-HTTP URI.
- The document format of /site-meta. The -00 draft defines a new and very simple XML-based schema. A proposal has been made to use a simple one-link-per-line text format instead.
- The mechanism in which /site-meta will support URI templates (template-based links). The discussion is in its early stage and will focus on whether /site-meta should allow such links (at all), simply enable the use case through future extensions (not prevent it), or directly address the use case.
- Should there be a fallback mechanism when failing to obtain the /site-meta document for example.com to www.example.com. Consensus seems to be that this is an application specific need and not part of the generic solution.


* Uniform Access to Information About

Document: http://www.w3.org/2001/tag/doc/more-uniform-access.html
Author: Jonathan Rees
List: www-tag at w3.org
Archive: http://lists.w3.org/Archives/Public/www-tag/
Org: W3C

The W3C TAG (Technical Architecture Group) is scheduled to hold a face-to-face meeting Dec 9-11 in Cambridge, MA. This draft has been submitted as the basis for discussion on the topic of locating 'information about' resources. The work originated from past discussions related to the POWDER specification from the W3C (see below). The TAG is trying to address the discovery topic from a high-level architectural stand point which is usually different from the discussion over technical details (header format, parameter names, etc.). Such discussions tend to be more "philosophical" than implementation-based, which gives a great complimentary perspective to this work.

The topics discussed in this draft:

- Use of Link header and elements to identify the location of a resource descriptor (information about).
- Relationship between the resource URI scheme and the use of HTTP for performing discovery itself.
- Interaction with HTTP status codes.
- Trust issues (authority and rights).

The W3C TAG is expected to produce some written outcome from this upcoming discussion. It is not known at this point what level of output will be agreed-upon and produced and the timeline for that.


* POWDER: Protocol for Web Description Resources

Document: http://www.w3.org/TR/powder-dr/
Editors:  Phil Archer, Kevin Smith, Andrea Perego
List: public-powderwg at w3.org
Archive: http://lists.w3.org/Archives/Public/public-powderwg/
Org: W3C

The POWDER protocol has been created 'to provide a means for individuals or organizations to describe a group of resources through the publication of machine-readable metadata'. While using a completely different descriptor format from XRDS and its own set of use cases, the overall design and flow are similar.

The parts of POWDER that are most relevant to this discussion, and should be reviewed by those interested in this work are:

- Section 4: Associating Resources and DRs (http://www.w3.org/TR/powder-dr/#assoc)
- Section 5: Trust (http://www.w3.org/TR/powder-dr/#trust)

The current Working Draft has reached its Last Call stage at the W3C which is set to close today (12/5/08).


* XRD: Extensible Resource Descriptor

Document: N/A (first draft pending)
Editors:  Eran Hammer-Lahav, Nat Sakimura
List: xri-comment at lists.oasis-open.org [2] (members only: xri at lists.oasis-open.org)
Archive: http://lists.oasis-open.org/archives/xri-comment/ and http://lists.oasis-open.org/archives/xri/
Org: OASIS

The OASIS XRI TC has recently decided to spin-off its discovery protocol XRDS from the XRI specifications. The current effort is to define and position XRD (the new name for what has been previously known as XRID, XRDS, XRDS-Simple, and Yadis) as a generic discovery protocol for URIs. XRD is planned to cover the mechanism used to locate the retrieve the resource descriptor, the document format for that descriptor, and a trust and security mechanism.

Topics recently / currently being discussed:

- Review of existing and proposed trust solutions, including digital signatures and certificates.
- Simplification of the XRDS schema as currently specified [3].
- Replacement of the xri:// scheme for XML namespaces with an http://oasis/... URI.
- Delegation functionality for entire descriptor or select services.
- Replacement of current Yadis-based workflow (X-XRDS-Location header, <meta> element, Accept Header) with Link and /site-meta.

While the official XRD work is done on a members-only mailing list, much of the work directly derives and depends on public discussions. Everything listed in this report is taken as input and as the basis for XRD 1.0. Non-members are free to participate via the 'xri-comment' list which is open to non-members.


* OpenID Discovery

Document: N/A
Editors:  N/A
List: specs at openid.net
Archive: http://openid.net/pipermail/specs/
Org: OpenID Foundation

OpenID Authentication 2.0, the latest version of the OpenID protocol includes both directly and via normative references a discovery protocol for obtaining identity related metadata from an HTTP(S) URI, or an XRI. With the recent consolidation of the various discovery discussions and the efforts of the (now closed) XRDS-Simple community, it has been suggested that the entire OpenID discovery workflow be reviewed for a potential update.

The current effort is focused on finalizing and approving a working group charter to review and potentially update how OpenID discovery works. Until a new working-group specific mailing list is created, the generic specs list should be used for such discussions. OpenID is considered a top priority use case for XRD.


* URI Templates

Document: http://tools.ietf.org/html/draft-gregorio-uritemplate-03 (see also [4])
Editors / Authors: Joe Gregorio, Marc Hadley, Mark Nottingham, Dave Orchard
List: uri at w3.org
Archive: http://lists.w3.org/Archives/Public/uri/
Org: IETF

While not directly related to discovery, URI templates have been positioned as a potential key component of the proposed solution via the /site-meta approach. The current I-D has expired and it is not clear its status moving forward. The proposal has raised a number of significant issues and has yet to achieve a wide enough consensus to move forward. In addition, an alternative has been suggested [4] which may be used as the basis of a new (perhaps competing) proposal. To be clear, all the statements made in this paragraph are my personal interpretation of the situation and do not represent the views of any of the authors or others involved.

If /site-meta will remain part of the proposed discovery architecture, and no stable URI template proposal is available in time for the various efforts to use, it is expected that a simple format be directly specified by the XRD or /site-meta specification. For the sake of completion, the OpenSearch specification also includes a URI template proposal [5] worth considering.


* Metadata Discovery Coordination Group

Coordinator: Eran Hammer-Lahav
List: metadata-discovery at googlegroups.com
Archive: http://groups.google.com/group/metadata-discovery
Org: None

This report is part of an effort to better coordinate the various ongoing efforts happening in the discovery space as it relates to resource descriptors. As is evident from this report, the list of parallel efforts is long and for many people hard to follow. It is especially hard for newcomers to figure out where discussions are happening. It will be updated as new development justify it.


EHL

[1] http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html
[2] http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=xri
[3] http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html
[4] http://lists.w3.org/Archives/Public/uri/2008Sep/0007.html
[5] http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_URL_template_syntax










--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Metatada Discovery Coordination" group.
To post to this group, send email to metadata-discovery at googlegroups.com
To unsubscribe from this group, send email to metadata-discovery+unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/metadata-discovery?hl=en
-~----------~----~----~----~------~----~------~--~---




More information about the specs mailing list