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: Planning for XRD 1.0


Title: Re: Planning for XRD 1.0
This is very much the basic use case. OpenID, OpenSocial, OAuth, and Portable Contacts are real use cases stuck waiting for this to be resolved. Developers are literally waiting for instructions to code. The basic requirements are listed in my blog post on HTTP and Discovery, but to super simplify it:

  1. The solution must support small hosted sites to mega site. This requires support for HTML/ATOM Link elements.
  2. The solution must operate well with HTTP. This calls for support for the Link header.
  3. The solution must support non HTTP URIs in the current deployed environment. The actual use case is mailto which is the de-facto user-identifier on the web today.

The three way solutions is directly targeting this. 1+2 is the current consensus for discovery. Everyone talks about the need for 3, that is, some way to find out resource description without having to HTTP GET it. /site-meta came out directly out of our discussions of the third requirement, but as currently drafted, falls short of actually supporting the use case.

Take DNS out for now (since there is no concrete proposal and no one who likes to see one suggests it be required) and this isn’t really that complicated. With the exception of the new /site-meta + templates proposal, the rest is really just best-practices of existing implementations.

EHL


On 12/2/08 4:27 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

Hey Eran,

My only real concern here is the variety and number of discovery
mechanisms being put forth; it's going to increase complexity for
implementers, and reduce the chances that accidental reuse will happen.

E.g., if someone finds some value-added service that they'd like to
introduce on-the-fly, but they have to sniff content (which is very
expensive), check response headers, check DNS and look up a template,
it's not going to happen.

Rather than trying to cover every scenario to start with, can't we
figure out what the 80% / right now case is and just work on that,
letting future extensions cover the rest?

Cheers,


On 30/11/2008, at 12:39 PM, Eran Hammer-Lahav wrote:

