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