Representation consistency and content negotiation

At the risk of opening up a Pandora's box, some related questions have come
up recently about which it would be good to get the TAG's view.

They are about the consistency of resource representations and the limits of
content negotiation as discussed in AWWW [1].

A rule that OpenID folks, XRI TC folks, and others working on metadata
discovery have been following since it was clarified for us last summer is
that an http: or https: resource that responds to a GET request with a 2xx
can return a representation of the resource in any content type it supports,
BUT that representation SHOULD (or MUST?) be a consistent across content
types.

For example, from the same URI it's okay to return versions of the same
document in HTML, PDF, and plain text depending on the content type
requested. But it's not okay to return a descriptor of the document (such as
a POWDER or XRDS file) instead of the document itself.

How does that rule apply in the following situations:

#1: Requestor-dependent representations. Many sites return different
versions of a web page based on who is requesting it, such as a personalized
homepage. How does that fit with the rule? Is the cookie used to identify
the requestor considered implicitly part of the URI of the resource?

#2: A related use case is requestor-dependent access control. For example is
it okay for a request to the same URI to return a full web page for one
fully-authorized requester and a redacted version to another
less-fully-authorized requestor?

#3: Content type-dependent representations. Can the view of a resource
returned from a URI as expressed by one content-type differ from the view
expressed by a different content-type? For example, from the URI for a
person's web calender, could a request for text/calendar (the ical content
type) produce one response, while a request from the same URI for
text/free-busy (a fictional free-busy content type) produce another?

Thanks for any guidance.

=Drummond 

[1] http://www.w3.org/TR/2004/REC-webarch-20041215/

Received on Monday, 12 January 2009 08:13:34 UTC