> The goal of this email is to identify open issues with regard to the
> common
> discovery framework (the part of XRD that will be applicable to non-
> XRD use
> cases) and to suggest next steps given the tight schedule we are
> trying to
> meet.
>
> ---
>
> Solution Outline
>
> XRD 1.0 will consists of 2 components (note I am not discussing
> document
> structure but design):
>
> 1. How to locate a resource's XRD descriptor given a resource URI.
> 2. How that XRD is structured and interpreted (Type/Link Selection).
>
> I think we have reached agreement that the first component,
> identifying the
> location of the resource descriptor should be uniform across
> descriptor
> formats (i.e. XRD, POWDER, etc.). Note I am no longer using the term
> metadata since abstract resources don't have 'data' to 'meta' on.
>
> At this point, the overall proposal is to use the following mix:
>
> 1. <Link> Element in HTML, XHTML, ATOM, and other XML-based schemas
> with
> support for an equivalent element. Solves HTML/ATOM regardless of
> transport
> (which is still likely to be HTTP).
>
> 2. HTTP Link response-header. Solves HTTP URIs with an HTTP
> representation
> available (if the resource is not HTTP-resolvable, it doesn't matter
> that
> the URI uses the HTTP scheme - there is no place to put the header).
>
> 3. Template-based mapping from the resource URI to the descriptor URI.
> Applicable to any URI scheme - basically the catch-all solution.
> Current
> proposal for storing such mapping includes /site-meta records (using a
> 'template' attribute extension to Link records), a DNS record (TBD),
> and
> another resource linked to from /site-meta or DNS.
>
> In addition, the workflow will include a signature mechanism that
> will be
> used to verify the authority and authenticity of documents used in
> discovery
> (end-to-end). The mechanism will apply to any document format
> supporting
> links (HTML, ATOM, /site-meta, XRD) by linking the document to a
> separate
> signature document (and certificate chain document).
>
> The idea is that the same Link infrastructure will be used to 'link'
> to the
> signature and certificate documents. Since all discovery document are
> retrieved using HTTP, it is easy to define the entire response body
> (raw
> form) as the signed content. Using external signatures avoid the
> need to use
> stuff like XML DSig.
>
>
> Coordination Effort
>
> None of the IETF drafts, currently /site-meta, Link header, and URI
> templates are likely to be published as final RFC by (around) May
> 2009 when
> we hope to go through an OASIS vote.
>
> POWDER is likely to use informative references to the Link header
> draft.
> Link isn't as important to POWDER as it is for XRD since POWDER is
> used
> equally to describe resources by their owners as much as by third
> parties.
>
> The IETF and W3C communities will not rush to participate in an OASIS
> specification or provide feedback. However, with regard to the
> solution
> above, it is critical that we reach that audience.
>
> The W3C TAG is schedule to discuss 'Uniform Access to Resource
> Descriptions'
> mostly in the context of the POWDER use case. It is unclear how much
> of the
> above solution they will endorse directly and in what form.
>
> As you can see, discovery is now being discussed simultaneously to
> some
> degree at OASIS, IETF, and W3C. There seems to be a general
> consensus as to
> the proposed solution outlined above.
>
>
> Open Items
>
> 1. Link Header
>
> * Draft [1] is pending a revision in the next few days. No
> implementation
> changes expected, but will clarify the structure and meaning of the
> header
> attributes.
>
> * Since the Link header draft may not be final by the time XRD goes
> for a
> vote, there is an open issue of which specification to reference
> (current
> draft or obsolete HTTP RFC [2] which included Link originally).
>
> 2. URI Mapping
>
> * The current IETF I-D proposal for URI templates [3] has expired
> and is too
> complex for discovery needs and lacks sufficient community support. An
> alternative proposal [4] by R. Fielding has not been submitted as
> draft at
> this point.
>
> * It is unclear how /site-meta [5] should support URI-maps. The
> direction
> [6] (i.e. simplification) /site-meta is taking, may or may not
> directly
> address storing such maps. A proposal [7] for adding support for URI-
> maps in
> /site-meta has been posted today pending feedback.
>
> * Once the URI template syntax is selected, the workflow must define a
> common vocabulary for deconstructing and reconstructing the resource
> URI to
> the descriptor URI. The simplest proposal includes a single 'uri'
> variable
> which can be used in a template with a prefix/suffix combination. A
> richer
> proposal includes all the terms listed in RFC 3986:
>
>         foo://example.com:8042/over/there?name=ferret#nose
>         \_/   \______________/\_________/ \_________/ \__/
>          |           |            |            |        |
>       scheme     authority       path        query   fragment
>
> where authority can be further broken down into 'domain' and 'port'.
> An even
> richer approach includes custom support for mailto URIs
> (user@domain) and
> XRI syntax (to replace the need for the append attribute of <URI>
> element in
> XRD).
>
> * Due to the difference between various URI schemes (for example
> http vs
> mailto), it was suggested to allow associating maps with specific URI
> schemes.
>
> * Waiting for proposals for a DNS-based solution to store URI-maps.
> References to existing DNS-based solutions mentioned during the TC
> F2F.
> Current IETF proposal from Apple [8] may be used to locate a service
> endpoint where such mapping is available, but clarification as to
> how it
> should be done is needed (the draft is somewhat complex for this use
> case).
>
> * XRD will define an alternative representation for /site-meta which
> will
> use the XRD schema to represent the /site-meta links. User-agents
> will use
> the Accept HTTP header to request this alternative representation. If
> supported, it will allow XRD resolution to operate solely within the
> XRD
> schema. However, support for the basic text-based (proposed) format
> (text/site-meta) will be required either way.
>
> 3. Link Relationship
>
> * Both POWDER and XRD today imply a singular relationship between a
> resource
> and its descriptor. In other words, the common use case is for a
> resource to
> link to a single XRD or POWDER descriptor. POWDER is moving forward
> with
> their proposal to register the 'describedby' rel type. Unless the
> registration is POWDER specific (which I hope it is not), I would
> suggest
> XRD uses the same rel type. 'describedby' would then become the
> default
> relationship for descriptor discovery (with more specific
> relationships
> defined as application specific).
>
> * The existing 'meta' relationship may also be used but it is not
> clear how
> it is currently implemented which may cause interop issues.
>
> 4. Trust
>
> * Many current XRDS use cases for XRD 1.0 require trust - the
> ability to
> authenticate and verify the authority of resource descriptors and
> related
> document (/site-meta). This is needed to accomplish an end-to-end
> solution
> that does not depend on HTTPS or other secure channels (due to current
> implementation issues for some use cases).
>
> * In a recent meeting with the Google team, a proposal has been
> suggested
> which is based on using certificates to sign the HTTP body (raw) of
> the
> signed document response. The signature will be provided in a
> separated
> resource linked to from the descriptor. The full details of this
> proposal
> have not been posted yet.
>
> * There are many open questions regarding this proposal, namely which
> signature algorithm to use, what certificate to use, and the content
> types
> used to provide the certificate and signature. One option is to use a
> similar approach as S/MIME [9] which comes with content type for
> signatures
> using PKCS #7.
>
> * At this point the proposal does not cover HTTP Link headers or the
> undefined DNS solution. It may be applicable to the HTML Link
> element as the
> entire HTML document can be signed in a similar way to /site-meta
> and XRD
> (same for ATOM).
>
>
> Next Steps
>
> * The Google team will post their trust solution to the XRI TC
> mailing list.
>
> * Current proposals for /site-meta document format and support for
> mapping
> are pending discussion and feedback on the WWW-Talk list.
>
> * The XRI community needs to review their vocabulary requirements for
> retiring the 'append' attribute and migrating its functionality to a
> new
> <URI-Template> element. While this is an XRD issue, it may have an
> impact on
> the URI mapping solution.
>
> * Waiting for clarification from the W3C regarding the registration of
> 'describedby' rel type.
>
> * Waiting for proposals for a DNS solution.
>
>
> Proposed Intermediate Draft
>
> In order to help in coordinating this entire effort (everything
> discussed in
> this report), I would like to publish the entire proposed solution for
> locating a resource descriptor as an IETF I-D. Doing so will allow
> the XRI
> TC and XRD 1.0 editors to widen the audience for this generic
> component of
> the specification, especially when all the IP is coming from IETF
> drafts
> already.
>
> This I-D will be published with the intention of being incorporated
> later
> into the XRD 1.0 specification, unless the schedule will permit to
> push it
> all the way to an RFC, in which case the XRD 1.0 specification will
> simply
> use a normative reference to it. It is not clear how that is likely to
> happen (given that draft's dependencies on the above mentioned IETF
> drafts).
>
> I would like to publish this I-D in the coming week so your feedback
> is
> requested. I will also post a modified version of this report to the
> Metadata Discovery Coordination Group.
>
> EHL
>
>
> [1] http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-02.txt
> [2] http://tools.ietf.org/html/rfc2068#section-19.6.2.4
> [3] http://tools.ietf.org/html/draft-gregorio-uritemplate-03
> [4] http://lists.w3.org/Archives/Public/uri/2008Sep/0007.html
> [5] http://tools.ietf.org/html/draft-nottingham-site-meta-00
> [6] http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0002.html
> [7] http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0006.html
> [8] http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
> [9] http://www.rfc-editor.org/rfc/rfc2311.txt
>
>
>
>


--
Mark Nottingham     http://www.mnot.net/




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