RSS Content Negotiation

From RSS Extensions

Server-Driven Negotiation

This is a proposal for server-driven negotation of RSS content using the HTTP 1.1 Accept header. The header specifies which feed formats are acceptable to a given client, based on a combination of media type and module support.

The Accept request-header can be used to specify certain media types which are acceptable for the response. Any XML-based media that supports modularization is supported as a media type. Refer to the HTTP 1.1 specification for details on Accept header.

The m accept-parameter indicates which modules are acceptable for a given media type. The parameter contains a space-separated set of URIs. Each URI refers to a public identifier, typically the primary namespace, of a feed module to accept. The client will accept ANY of the specified modules.

If the Accept header is not specified then the response behavior is undefined. If the m accept-parameter is not specified then the set of accepted modules is undefined.

The degree of support by the server for the acceptable modules SHOULD bear on the quality measure. A measurement that is sensitive to module compatibility enables the acceptance of alternative modules. The quality measure SHOULD be less than 1.0 if any modules are not supported.

Examples

Here is a typical case where alternative modules can be accepted by the user-agent.

GET /feed.ashx HTTP/1.1
Accept: application/atom+xml; q=1.0; m="http://search.yahoo.com/mrss/ http://www.microsoft.com/schemas/rss/core/2005", application/rss+xml; q=0.7; m="http://www.itunes.com/dtds/podcast-1.0.dtd http://www.microsoft.com/schemas/rss/core/2005" 

Verbally, this would be interpreted as "I prefer Atom with Yahoo Media and SLX, but send me RSS with iTunes and SLX if it is the best available after a 30% mark-down in quality (indicating, for example, a lack of support for Yahoo media)."

Version History

0.1 - Initial Proposal

0.2 - Specified the behavior when 'Accept' header or 'm' accept-parameter is not present.