OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


There are some interesting wrinkles in how URI templates interact with
delegation and security.  Let's say that site A wants to securely
delegate metadata descriptions about 1 million users to site B.  If
the URI mapping occurs before the delegation, then 1 million user
documents on site B have to be signed by site A.  That's a major pain
to administer.

It's much easier if the delegation statement and signature occurs
before (or at the same time as) the URI mapping.

If URI templates can only be in site-meta, it's really important that
site-meta also support signing and delegation.

On Mon, Dec 15, 2008 at 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".
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]