Fwd: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery

David Recordon drecordon at sixapart.com
Sat Nov 1 21:30:54 UTC 2008

This is worth reading as it outlines what Eran plans to do with the  
current XRDS and XRDS-Simple specifications.  It will have future  
implications on OpenID as the current Yadis discovery protocol  
actually violates the HTTP and web architecture (as pointed out by the  
W3C).  I'm going to be following this work and figure a future version  
of OpenID should make use of it.  That will mean that OPs will likely  
need to support the new discovery mechanism while also supporting the  
current one for a period of time as it becomes deprecated.

cc'ing Eran in case there are questions, but the discussion is  
occuring on the XRDS Simple list at http://groups.google.com/group/xrds-simple 
  for the time being.


Begin forwarded message:

> From: Eran Hammer-Lahav <eran at hueniverse.com>
> Date: October 27, 2008 3:06:41 PM PDT
> To: "xrds-simple at googlegroups.com" <xrds-simple at googlegroups.com>
> Subject: [xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery
> Reply-To: xrds-simple at googlegroups.com
> I have been reviewing XRDS and XRDS-Simple for the past couple of  
> months, including their relationship to HTTP, web architecture, and  
> most importantly, the use cases that are driving the development of  
> an HTTP discovery protocol. What I am most interested in has always  
> been a protocol for discovering metadata about an HTTP resource.  
> This metadata is focused on two things: the resource itself, and its  
> relationship to other resources.
> Brand / Document Type
> I would like to change focus from XRDS/XRDS-Simple to XRD. XRDS as a  
> sequence of XRD elements is specific to XRI resolution where the  
> sequence of XRDs adds value. The inclusion of multiple XRD elements  
> does not fit within the model of a document describing a resource.  
> My proposed use of URI fragment together with xml:id attributes ads  
> much complexity and little value and will be dropped.
> I propose to name this specification ‘XRD: Extensible Resource  
> Descriptor’. There is existing value in the XRDS and XRDS-Simple  
> brands, but it is extremely low outside the social-web/identity echo- 
> chamber. Pushing out a somewhat new brand of XRD with a simple  
> acronym (Extensible Resource Descriptor) goes a long way in  
> delivering our message.
> Focusing on the application/xrd+xml and XRD schema will also make  
> the transition easier as there will be less overlap in headers,  
> elements, and existing documents. By offering an XRD-top-level  
> document, there is less chance of conflicting with existing XRI and  
> OpenID documents.
> This effort should be branded as XRD 1.0. XRDS is currently in  
> version 2.0 (which failed an OASIS vote) and is now planned to  
> become 3.0. I think that for branding purposes, starting with  
> version 3.0 is counterproductive, but I do not have strong opinions  
> in the version number. One idea I like is to drop the version and  
> use a date instead (common for W3C standards).
> Another advantage of keeping XRDS XRI-specific is that the current  
> XRDS element not included in the new XRD schema will be able to get  
> assigned to the XRDS namespace which will prevent the need to define  
> a third namespace just for XRI-specific elements (on top of the XRDS  
> and XRD namespaces).
> Venue / Namespace
> XRD is a product of the OASIS XRI TC and if for no other reason than  
> to give proper attribution, should stay anchored there. I intend to  
> draft and publish the XRD specification as a product of the XRI TC  
> and will be joining OASIS in the next few days. As an OASIS  
> standard, the XRD schema should have an OASIS http namespace (http://docs.oasis-open.org/ns/xri/xrd/1.0 
>  or http://docs.oasis-open.org/ns/xri/xrd/2008/11).
> However, much of the relevant community to a generic HTTP discovery  
> mechanism and resource metadata resides in the IETF where HTTP is  
> defined and evolved. I would like to find a way to publish OASIS  
> drafts simultaneously as IETF I-Ds for informational purposes only.  
> At the end, I would like to see the OASIS standard assigned an IETF  
> RFC number. Again, this is not a proposal for standardization at the  
> IETF, just using the RFC as a publication channel. This proposal  
> needs much discussion by the XRI TC and would ultimately be their  
> decision.
> Discovery Workflow
> The entire discovery workflow defined by Yadis will be replaced in  
> XRD. Support for the ‘Accept’ HTTP header will be removed as it  
> violates HTTP and web architecture. The direct-access use case (of  
> accessing the metadata document without interacting with the  
> resource itself) will be supported using the new /site-meta proposal  
> [1] with a dynamic map to transform the resource URI to the metadata  
> URI. The resource metadata map functionality will be added to the  
> next draft of the /site-meta proposal or published as a separate  
> proposal.
> The plan is to add support for mapping between a resource’s URI to  
> the URI of its metadata document by using a URI template. Currently,  
> the draft only covers links to site-wide metadata. However, there  
> are use cases in which a client is looking for resource-specific  
> metadata. The proposal is to add a simple template-based mechanism  
> to create a map between the resource URI to the metadata URI  
> (specific to that resource). The new addition will add a new element  
> to the site-meta schema (as a child of the <metadata> element):
> <resource-map type="application/example+xml" rel=”http://example.com/relationship 
> ” map="http://meta.example.net?resource={uri}" />
> The element maps the metadata document URI for: http://example.net/resource/1 
>  with http://meta.example.net?resource=http%3A%2F%2Fexample.net%2Fresource%2F1 
> .
> XRD will use the (to-be-registered) content type application/xrd+xml  
> with the Link header [2] and HTML <Link> element to link from the  
> resource itself to the metadata document. This will replace the XRDS  
> mechanism using X-XRDS-Location header and <meta> HTML element. The  
> X-XRDS-Location header will not be directly affected as it is XRDS- 
> specific, but it should be marked as depreciated and replaced by the  
> Link header for the XRDS use case as well (if such support is  
> desired).
> XRD discovery will not define a relationship type, allowing XRD to  
> be used for any relationship type desired (authorization, list of  
> social services, etc.). In other words, XRD will be useful to  
> describe the same resource in different context using multiple  
> document.
> Tiered Schema
> XRDS-Simple is a restrictive subset of XRDS which better fits the  
> common use cases needed for HTTP-based discovery. The XRDS schema  
> can be considered to include three types of elements and attributes:  
> basic, advance, and XRI-specific. XRDS-Simple can be considered the  
> basic set. In order to simplify implementation and provide an  
> upgrade path from the basic set to the advance set, the proposed XRD  
> schema will include both the basic and advance sets in one format.
> In order to allow parsers to check if they are capable of handling  
> extensions, the advance set, or other types, XRD might include a  
> ‘level’ (or ‘profile’) attribute to indicate if the document is a  
> ‘basic’ or ‘advance’. This isn’t mandatory as the specification can  
> simply instruct basic parsers to look for unknown elements in the  
> same namespace and if such found, to treat the document as an  
> advance profile. In a way, this will be required from a basic parser  
> anyway, so the profile attribute might not be needed. Either way,  
> the XRDS-Simple profile will be required while the rest of XRDS  
> defined as optional support.
> Schema Changes
> The Key change I am proposing is to make the XRD itself a resource- 
> descriptor, closely mirroring how the Service element treats related  
> resources. What this means is adding support for the URI and  
> MediaType elements at the XRD level and defining Type as an  
> attribute of the resource, not the XRD itself (as was previously  
> used by XRDS-Simple).
> At the XRD level, multiple URI will mean equivalent endpoints for  
> the same resource, while CanonicalID can be used to indicate which  
> is the authoritative view. I am not sure if EquivID is suitable for  
> this use case and if it is, no need to add URI support at the XRD  
> level. I am just not sure if this will break anything with XRI. Both  
> CanonicalID and EquivID can be replaced with URI (with priority  
> attribute support).
> [1] http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt
> [2] http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google  
> Groups "XRDS-Simple" group.
> To post to this group, send email to xrds-simple at googlegroups.com
> To unsubscribe from this group, send email to xrds-simple+unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/xrds-simple?hl=en
> -~----------~----~----~----~------~----~------~--~---

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081101/f75e4359/attachment-0002.htm>

More information about the specs mailing list