Re: [xri] Quick overview of descriptor discovery flow

[Eran Hammer-Lahav <eran@hueniverse.com>]

Title: Re: [xri] Quick overview of descriptor discovery flow

If it wasn’t clear, this replaces only the ‘Yadis’ portion of the current OpenID discovery flow. It means you can get from the URI the user entered to the XRD, and from there business as usual. If the RP supports email addresses, it can use the same process assuming a template is found to obtain the descriptor.

Note that this workflow does not convert the email to an http URI! All it does is provide the descriptor of any URI: http, mailto, or other. OpenID will still need to decide what to use as the actual identifier, but this suggest the claimed identifier is the mailto URI.

EHL


On 12/15/08 12:55 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

> The following method describes how to perform R-URI --> D-URI: finding the descriptor URI from the resource URI. The process starts with a resource URI. It doesn't matter how that URI has been obtained. In the examples below, 'D-URI' is used to indicate the placeholder containing the desired descriptor URI.
>
> 1. Method selection
>
> The consumer (entity performing discovery) has three options based on information available to it with regard to the resource:
>
> * If the resource is known to be an HTML or ATOM document, and the document has been and will be retrieved via HTTP GET either way, the consumer can look for <Link> elements:
>
>     <Link href=""D-URI"" rel="describedby" type="application/xrd+xml">
>
> * If the resource is going to be retrieved via HTTP GET/HEAD, the consumer can look for Link: headers:
>
>     Link: <D-URI>; rel="describedby"; type="application/xrd+xml"
>
> * If the first two options are not applicable, the consumer obtains the /site-meta document for the resource's domain. The consumer may request an XRD representation but must be able to parse the text representation. It is not clear if there is real value in offering an XRD representation of /site-meta (please discuss).
>
> Text:
>
>     Link-Template: <http://example.com?meta={+uri}>; rel="describedby"; type="application/xrd+xml"; syntax=”plain”; vocabulary=”uri”; scheme=”mailto http”
>
> XRD:
>
>     <XRD>
>         <Link>
>             <Rel>describedby</Rel>
>             <MediaType>application/xrd+xml</MediaType>
>             <TemplateURI syntax=”plain” vocabulary=”uri”>http://example.com?meta={uri}</TemplateURI>
>             <site-meta:scheme>mailto http</site-meta:scheme>
>         </Link>
>     </XRD>
>
> The ‘plain’ template syntax means simple substitution of {variable}s. If the variable name is prefixed with a ‘+’, it must be percent-encoded prior to substitution. The ‘uri’ template vocabulary includes: uri, scheme, authority, domain, port, path, query, fragment, and username.
>
> Using the template, the consumer construct the D-URI from the R-URI.
>
>
> EHL
> Ps. The above syntax for /site-meta is the expected format in the next draft. This flow does not use the regular Link records in /site-meta as those are used for the entire site (an abstract concept) and not for individual resources. There is no such URI identifying the “site”.