[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Re: Planning for XRD 1.0
a /site-meta equivalent is crucial to have this work in the enterprise space. hosted.example.com will want to bulk outsource discovery to a 3rd party site, presumably in a secure fashion. On Tue, Dec 2, 2008 at 5:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > 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: > > The solution must support small hosted sites to mega site. This requires > support for HTML/ATOM Link elements. > The solution must operate well with HTTP. This calls for support for the > Link header. > 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/ > > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]