http://www.intertwingly.net/wiki/pie/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 [EMAIL PROTECTED]
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.
[EMAIL PROTECTED]@ 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 ==
--
Thomas Broyer
