RE: Representation consistency and content negotiation

The discussion seems to be couched in terms of URI and web architecture, but perhaps looking at it in the HTTP context would be more helpful. Content negotiation was a HTTP feature, not a URI feature.

I have the action item to rewrite the "content negotiation" section of the HTTP document as part of the IETF HTTP working group; I've finally started on this. My goal is to scope the utility of content negotiation in HTTP and to make it clearer when it is and isn't appropriate.

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81

       and 

http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-05#section-5 

In searching for the history of when and how content negotiation and variant resources got added to HTTP, I found a writeup which I took the liberty of publishing:
           http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0059.html



Larry

-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Drummond Reed
Sent: Monday, January 12, 2009 10:06 AM
To: 'Williams, Stuart (HP Labs, Bristol)'; 'www-tag'
Subject: RE: Representation consistency and content negotiation


Stuart, thanks very much - your answers are illuminating. See inline.

> -----Original Message-----
> From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com]
> Sent: Monday, January 12, 2009 3:24 AM
> To: Drummond Reed; 'www-tag'
> Subject: RE: Representation consistency and content negotiation
> 
> Hello Drummond,
> 
> FWIW, here's my take on your questions...
> 
> > -----Original Message-----
> > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
> > On Behalf Of Drummond Reed
> > Sent: 12 January 2009 08:13
> > To: 'www-tag'
> > Subject: 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.
> 
> Though not directly relevant to the question in hand, it may be worth
> noting that in general there is *no* prescribed relationship between the
> resources that are referenced by URI that differ only in scheme name.
> Specifically, http://example.com/ and https://example.com do not
> necessarily reference the same resource.

Yes, I'm clear on that. Interestingly, this is one identification issue that
XRI 3.0 will tackle with its XRI-as-relative-URI architecture
(http://wiki.oasis-open.org/xri/XriAsRelativeUri). The semantics of
XRIs-within-URIs will allow the same resource to be identified across
multiple URI schemes.

> > 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.
> 
> Ok... one thing to sharpen the question is that whatever a URI reference
> with fragID refers to should be consistent across representations. It's ok
> that not all fragIDs resolve in all representations, but those that
> resolve in multiple representations should have a consistent
> interpretation of what is being referenced.
> 
> See http://www.w3.org/TR/webarch/#frag-coneg

Thanks for that reference. I was aware of it but didn't realize how much of
a bearing it has on my question. To take a graph view of it (with XDI I have
graphs on the brain ;-), what you're saying is that the graph of information
associated with a resource must be consistent -- that's why fragIDs should
resolve consistently across representations.

> > 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?
> 
> The way that I would (like to) tell the story is that the users
> credentials condition the view of the resource (state) that the user is
> allowed access to.
> 
> Cookies shouldn't used as a means to identify say distinct shopping carts
> between users (though I'm sure it's done) - different resources should be
> blessed with different URI names.  So no, "...the cookie used to identify
> the requestor" should *not* be "...considered implicitly part of the URI
> of the resource." If you have distinct things that you want to be
> referencable by URI, then arrange for them to have distinct URI.

I understand. Ironically I'd guess that 90+% of the shopping carts out there
have the same URI and just use cookies to differentiate customers. I guess
they are taking the approach that each customer represents a different state
of the cart.

> > #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?
> 
> I say that that's ok if you can regard each of them as views of the same
> thing and that the convey a consistent if incomplete 'picture'.

Yes, that makes sense.

> > #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?
> 
> I think that from a WebArch/naming POV what is important (as mentioned
> above) is that given a URI reference it is consistently used to refer to
> the same thing. Across content-types the resulting representations should
> be of the same resource (whatever is deemed to be the resource in
> question). Where the referring URI has fragIds that in some sense refer
> into the resource, then those fragID targets need to at least have a
> consistent referent across all the representation-types in which they
> resolve. It's ok for fragID not to resolve in some particular available
> representation.
> 
> I think the direct answer to your iCal example is that it depends on what
> you frame the resource as being. If you consider busy/free time as just a
> different (summary) view of your schedule and that the URI is a reference
> to your schedule then that's ok (I think - provided fragID 'semantics' are
> respected across representations). If you regard your busy/free time as a
> related, but distinct, resource from your schedule then connneg for the
> purposes of distinguishing the views is probably best avoided. Maybe think
> of it like this, if what you might want to say *about* the resource is
> dependent on which 'view' of it one is considering then you are probably
> thinking of multiple resources that have been accidentally conflated into
> one.

So to summarize what you are staying: two content types could return
different subsets of information about the same resource as long as those
subsets are subsets of a consistent graph of information about the resource,
but if the content type requested changes the graphs of information returned
to a different, not-consistent graphs, that's where you should clearly use
different URIs.

That seems like a clear rule. (Talking in graphs always seems to help clear
these things up for me.)

Best,

=Drummond

Received on Tuesday, 13 January 2009 01:11:23 UTC