• David Galbraith, Wists
• Matt Mullenweg, Ping-O-Matic, WordPress

Summary

The goal of RSS Ping is provide richer metadata flowing across the ping stream. RSS Ping enhances what is currently sent with an extended ping with the equivalent of a single RSS or Atom item.

Currently a standard ping has the site name and site URI, an extended ping adds a RSS feed URI. We're expanding that to allow multiple feed URLs, authentication, and a payload. Payload content can have attributes to represent different types of payloads and an attribute indicating what type of MIME type.

Root element

rss_ping

The root element has one required attribute, version. The RSS Ping described by this specification is version 2 (where 2.0 is implied if there is no '.0').

Core Elements

Unless explicitly stated otherwise, there may be only one of each element.

site_name

The name or title of a site.

site_uri

The URI of the site's home page

feed_uri

The URI of the source feed for this fragment of content. There may be multiple feed_uri elements. Each element requires the type attribute. The type attribute consists of two parts, a single word name followed by a space and then a float version number. Type is case insensitive. Examples would be "RSS 2.0" or "RSS 0.92" or "Atom 0.3".

payload_hash_uri (optional; mandatory attribute: "SHA1" or "MD5")

The location of a SHA1 or MD5 hash of the contents of the payload, when pingserver-side (on-the-fly) authentication is used to verify the RSSping.

publisher_mbox_hash (optional; mandatory attribute: "SHA1" or "MD5")

Contains a SHA1 or MD5 hash of the email address for the primary contact, when publisher-side (pre-arranged) authentication is used to verify the RSSping.

Payload

payload

The payload element contains a feed fragment (defined as a single and self-contained item from a feed like a RSS item or Atom entry) or a feed with a single item.

The payload must contain a minimum of a: title or description or content or summary and: link or guid or permalink for the individual content item which is being updated. More generally, to allow for future formats to be used, the minimum requirements for the payload are a headline and uri, where exact element names can vary as long as they are semantically equivalent. Where the payload contains RSS or Atom, individual items or entries may be submitted, without surrounding channel or feed information. In this case the payload type should contain the string 'fragment', e.g payload type="Atom 0.3 fragment". Namespaces when using payloads which contain feed fragments. If a fragment of a feed is used which contains namespaced elements, to avoid 'dangling' namespaces, the payload element must contain relevant namespace uri attributes and the encoding type. e.g.<payload type="RSS 1.0 fragment" encoding="iso-8859-1" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/">

Authentication (draft)

Pingserver-side authentication.

Predecessors to RSS Ping require passing limited information to a ping server and then pulling content from an entire RSS feed and/or webpage. RSS Ping allows for spam free authenticated pings by sending content directly as a ping and checking a matching hash of the payload (MD5 or preferably SHA1), stored at the 'payload_hash_uri' on the publishers site.

(This is the preferred method of authentication for smaller publishers who nevertheless want to benefit from the advantages of RSS Ping)

Publisher-side authentication.

For a fully authenticated ping that requires no round trip by the ping server provider or aggregation service, the ping endpoint is a hash of site_uri+password+datetime (MD5 or preferably SHA1) where datetime is a single use token retrieved from ping server that sets up a onetime use endpoint to ping.

(This level of authentication need only be provided for larger publishers or people with particularly time sensitive information such as prices)

Sharing authenticated pings between ping server providers.

Any authorized ping server provider may place an authenticated flag in feeds based upon pings, or pings that are forwarded directly to another ping server to indicate which pings were authenticated, either as 'pingserver_side' or 'publisher_side'.

(Ping server providers may later negotiate their own security and authorization mechanism, collaboratively. Since the number of ping servers is expected to be much smaller than the number of publishers, ping server providers are analogous to certification authorities rather than service providers, no automated certicate or authentication system need be provided.)

Notes

Many sites, including larger publishers, are reluctant to send full content within feeds since it potentially reduces traffic to the destination site. Passing the full content is necessary for search engines to index content in real-time. It is proposed that a new type of content type, 'content type=tokenized' is used, whereby standard stop words such as 'and','of','the' are removed to produce text which cannot be re-published or read out of context, but which allows indexing for search engine purposes without crawling destination pages. This way, using RSSping with full content or tokenized content, information can be indexed directly as it is pinged, reducing the round-tripping that RSSping is designed to avoid.

Examples

Below are examples of pings sent via an http POST.
Alterative XML-RPC or SOAP enpoints may also be provided.

RSS ping with a single item RSS 2.0 feed as a payload:

RSS ping with an Atom 1.0 fragment (entry) as a payload:

RSS ping with an RSS 1.0 fragment (item) as a payload:

RSS ping with a single item RSS 1.0 feed as a payload: