UserPreferences

PaceContentNegotiationSection


Abstract

Adds a section (explicitly) dealing with content negotiation.

Status

Open (ThomasBroyer)

Rationale

Some implementors wants to do content negotiation on their resources (for example, serving a collection as an Atom Feed, an RSS feed or as HTML, serving entries as Atom or HTML, serving "media link entries" and "media resources" at the same IRI, etc.). Others have expressed interogation about whether a server could use content negotiation and how their clients should behave (i.e. sending the appropriate Accept-* request-header fields).

Conclusion: content negotiation needs to be (explicitly) discussed in the spec.

Proposal

Add a new section in draft-atom-protocol-09 to explicitly deal with content negotiation:

11. Content Negotiation

  Servers MAY use content negotiation as described in section 12 of
  [RFC2616], and in [RFC2295] and [RFC2296]. Clients SHOULD then
  send a appropriate Accept-* request-headers in their requests. For
  example, if the intention of a client is to retrieve the Atom Entry
  Representation of an Entry, it should send an Accept request-header
  listing application/atom+xml with a high "q-value", for example:

     Accept: application/atom+xml, */*;q=0.5

  If the content of an Entry is a JPEG image as in the example of
  section 8.3.2 and the client wants to retrieve the JPEG image, it
  should send an Accept request-header listing image/jpeg with a
  high "q-value", for example:

     Accept: image/jpeg, */*;q=0.5

  Given that "atom:link" elements cannot give more information than
  a media type and language, servers SHOULD NOT base content
  negotiation on other attributes of representations. These attributes
  are negotiated based on the value of the Accept, Accept-Charset
  and Accept-Language request-header fields.

  [@@ should we add a note about content encodings? given that
  they cannot be exposed in atom:link or app:collection elements@]

  Note to implementors: it is good practice to associate an IRI with
  each representation of a resource, with the server sending a
  Content-Location header in response for which content negotiation
  was performed.
  [@NOTE@ rationale:
   http://bitworking.org/news/WebServicesAndContentNegotiation @]

  [@@ should we add a note about languages, and issues I enlightened
  in my mail to the list ? --see the Rationale section for a link-- @]

Impacts

Makes things clearer

Notes


CategoryProposals