W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Input on request for link relation

From: Sam Johnston <samj@samj.net>
Date: Wed, 16 Sep 2009 12:13:35 +0200
Message-ID: <21606dcf0909160313m1dcad47dk47c139959edb113d@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Lisa Dusseault <lisa.dusseault@gmail.com>, Atom-Syntax Syntax <atom-syntax@imc.org>, ietf-http-wg@w3.org, Brett Slatkin <brett@haxor.com>
On Wed, Sep 16, 2009 at 8:15 AM, Mark Nottingham <mnot@mnot.net> wrote:

> In the current link draft, relations shouldn't have dependencies on the
> media types of what's linked to, and it looks like both the request and
> response content is constrained in this proposal.
>
> Why not use an extension relation type (i.e., unregistered URL) instead of
> a registered one? That allows the protocol to define things much more
> closely, because it will "own" the relation type.
>

I tend to agree that such standards should be strongly encouraged to use URI
relations (at least while waiting for approval, but perhaps also on an
ongoing basis) and that clients should accept both. One way to precipitate
this would be to reject this application, giving reference to the existing
'monitor' relation (which per Adam Roach above "was to be used for both
polling *and* passive mechanisms").

I see that the applicant (copied) owns http://pubsubhubbub.org/ which would
be as good a URI as any to use, but they could also use the Google Code site
or a PURL. Being able to resolve directly back to the specification rather
than going via the registry would presumably be advantageous too. In any
case it's not clear to me how this registration will help interoperability
given the constraints Mark referred to above and Brett in this
thread<http://groups.google.com/group/pubsubhubbub/browse_thread/thread/e24797ef477ecddd/a6ed35a34ad1421b#a6ed35a34ad1421b>
:

The protocol-specific nature of the "hub" relation is extremely important.
> Like the AtomPub "edit-media" relation, the "hub" link is a machine-readable
> declaration that enables software to take a specific action on discovery
> (via the PubSubHubbub protocol). Without being bound to a specific protocol
> this discovery mechanism becomes useless.


Indeed if competitive standards like PubSubHubbub and rssCloud were to share
the relation (at least without clarifying with a content type) then it could
ironically cause interoperability problems. Note also that the motivation
for the application was Atom compliance which would be achieved with a URI
relation. That's not to say it's any less of a standard, just that the
relations registry is intended for generic relations (at least going
forward).

Sam


> On 11/09/2009, at 3:30 AM, Lisa Dusseault wrote:
>
>  Comments welcome on the following request
>>
>> thx,
>> lisa
>>
>> ---
>> General Request for Assignments (link-relations)
>>
>> Contact Name :
>> Brett Slatkin
>>
>> Type of Assignment :
>> I want to add a new Atom Link Relation type for the PubSubHubbub protocol
>>
>> (http://pubsubhubbub.googlecode.com). The relation type is "hub".
>>
>> Registry :
>> http://www.iana.org/assignments/link-relations/link-relations.xhtml
>>
>>
>> Description :
>> The new  is used for discovery of Hubs,
>> which enables real-time notifications of entries in Atom and RSS feeds.
>> Without making the relation type official, we're not in compliance with
>> the
>>
>> Atom spec.
>>
>> Additional Info :
>> http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.1.html
>>
>>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>
Received on Wednesday, 16 September 2009 10:14:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:10 GMT