On 01/20/2010 02:28 AM, Julien Genestoux wrote:
Hey,
We (superfeedr) have been in talks with a lot of publishers and several
of them where concerned about the "blindness" for publishers in the
PubSubHubbub protocol.
Sorry for linking from the Superfeedr blog
(http://blog.superfeedr.com/Extension/PubSubHubbub/Spec/publisher-callback-extension/),
but if you're looking for more insight on why we're proposing this, you
can find it there.
We published the Extension proposal to the wiki :
http://code.google.com/p/pubsubhubbub/wiki/AcceptingSubscriptionForPublishers?ts=1263982978&updated=AcceptingSubscriptionForPublishers
<http://code.google.com/p/pubsubhubbub/wiki/AcceptingSubscriptionForPublishers?ts=1263982978&updated=AcceptingSubscriptionForPublishers>
I'd love to have everybody's opinion. Bob added a few comments and I'd
like to insist on the fact that this doesn't solve any copyright issue.
It just makes it a little easier for publishers to know about who
subscribed to their content.
I'd love to know what you guys think :). Please help me complete that!
Julien,
This is a good idea and proposal. Internally in TypePad we have a
proprietary mechanism which does something similar to this so that our
hub (which currently runs on Google App Engine) can find out if a
particular feed is hosted by TypePad.
I'm not so convinced about using this as a mechanism to prevent
copyright infringement, but since this particular use-case doesn't
require anything additional it seems mostly harmless, and doesn't seem
to allow a publisher to do anything that the publisher wouldn't be able
to do by running his own hub, which is already possible today.
Really this protocol is useful only between a particular federated hub
and publisher combination, but that's okay because hubbub considers hubs
and publishers to be pre-federated anyway by virtue of allowing the
publisher to choose which hubs it considers to be its "official" hubs.
The only real feedback I have is about your use of HTTP status codes.
If there is no entity body in the success case then specifying a 204 No
Content response makes more sense than 200 with an explicit
Content-Length of 0, though in the interests of being liberal the hub
should probably be instructed to accept any 2xx status code as a "yes"
and ignore the body entirely.
401 is the wrong response code for "no" because a 401 response is
usually expected to contain at least one WWW-Authenticate header
describing how the client might provide credentials to gain access. 403
Forbidden is closer in meaning to what you're trying to express here.
Finally, using the WebDAV 422 Unprocessable Entity to signal this case
from hub to subscriber seems a bit strange; is there a reason not to
just use 403 in this case too?
If a future revision of this spec includes a provision for the
subscriber to authenticate to the publisher and create some kind of
token that the hub can use to verify access then using 401 Unauthorized
might make sense for that transaction, but that largely depends on how
the protocol flow works for that case.
