[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Planning for XRD 1.0
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]