Re: Input on request for link relation

[Sam Johnston]

Jan et al,

In line with comments I've made in other threads I think it makes sense for us to limit link relation discussions to the generic relation itself rather than any specific implementation of it. I imagine the pubsubhubbub Google Group (blind copied as it requires subscription to post) is the appropriate forum for your [no doubt legitimate] concerns regarding the protocol.

In terms of the relation, I think the description could be improved by dropping references to entries, Atom and RSS. It is conceivable for example that someone would want to be notified of an update to an HTML page (I'm thinking about this currently for status updates to HTML renderings of virtual machine resources) or indeed some other arbitrary resource. If we [continue to] allow relations to be bound to protocols in spite of the availability of content types and/or URI relations which are fit for the purpose we're going to back ourselves into a corner before we know it.

Accordingly I propose the following description:

Description: A URI for a "hub" that allows clients to register for real-time updates to the resource.

The PuSH(?) group may want to consider using a URI relation and/or dedicated content type in addition to the generic "hub" relation.

Kind regards,

Sam

On Fri, Sep 11, 2009 at 1:57 AM, Jan Algermissen <algermi...@mac.com> wrote:

On Sep 11, 2009, at 1:31 AM, John Panzer wrote:

Without getting into the appropriate discussion form question, what hub resource semantics (and link relation definition) are you referring to exactly?  I can't seem to find it, and it's hard to understand your objection without it.

Section 7.3 says:

"If, after a content fetch, the hub determines that the topic feed content has changed, the hub MUST send information about the changes to each of the subscribers to the topic."

I understand this to imply that subscribers expect the hub to definitely send the notifications. What if the hub decides not to due to the number of subscribers it has? Or to turn this around: how would a subscriber ever know whether not receiving notifications means that there are not updates or that the hub stopped sending notifications.

Jan

On Thu, Sep 10, 2009 at 12:40 PM, Jan Algermissen <algermi...@mac.com> wrote:

Lisa,

not sure the following it is appropriate to discuss this here, so please redirect me to the proper place if so.

Hubs are being discovered by clients by way of the 'hub' link relation. I am
concerned that the semantics of a hub resource (provided by the link relation
definition) are imposing obligations on the server that are contrary what one
would expect to see in the HTTP world.

Or in other words: I think that the assumptions a client makes about the behaviour
of a hub are too rigid. If a hub has more subscribers than it knows it can handle
it might well decide not to notify them. A situation like this is impossible to
prevent by the specification and I think the server should therefore explicitly be
given much more freedom regarding its behavior upon a ping.

Especially given the use of Atom which in a sense implies a very unconstrained
protocol.

(Sorry if this discussion is already going on elsewhere)

Jan



On Sep 10, 2009, at 7:30 PM, 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

[Brett Slatkin]

Hey Sam,

Sorry for the delay in my response, I've been on vacation.

On Fri, Sep 11, 2009 at 4:45 AM, Sam Johnston <sa...@samj.net> wrote:
> In line with comments I've made in other threads I think it makes sense for
> us to limit link relation discussions to the generic relation itself rather
> than any specific implementation of it. I imagine the pubsubhubbub Google
> Group (blind copied as it requires subscription to post) is the appropriate
> forum for your [no doubt legitimate] concerns regarding the protocol.
> In terms of the relation, I think the description could be improved by
> dropping references to entries, Atom and RSS. It is conceivable for example
> that someone would want to be notified of an update to an HTML page (I'm
> thinking about this currently for status updates to HTML renderings of
> virtual machine resources) or indeed some other arbitrary resource. If we
> [continue to] allow relations to be bound to protocols in spite of the
> availability of content types and/or URI relations which are fit for the
> purpose we're going to back ourselves into a corner before we know it.

The proposal I submitted (for
http://www.iana.org/assignments/link-relations/link-relations.xhtml)
is to add the "hub" link relation as valid *only* for Atom documents.
Your concerns about HTML are valid in general, but not relevant in
this context as I understand things.

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.

> Accordingly I propose the following description:
> Description: A URI for a "hub" that allows clients to register for real-time
> updates to the resource.
> The PuSH(?) group may want to consider using a URI relation and/or dedicated
> content type in addition to the generic "hub" relation.

Such an amorphous definition doesn't accomplish anything, in my view.
Hopefully what I said above makes sense. Many of the other relation
types specifically reference an RFC with the protocol definition.
PubSubHubbub is moving in that direction, and hopefully will be a real
RFC after the draft stage.

Otherwise, this is my first time interacting with any of these
standards or standards bodies, so please forgive me if I'm
misunderstanding anything or being thick-headed.

> On Fri, Sep 11, 2009 at 1:57 AM, Jan Algermissen <algermi...@mac.com>
> wrote:
>>
>> On Sep 11, 2009, at 1:31 AM, John Panzer wrote:
>>
>>> Without getting into the appropriate discussion form question, what hub
>>> resource semantics (and link relation definition) are you referring to
>>> exactly?  I can't seem to find it, and it's hard to understand your
>>> objection without it.
>>
>> Section 7.3 says:
>>
>> "If, after a content fetch, the hub determines that the topic feed content
>> has changed, the hub MUST send information about the changes to each of the
>> subscribers to the topic."
>>
>> I understand this to imply that subscribers expect the hub to definitely
>> send the notifications. What if the hub decides not to due to the number of
>> subscribers it has? Or to turn this around: how would a subscriber ever know
>> whether not receiving notifications means that there are not updates or that
>> the hub stopped sending notifications.

Jan: This is some extremely useful feedback. Could you please follow
up on the mailing list (http://groups.google.com/group/pubsubhubbub)
about this? We should be able to investigate and address your concerns
in an update to the PubSubHubbub spec!

-Brett

[Martin Atkins]

Brett Slatkin wrote:
>
> The proposal I submitted (for
> http://www.iana.org/assignments/link-relations/link-relations.xhtml)
> is to add the "hub" link relation as valid *only* for Atom documents.
> Your concerns about HTML are valid in general, but not relevant in
> this context as I understand things.
>
> 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.
>

Normally it is the "type" parameter which gives a specific
representation format. However, as with OpenID it's not a good fit here
because a PubSubHubbub hub doesn't really behave like a REST-ish
resource that the rel/type mechanism was intended for.

I think the argument being made here is that, for example, rssCloud
should in thery use the same rel as hubbub does, because they're both
specific implementations of (more or less) the same functionality.

So, as I understand it, there are two options that are in the spirit of
the Atom link rel extension mechanism:

* Define some dummy MIME type that represents a hubbub-type hub. This
feels kinda stupid.

* Use a URI specific to hubbub as the rel value, rather than
registering an "official" rel keyword. (or, if you're willing to bend
the rules the same way OpenID did, use some pseudo-namespaced rel like
"hubbub.hub".

But with all that said, in practice many rel values have ended up bound
to specific protocols despite the best intentions of those who designed
the rel/type tuple. rel="hub" is terse and easy to understand. I have
trouble coming up with any practical problem with it.

[Sam Johnston]

On Wed, Sep 16, 2009 at 8:15 AM, Mark Nottingham <mn...@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:

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/

[Sam Johnston]

On Thu, Sep 17, 2009 at 4:02 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:

I also want to point out that we really need to work on our messaging and perception that URI extension relation type are in any way inferior or "less cool" than the short registered ones. The sooner protocol authors accept this as a perfectly valid choice for their protocol needs, the better the link framework will be.

I couldn't have said it better myself. Basically what you are saying by requesting a short relation is that you actively intend to share the relation with others with a view to improving interoperability. By using a URI you control you're saying you want it to have a specific, concrete meaning (while retaining the option of sharing). The more I hear the more it sounds like PubSubHubbub wants the latter and with that in mind I would suggest that http://pubsubhubbub.org/ is as good an identifier as any.

Imagine a feed advertising both rssCloud and PuSH - without clarification of the "hub" relation (for example by way of dedicated content types) clients will have to use protocol discovery or trial and error to work out what to use. It doesn't help that it's not so much a content type we're talking about but a protocol, in which case a [registered] service name would be a better fit (and even then registered service names are generally used in conjunction with well-known port assignments rather than "everything over HTTP").

I have a similar problem with OCCI whereby I want to advertise console access to virtual machines via ssh, vnc-server or ms-wbt-server - I guess we'll have to assign a separate link relation (like  http://purl.org/occi/console#ssh) for each protocol, which is a bit of a hack when e.g. a "service=ssh" attribute would accomplish the same. Conversely content types work fine for advertising console screenshots in e.g. PNG or JPEG.

Mark: perhaps you could consider including some wording like Eran's and/or mine above into the Web Linking draft so we can point at it later? I would also suggest that the "broadly useful" test needs some refinement - the implication in rejecting applications is that the applicant's work is not "broadly useful" while what we mean by this is that it is useful for multiple/many standards.

Sam

[Martin Atkins]

Sam Johnston wrote:
> On Thu, Sep 17, 2009 at 4:02 AM, Eran Hammer-Lahav <er...@hueniverse.com
> <mailto:er...@hueniverse.com>> wrote:
>
>
> I also want to point out that we really need to work on our
> messaging and perception that URI extension relation type are in any
> way inferior or "less cool" than the short registered ones. The
> sooner protocol authors accept this as a perfectly valid choice for
> their protocol needs, the better the link framework will be.
>
>
> I couldn't have said it better myself. Basically what you are saying by
> requesting a short relation is that you actively intend to share the
> relation with others with a view to improving interoperability. By using
> a URI you control you're saying you want it to have a specific, concrete
> meaning (while retaining the option of sharing). The more I hear the
> more it sounds like PubSubHubbub wants the latter and with that in mind
> I would suggest that http://pubsubhubbub.org/ is as good an identifier
> as any.
>

I think the main beef that folks have with the URI-shaped rels is that
they're long and awkward. Why is all that "http://" and "/" noise in
there? That's only useful if you want to dereference the URI.
pubsubhubbub.org is enough information for an identifier.

Here are some other examples that would probably be less objectionable:

* hubbub.hub (OpenID-style protocol.rel naming)
* org.pubsubhubbub.hub (Java-style .. but I personally find it award
that these are "backwards" compared to DNS.
* pubsubhubbub.org:hub (like a tag: URI without the scheme and date)

These things are much less likely to be considered second-class citizens
if they don't look so daft.