- From: Sam Johnston <samj@samj.net>
- Date: Wed, 16 Sep 2009 12:13:35 +0200
- 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>
- Message-ID: <21606dcf0909160313m1dcad47dk47c139959edb113d@mail.gmail.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 UTC