on cacheability of 307 responses

I think that a 307 response shouldn't mean that the Location: URI
refers to the original resource, but instead means that
representations of the resource identified by the Location: URI are
representations of the original resource, for some time interval.

As Stuart pointed out, this isn't justified by the spec, but I think
it is the only interpretation that is useful in conjunction with
careful RDF modeling. Remember that the goal in RDF is to come up with
"satisfying interpretations" for graphs. So we need to come up the
right graphs (translation of HTTP exchanges to RDF) and with a
plausible story around which "satisfying interpretations" we have in
mind. Since RDF doesn't have an explicit treatment of time, we have to
decide, for each URI, how that URI is to be interpreted over all times
we might care about. In principle we could talk about generating
different RDF graphs at different times, each with a different
interpretation for its URIs, and give up the ability to accumulate and
compare evidence (or assert invariants) about resources through time,
something that I would really like to be able to do - in particular
you need this to explain Tim's notion of "time invariant"
axiomatically.

If we decide to continue with my programme of time-limited
"correspondences", I think that an account of 307 will have to have a
similar class of time-limited "redirections".  The lifetime of a
redirection is stated in the caching information conveyed in the 307
response. So if we have a member of Redirection from U to V whose
lifetime contains [t1,t2) and a Correspondence of Z to V whose
lifetime contains [t3,t4), then this would imply the existence of a
Correspondence of Z to U whose lifetime contains [max(t1,t3),
min(t2,t4)).  Right?  That is, the 307 asserts a "window" during which
representations of V also are representations of U.

I think this is similar to Roy's treatment of redirects, which puts
them on a more or less equal footing with representations.

(I thought tracker had created issues for us... apparently not)

Received on Monday, 30 November 2009 15:17:37 UTC