LRDD proposal draft

[Eran Hammer-Lahav]

How about this...

Note: I am using rel="lrdd" as a placehold for the actual LRDD relation type and rel="x" as the relation type desired.

1. Get host-meta and find the LRDD link:

<Link template="http://example.com?uri={uri}" rel="lrdd" type="application/xrd+xml" />

2. Look for a link child element Priority (newly proposed element in XRD to replace <Type>):

<Link template="http://example.com?uri={uri}" rel="lrdd" type="application/xrd+xml">
<Property type="http://lrdd.net/priority/resource" />
</Link>

3. If not found, perform LRDD discovery in order: host-meta, Link: header, <Link> element. If found, perform LRDD discovery in order: <Link> element, Link: header, host-meta

4. For each of the three locations, in the order determined in #3:

[[ a. Look for the desired link (rel="x"), if found, stop ]]
b. Look for a LRDD link (rel="lrdd") and get LRDD XRD document. If failed continue to next location
c. Look for the desired link (rel="x"). If not found continue to next location
d. If the link uses a template, apply the template to the resource URI to get the link URI. If template fails, continue to next location
e. Success

5. If no link was found, protocol fails

I am not sure we need 4a.

Trust profiles will need to validate the XRD documents obtained in #1, #4 for host-meta, and #4b.

Also, I am not sure how Template-XRD (used in #4d) will be verified from trust perspective since they will not have a <Subject>.

EHL

[Eran Hammer-Lahav]

Is this good enough to put another draft out?

EHL

[John Panzer]

This looks pretty good to me.

One q:  Should the "resource-first" property be on the individual links?  I suppose that gives the most flexibility, though it means Webfinger gets a workout.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Eran Hammer-Lahav]

WebFinger will just use the LRDD relation type, so no.

 

EHL

[Blaine Cook]

In that sense, it might actually make sense to use something more
english for the relation type. There may be a real adoption advantage
to being able to verbally say, for example, "rel='discover'" or
"rel='disco'" or "rel='lard'" (as offensive to music lovers and
vegetarians as those last two may be).

b.

2009/11/11 Eran Hammer-Lahav <er...@hueniverse.com>:

[Eran Hammer-Lahav]

We are going to register a short-name for LRDD. Just need to pick a good one that is not too generic (i.e. no 'meta', 'discovery', 'about', etc.). I talked to Mark today about the web link relation registry and it is going to allow protocol specific relations as long as they are useful *within* multiple sources (which obviously it will be, at least 3).

So those of you with a short attention span who cannot focus on the actual LRDD workflow, please think of short relation types. :-)

[John Panzer]

Wait, what is this about again?
- http://snltranscripts.jt.org/88/88ashortterm.phtml

--

[Joseph A Holsten]

Anyone want to remind me what happened to the POWDERism rel=described-
by?
--
j

[Eran Hammer-Lahav]

'describedby' is not protocol-specific. It has a loose semantic meaning which tells clients, "try it, it might be someone you understand and find useful". It doesn't come with any clear processing priority or other restrictions.

[Joseph A Holsten]

Blaine Cook wrote
> In that sense, it might actually make sense to use something more
> english for the relation type. There may be a real adoption
> advantage to being able to verbally say, for example,
> "rel='discover'" or "rel='disco'" or "rel='lard'" (as offensive to
> music lovers and vegetarians as those last two may be).

Joseph A Holsten wrote:
> Anyone want to remind me what happened to the POWDERism
> rel=described-by?

Eran Hammer-Lahav wrote:
> 'describedby' is not protocol-specific. It has a loose semantic
> meaning which tells clients, "try it, it might be someone you
> understand and find useful". It doesn't come with any clear
> processing priority or other restrictions.

Is that worse than rel=alternate? It's much narrower than rel="see-
also". <link rel="describedby" type="application/xrd+xml" href="/disco-
fabulous"> seems perfectly clear.

Much as I enjoy rel=disco, I'd like to know what I'm disco(ver)ing.
I'm discovering services? discovering information-about this resource?
discovering descriptions of this resource? discovering more-links-over-
yonder? I probably don't want to be discovering the lard of this
resource.

Is there not to use a purely declarative semantics, and let the tools
doing the processing? Is it sane to try to separate the document
semantics from their processing implications?
--
j

[Eran Hammer-Lahav]

I don't buy into much of the semantic web worldview. I want simple and deterministic protocols which look for specific link relations and act on them without having to guess and experiment to get what they need. With LRDD we are defining "The XRD" of any given resource which means we are enforcing a cardinality of one LRDD link per location (host-meta, header, element).

Sharing a relation type with other protocols such as 'describedby' means we now have to add another check for the media type. In addition, there is nothing to prevent someone for using 'describedby' to link to an XRD to describe the color of the page, given the way it is registered.

It is ok to have non-protocol-specific relation types such as 'alternate'. But that's not what we need here.

EHL

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Joseph A Holsten
> Sent: Wednesday, November 11, 2009 8:31 AM
> To: webf...@googlegroups.com
> Subject: Re: LRDD proposal draft
>
>

[Martin Atkins]

Eran Hammer-Lahav wrote:
> We are going to register a short-name for LRDD. Just need to pick a good one that is not too generic (i.e. no 'meta', 'discovery', 'about', etc.). I talked to Mark today about the web link relation registry and it is going to allow protocol specific relations as long as they are useful *within* multiple sources (which obviously it will be, at least 3).
>
> So those of you with a short attention span who cannot focus on the actual LRDD workflow, please think of short relation types. :-)
>

