Spec Revision Suggestions

Skip to first unread message

Rogers Cadenhead

Sep 23, 2009, 12:58:34 PM9/23/09
to Pubsubhubbub
I've been looking over the spec as I implement portions of it,
starting with the feed publisher's portion.

Although it mentions that PuSH works with RSS feeds, the spec is
written in a way that obscures this fact and may cause some RSS
publishers to think that it isn't for them. I'd like to suggest the
following revisions:

1. In the Abstract, make the first sentence "An open, simple web-scale
pubsub protocol for feeds in Atom and RSS formats, along with an open
source reference implentation targetting Google App Engine." by adding
the clause "for feeds in Atom and RSS formats".

2. In Definitions, change the Topic definition to the following:

An Atom [RFC4287] or RSS [RSS20] feed URL [RFC3986]. The unit to which
one can subscribe to changes. Further, this spec currently only
addresses public (unauthenticated) feed URLs.

3. In Atom Details, change the first sentence to "Notification format
will be Atom [RFC4287]."

4. In Discovery, in the first sentence, change "retrieving the Atom
feed" to "retrieving the feed".

Also, I think I found an error:

5. In Definitions, in the Notification definition, change "The format
of the notification will be an Atom feed served by the publisher" to
"The format of the notification will be an Atom feed served by the
hub". If I understand the spec correctly, the notification is served
by the hub to feed publishers, not by publishers.

Finally, I'd like to propose that in the References section, the spec
reference the RSS Specification at

I'm a member of the RSS Advisory Board, and we've been publishing the
specification since 2003. Our most recent revision was March 30, 2009.

I have some more suggestions for how the spec uses topic, source and
feed URL to all refer to the same thing -- the feed that's monitored
for updates. But I'll wait until these ideas have been evaluated.

Brett Slatkin

Sep 23, 2009, 3:10:24 PM9/23/09
to pubsub...@googlegroups.com
Hey Rogers,

I've added this info to the issue we're using to track this:

I plan to incorporate your revisions into the existing 0.2 spec as
soon as I can, since it does not reflect a change to the current,
common practice that Hub implementations have in the wild; it's just a
clarification of how it really works/should work.

Thanks and keep the feedback coming!


Reply all
Reply to author
0 new messages