Re: Input on request for link relation [ w/ proposed modifications to link draft ]

On 17/09/2009, at 12:35 AM, Brett Slatkin wrote:

> I understand part of the motivation for mnot's draft
> (http://www.ietf.org/id/draft-nottingham-http-link-header-06.txt), but
> it doesn't remove the need for registered link relations. It seems
> that the litmus test for registration is whether the relation is
> "broadly useful".

The litmus test is that:

* It's broadly applicable (which currently isn't true, because you're  
specific to Atom feeds)
* It has an existing, stable specification (which it looks like you're  
approaching, if you submit as an Internet-Draft), and
* It not be specific to a particular media type (which you are, at  
least for requests).

So there's probably room for getting it in, especially since you're  
effectively "grandfathered". See below for more.


> In that regard, it's important to note that PubSubHubbub is live for
> over 100 *million* feeds as of this writing. It is consumed by dozens
> of companies and developers from multiple countries. There are
> implementations of publisher and subscriber clients in many
> programming languages. There are even new companies with private
> investment running hubs. We've had the genie out of the bottle (since
> October 2008) and it's difficult to go back to ask everyone to change
> things now.

Then why are you only bringing it to the attention of the wider world  
now? I don't mean to pick on you, but it seems like there are lots of  
developers these days who are writing protocols in secret, and then  
expecting the world to come along for the ride, no matter how badly  
they interact with the infrastructure. Pubsubhubbub (PLEASE come up  
with a shorter name!) isn't the worst in this respect by far, but  
still...


> Also, on second thought, I should have pointed out that others
> (namely, Jeff Lindsay) advocate making PubSubHubbub a generic protocol
> that's not specific to any particular content type. This would enable
> the protocol to push event-based Atom, RSS, text, arbitrary XML, HTML,
> raw bytes, etc. I've pushed back on this because I don't want to lose
> focus on the use-case of feeds (because it's immediately useful), but
> I think making this protocol more generic in the future is a good
> idea.
>
> So, this is how I would modify your description from before to be  
> more generic:
>
> Description: A URI for a "hub" (speaking the PubSubHubbub protocol)
> that enables clients to register for and publish real-time updates to
> the resource.
>
> How does that sound?

That's a start. To my mind, you need to:

1. Accommodate things other than Atom feeds in your protocol, if only  
by leaving appropriate extension points for addressing it in a future  
(hopefully soon; lots of people are interested in this, from what I've  
seen) revision.

2. Publish as an Internet-Draft.

The question that this brings to mind for me about the Link draft is  
whether this text about registered relations is appropriate:

"Relation types that constrain the target IRI or context IRI (e.g., to  
a specific media type) MUST NOT be registered."

Obviously, that's pretty open-ended, and generally link relation types  
shouldn't specify a media type, if they're to be broadly applicable,  
but relations like "hub" that constrain things to specific input and  
output formats for *generic* protocols (here, pub/sub) could be an  
exception. Read too broadly, and this requirement could even disallow  
"duplicate" as we've been discussing on a separate thread.

My inclination at this point is to rewrite this as something like:

"Registered relation types MUST NOT constrain the media type of the  
context IRI, and MUST NOT constrain the available representation media  
types of the target IRI. However, they MAY specify the behaviours  
(e.g., allowable methods, request media types) and constrain the  
representations of target resources in other ways."

Thoughts?

Regarding "hub" vs. "monitor" -- this is interesting to me, if not  
just because people have been talking about this sort of protocol for  
easily more than a decade, and many proposals have already been made*.  
As such, I think there's more value in something more capable than  
specific, lest we all drown in a sea of special-purpose, needlessly  
application-specific protocols.

That said, I don't think you can use one link relation for both  
purposes, because even if they both took the same POST payloads, the  
further interactions beyond that (the callback to you) would also need  
to be compatible. While you could use the type attribute to  
distinguish between which protocol is in use, that's not really what  
it's for; the representation returned wouldn't be describing the  
protocol that was going to commence.

Cheers,


* I'm purposefully limiting my comments here to the impact on the link  
relations draft and registry. I have many other thoughts about  
pubsubhubbub and how suitable it is to general use; hopefully I'll  
have time to convey them separately.


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 17 September 2009 05:52:00 UTC