I'm sorry if this is digging up graves, but isn't rel="describedby" with
a type of "application/xrd+xml" sufficient to locate the XRD?

Last I looked this was how one XRD linked to another XRD (for example,
with host-meta and URITemplates) so why wouldn't we use the same
relation/type tuple in the links from the resource to its XRD?

[Eran Hammer-Lahav]

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Thursday, November 12, 2009 9:45 AM
> To: webf...@googlegroups.com
> Subject: Re: LRDD proposal draft
>
>

> Eran Hammer-Lahav wrote:
> > We are going to register a short-name for LRDD. Just need to pick a
> good one that is not too generic (i.e. no 'meta', 'discovery', 'about',
> etc.). I talked to Mark today about the web link relation registry and
> it is going to allow protocol specific relations as long as they are
> useful *within* multiple sources (which obviously it will be, at least
> 3).
> >
> > So those of you with a short attention span who cannot focus on the
> actual LRDD workflow, please think of short relation types. :-)
> >
>
> I'm sorry if this is digging up graves, but isn't rel="describedby"
> with
> a type of "application/xrd+xml" sufficient to locate the XRD?

Not if we want to enforce a zero or one cardinality between each location and "The" LRDD XRD. Also, the type is nothing but a hint and the consensus is it should not be used by protocols to make deterministic link selection.

> Last I looked this was how one XRD linked to another XRD (for example,
> with host-meta and URITemplates) so why wouldn't we use the same
> relation/type tuple in the links from the resource to its XRD?

Within an XRD, 'describedby' can be used to associate any generally purpose descriptors to a resource. But in practice it is pretty useless. It is not like we are writing a protocol that just crawls and looks for anything it can find. I it mostly useful when interacting with people (like rel='author') or for semweb stuff.

EHL

[Martin Atkins]

On 11/12/2009 12:16 PM, Eran Hammer-Lahav wrote:
>
>>
>> I'm sorry if this is digging up graves, but isn't rel="describedby"
>> with
>> a type of "application/xrd+xml" sufficient to locate the XRD?
>
> Not if we want to enforce a zero or one cardinality between each location and "The" LRDD XRD. Also, the type is nothing but a hint and the consensus is it should not be used by protocols to make deterministic link selection.
>

Atom seems to get on okay having the single "permalink" for a entry
being a link whose rel is "alternate" and whose type is "text/html".

Furthermore, the Atom specification itself requires that there not be
more than one rel="alternate" link with the same (type, hreflang) tuple
associated.

This does seem like a deviation from the design of link constructs and
their usage in other specifications. If there has been a discussion
about this elsewhere that has reached consensus that the link design is
flawed and that rel should be the sole selector for a link then I'm
happy to concede, though I would be interested to know where that
discussion took place so I may review it and see the rationales.

(Also, once you stop using "type" as part of the selector it seems a
little pointless to have it at all. You characterized it as a "hint",
but it seems to me that the primary purpose of this hint has been to
exclude from consideration links to unsupported representation formats
without requiring a separate request to be made; if that's not what it's
for, then what exactly is it for?)

[Eran Hammer-Lahav]

This has been discussed for about two years now as part of http://tools.ietf.org/html/draft-nottingham-http-link-header-06

The thing about 'type' is that you have to treat it as a hint because the link might be pointing at something with a different type. The way links were setup before this draft gave rel types a specific meaning in each context they were defined. So XRD can dictate what a link relation means if you find it in an XRD and that includes existing rels. However, we are trying to move to a unified link framework where links share common rel values across context.

LRDD has specific protocol requirements which makes it hard to use with existing relation types because they are already defined with much looser restrictions.

EHL

> -----Original Message-----
> From: webf...@googlegroups.com [mailto:webf...@googlegroups.com] On
> Behalf Of Martin Atkins
> Sent: Thursday, November 12, 2009 1:56 PM
> To: webf...@googlegroups.com
> Subject: Re: LRDD proposal draft
>
>

[John Panzer]

To revive this thread and bring it back to something other than the color of the link relation:  I think that the proposed lookup flow is fine (reproduced below) but would like to see fully worked out spec text.

1. Get host-meta and find the LRDD link:

<Link template="http://example.com?uri={uri}" rel="lrdd" type="application/xrd+xml" />

2. Look for a link child element Priority (newly proposed element in XRD to replace <Type>):

<Link template="http://example.com?uri={uri}" rel="lrdd" type="application/xrd+xml">
       <Property type="http://lrdd.net/priority/resource" />
</Link>

3. If not found, perform LRDD discovery in order: host-meta, Link: header, <Link> element. If found, perform LRDD discovery in order: <Link> element, Link: header, host-meta

4. For each of the three locations, in the order determined in #3:

       [[ a. Look for the desired link (rel="x"), if found, stop ]]
       b. Look for a LRDD link (rel="lrdd") and get LRDD XRD document. If failed continue to next location
       c. Look for the desired link (rel="x"). If not found continue to next location
       d. If the link uses a template, apply the template to the resource URI to get the link URI. If template fails, continue to next location
       e. Success

5. If no link was found, protocol fails

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Eran Hammer-Lahav]

Just posted:

 

http://tools.ietf.org/html/draft-hammer-discovery-04

 

Please discuss on the IETF Apps list as indicated by the draft (i.e. NOT here).

 

Coming next is the WebFinger I-D.

 

EHL

[John Panzer]

Awesome; updated http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html to reference this document.