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