Fully document RSS support in the spec

[GoogleCodeExporter]

Nuff said

Original issue reported on code.google.com by bslatkin on 16 Sep 2009 at 11:00

[GoogleCodeExporter]

Concerns from an email thread with Jay:

> The Atom format provides all the envelope that is required here. As long as 
you
have a MIME type, you can put just about anything you want into atom.content.
>
> Also, Section 7.3 of the current spec says:
> "A content distribution request...  MUST have a Content-Type of
application/atom+xml and a request body of an Atom feed document with the list 
of new
and changed entries."
>
> The way I read this is that while a hub may read RSS, it should publish Atom. 
This
simplification seems to me to be a good thing that will make it easy for 
developers
to write code and know what to expect in what they receive.
>
>     I was very much hoping that the spec document simply hadn't been updated 
with
RSS support, yet.  (As per "RSS [RSS20] is supported and working in the 
reference
hub, but not yet well-defined in this specification.")
>
>     If it's truly the case that all publication must be done in Atom format, 
then I
feel that the claim of "RSS support" is patently false.  It means that the 
protocol
doesn't support RSS at all, and that the intermediary fetcher is the one 
handling RSS
publisher updates.

Original comment by bslatkin on 16 Sep 2009 at 11:01

[GoogleCodeExporter]

I think that the most important updates concern 7.3, as described above, and 7.5
which needs to describe how RSS should be handled in aggregated delivery.  (Is 
it a
MUST convert situation?)

From Brett's followup:

"Sorry I meant to respond to this part specifically. The Hub MAY
preserve the content type of the original stream or change it. That
should also be documented in the spec. The reference hub
implementation (and thus the Google hub) preserves the source feed's
format (including RDF RSS). I believe Superfeedr normalizes to Atom."

Original comment by jrossi...@gmail.com on 16 Sep 2009 at 11:26

[GoogleCodeExporter]

Heard more input about this. Apparently this section is confusing people 
thinking
hubs MUST transform the content into Atom. This is false. The content MAY pass
through unchanged in the original format or it MAY be transformed by the hub
following its own internal policies.

Original comment by bslatkin on 18 Sep 2009 at 10:29

[GoogleCodeExporter]

From Rogers:

-----------

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
http://www.rssboard.org/rss-specification

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.

Original comment by bslatkin on 23 Sep 2009 at 7:08

[GoogleCodeExporter]

#3 bslatkin: 

"The content MAY pass through unchanged in the original format or it MAY be 
transformed by the hub following its own internal policies."

spec 0.2 / 7.3 says:

"This request MUST have a Content-Type of application/atom+xml and a request 
body of 
an Atom feed document with *the list of new and changed entries*."

Does 'pass through unchanged' mean that it could pass through including 
*unchanged* 
entries? This would tremendously simplify hub implementations while relying on 
functionality in existing aggregators. 

Original comment by lxba...@gmail.com on 25 Oct 2009 at 4:18

[GoogleCodeExporter]

Technically speaking, the subscriber should be able to handle unchanged entries 
as
well as new or changed, but that's not what this is referencing.  This is 
speaking
specifically to the format of the entries, not content.

Original comment by jrossi...@gmail.com on 25 Oct 2009 at 4:22

[GoogleCodeExporter]

I have the opposite issue. Going with the spirit of putting complexity into the 
hub I
would like to be able to tell the hub that I only want the content type
application/atom+xml and the hub should take care of transforming RSS feeds. 
The spec still clearly says that the POST content type header MUST be
application/atom+xml but the reference implementation on
http://pubsubhubbub.appspot.com sends the following header for one of my feeds

Content-Type: application/rss+xml

Is there a way to make a subscription that forces RSS->Atom conversion?

Joerg

Original comment by jbeck...@gmail.com on 18 Nov 2009 at 12:33

[GoogleCodeExporter]

> Does 'pass through unchanged' mean that it could pass through including 
*unchanged*  entries? This would tremendously simplify hub implementations 
while 
relying on  functionality in existing aggregators

Yes. Other data may be provided as context. This is covered in section 4 ("Atom 
Details").

Original comment by bslatkin on 9 Feb 2010 at 3:56

• Added labels: spec0.3

[GoogleCodeExporter]

Addressed in 0.3 draft spec

Original comment by bslatkin on 9 Feb 2010 at 6:05

• Changed state: Fixed