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: [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]