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