-1. Don't see this as being necessary.
Thomas Broyer wrote:
>
> 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 ==
>
>
