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