[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] FW: New Version Notification - draft-hammer-hostmeta-09.txt
Indeed, if host-meta is not designed for stand-alone use case, then a title is not necessary. On Mon, May 24, 2010 at 11:52, DeWitt Clinton <dclinton@gmail.com> wrote: > +1 from me, but you already expected that. : ) > Now we're just two arbitrary (though minor) deltas away from making this > spec what I always wanted it to be: a simple list of standard Atom/HTML5 > <link> elements with the addition of the 'template' attribute. > So if the next draft a) drops the <Title> element in favor of the usual > 'title' attribute, and b) changes the casing from 'Link' to 'link', then I > can rest easily for evermore. > -DeWitt > > On Mon, May 24, 2010 at 11:28 AM, John Bradley <ve7jtb@ve7jtb.com> wrote: >> >> +1 to the change. >> >> I think especially with JRD it is unclear how a signature relates to >> <Host> especially given that Magic signatures use raw keys as opposed to >> X509 certificates. >> >> In many ways magic signature a good thing however it doesn't solve the >> trust bootstrap problem, and adds complexity requiring the unpacking of a >> base64 encoded file. >> >> I think the trust model for host-meta needs more thought. >> >> John B. >> >> On 2010-05-24, at 2:11 PM, Eran Hammer-Lahav wrote: >> >> > The <Host> element as currently specified adds no value to any of the >> > use cases host-meta is intended for. The only reason why it was originally >> > added was to support signatures. At this point it is far from clear how it >> > will actually be used, how to address multiple hosts, and what impact will a >> > JSON serialization will have on signatures (especially when considering >> > "magic signatures"). >> > >> > It is a part of the spec no one really cares much about, and removing it >> > doesn't prevent anyone from specifying it elsewhere, where it is actually >> > used. >> > >> > As for last stage, I'm not done with the document and planning on making >> > significant changes to LRDD and integrating them into the same spec. This is >> > based on feedback received over the last couple of weeks. >> > >> > Host-meta didn't even reach IETF last call yet. >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Breno de Medeiros [mailto:breno@google.com] >> >> Sent: Monday, May 24, 2010 10:56 AM >> >> To: Eran Hammer-Lahav >> >> Cc: xri@lists.oasis-open.org; webfinger@googlegroups.com >> >> Subject: Re: [xri] FW: New Version Notification - >> >> draft-hammer-hostmeta- >> >> 09.txt >> >> >> >> -1 to this change. >> >> >> >> Can you explain why the simplification is worth the cost of making a >> >> last- >> >> minute change and sowing uncertainty at this last stage? >> >> >> >> On Mon, May 24, 2010 at 10:49, Eran Hammer-Lahav >> >> <eran@hueniverse.com> wrote: >> >>> They can do whatever they want, as long as it is valid according to >> >>> the XRD >> >> schema. Host-meta leaves <Subject> and <Alias> undefined and not >> >> recommended. >> >>> >> >>> EHL >> >>> >> >>>> -----Original Message----- >> >>>> From: Breno de Medeiros [mailto:breno@google.com] >> >>>> Sent: Monday, May 24, 2010 10:21 AM >> >>>> To: Eran Hammer-Lahav >> >>>> Cc: xri@lists.oasis-open.org; webfinger@googlegroups.com >> >>>> Subject: Re: [xri] FW: New Version Notification - >> >>>> draft-hammer-hostmeta- 09.txt >> >>>> >> >>>> I suspect people will want to write a <Subject> instead of <hm:Host> >> >>>> now that it's gone. :) >> >>>> >> >>>> On Mon, May 24, 2010 at 00:52, Eran Hammer-Lahav >> >>>> <eran@hueniverse.com> wrote: >> >>>>> After much (re)deliberation and discussions, I've decided to drop >> >>>>> the >> >>>> <Host> element from host-meta. The two reasons why it was there were: >> >>>>> >> >>>>> 1. make host-meta self-contained so it can be obtained via other >> >>>>> means than /.well-known/host-meta 2. provide a subject for >> >>>>> signatures >> >>>>> >> >>>>> Since there are no use cases for #1, and #2 has failed to >> >>>>> materialize after >> >>>> more than a year of discussions (still no signature profile >> >>>> published), I have decided that for the sake of simplicity and >> >>>> practicality to remove the element. host-meta doesn't address >> >>>> security and it should not provide a hook for future security >> >>>> profiles - that's their job. Those who find a need for expressing the >> >>>> subject of a host-meta XRD (or JRD) can add it back in their own spec >> >>>> (or >> >> make up something else). >> >>>>> >> >>>>> -09 dropped the element. >> >>>>> >> >>>>> Note that there is going to be a -10 coming out shortly which >> >>>>> merges LRDD >> >>>> back into host-meta, dropping links from HTTP headers and HTML bodies >> >>>> (which don't have any driving use cases). >> >>>>> >> >>>>> EHL >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Internet-Draft@ietf.org [mailto:Internet-Draft@ietf.org] >> >>>>> Sent: Monday, May 24, 2010 12:45 AM >> >>>>> To: Eran Hammer-Lahav; draft-hammer-hostmeta@tools.ietf.org; >> >>>>> stpeter@stpeter.im >> >>>>> Subject: New Version Notification - draft-hammer-hostmeta-09.txt >> >>>>> >> >>>>> New version (-09) has been submitted for draft-hammer-hostmeta- >> >> 09.txt. >> >>>>> http://www.ietf.org/internet-drafts/draft-hammer-hostmeta-09.txt >> >>>>> >> >>>>> >> >>>>> Diff from previous version: >> >>>>> http://tools.ietf.org/rfcdiff?url2=draft-hammer-hostmeta-09 >> >>>>> >> >>>>> IETF Secretariat. >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> --Breno >> >>>> >> >>>> +1 (650) 214-1007 desk >> >>>> +1 (408) 212-0135 (Grand Central) >> >>>> MTV-41-3 : 383-A >> >>>> PST (GMT-8) / PDT(GMT-7) >> >>> >> >> >> >> >> >> >> >> -- >> >> --Breno >> >> >> >> +1 (650) 214-1007 desk >> >> +1 (408) 212-0135 (Grand Central) >> >> MTV-41-3 : 383-A >> >> PST (GMT-8) / PDT(GMT-7) >> > > -- --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]