[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Planning for XRD 1.0
Eran, Outstanding email - lots of great stuff in here, in fact too much to try to address in one reply. Some overall feedback: 1) I like the idea you raise at the end about "publishing the entire proposed solution for locating a resource descriptor as an IETF I-D". The larger the audience that we can gain input from/consensus with, the better. 2) You provide a good list of open issues, but I don't yet have a clear sense of: - Which of these open issues should be tackled by XRI TC input/discussion vs. which ones are larger cross-body "coordination" issues. (Example: DNS proposals.) - For those issues which the XRI TC can tackle (such as URI template vocabulary for replacing the current URI "append" attribute), what's the priority, and how would you like to proceed with discussion? Suggestions on both scores: A) First, parse out the open issues onto the issues list of the XRD 1.0 spec home page I created today (http://wiki.oasis-open.org/xri/XrdOne/SpecHome) and link to proposal pages as needed. It's a simple manual approach to issues management, but it should work until OASIS gets Jira set up for us. To make it easy for you I already did this for the two open issues you explicitly labelled in your email and created proposal pages for each: http://wiki.oasis-open.org/xri/XrdOne/LinkHeader http://wiki.oasis-open.org/xri/XrdOne/UriMapping I just copied the text and links from your email. B) Start email threads on individual open issues as needed to advance discussion on the mailing list(s). Our best practice has been to use the issue # and name from the issues list on the spec home page as the email subject line so it's easy to find threads from the email discussions to update the wiki pages. For example, you could use the Subject lines: XRD 1.0 #1: Link Header XRD 1.0 #2: URI Mapping Hope this helps, =Drummond > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Saturday, November 29, 2008 5:39 PM > To: xri@lists.oasis-open.org > Cc: Mark Nottingham; Lisa Dusseault; Phil Archer; David Orchard; Jonathan > Rees > Subject: [xri] 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]