RE: FW: Http.ow and jar-diagram-7.pdf l (was RE: JAR conflict for July 7 AWWSW telecon)

Hello Jonathan, 

> -----Original Message-----
> From: Jonathan Rees [mailto:jar@creativecommons.org] 
> Sent: 15 July 2009 02:29
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: AWWSW TF
> Subject: Re: FW: Http.ow and jar-diagram-7.pdf l (was RE: JAR 
> conflict for July 7 AWWSW telecon)
> 
> On Mon, Jul 6, 2009 at 11:47 AM, Williams, Stuart (HP Labs,
> Bristol)<skw@hp.com> wrote:
> >> [JAR] I would rather remove the date/time so that we can 
> more often say
> >> the same representation corresponds to multiple resources, a la the
> >> genont theory. I have no idea how carefully last-modified is
> >> maintained by servers and proxies; perhaps what you 
> suggest will work.
> >
> > I don't know either - I expect that for things based on 
> filing systems last modified come straight from there. For 
> things that are the output of processes... Last modified 
> either relates to some underlying storage (if the information 
> is available from there) or is 'now' - modulo possibly some 
> server side caching that mitigates constantly recomputing the 
> same responses - eg. I use a CMS for my canoe club web site 
> [1] which caches the composite pages that it builds.
> >
> >> Let's try to figure this out over the coming months...
> >
> > Ok...
> 
> I thought of the following case: Consider 302 and 307 redirects from a
> URI to A URI B (Location: B). 2616 talks of the resource residing
> elsewhere, but I would choose to interpret the redirect as saying that
> representations corresponding to B are, for the time being, also
> representations corresponding to A. I have also chosen to interpret
> "Last-modified:" to mean that the representation has been a
> representation of the requested resource (the one named in the GET
> request leading to the 200 response containing the Last-modified:
> field) since the given time.

Ok... So in the case of a followed redirection (of whatever kind) from A to B, the request URI in the request that corresponds to the 200 response would be URI B, right?

> So how do go from a statement that Z has been a representation of
> resource B since time T, to a statement that Z has been a
> representation of A since time T?

I suppose that part of the 'trickiness' here has to do with both Roys formulation of a resource and TimBLs original 'cool URIs don't change' mantra.

Roy describes (a model) of a resource as a mapping function from time to {sets of equivalent representations} or {URI}. However there is also an additional mapping fron URI to resource (ie. To mapping function). As we know, the stability of the URI to resource mapping is in question (site reorganisation, domain name 'ownership' changes...).  

301 and 302's tell us that the resource has changed its location (in web space), changed its address or its name. So... For a period of time the resource is named by the URI A and for a different period of time the resource is named by the URI B - but, if we take 301/302 at face value... it's the same resource. 

You speak of "representations of A" which I read as "representation of the resource named by A", and like wise for B. A 301/302 is saying that both A and B are references for the same resource (over some temporal scope). 

[BTW: I continue to persist in the view that it is the web and the web infrastructure that is being asked to provide representations and which, in a sense, inspects the resource, as opposed to the resource being the agency of its own responses - which allows me to avoid the 'tangle' of whether a change of location necessarily means a change of resource - because the machinery producing the responses may also have changed]

Aaaaghh... just been and looked at 301/302/307... What a mess! http://sebastians-pamphlets.com/the-anatomy-of-http-redirects-301-302-307/#redirect-recap is interesting on the topic. Also, http://kendsnyder.com/archives/15-HTTP-Status-Codes-302,-303,-and-307.html

I guess we are in another space here wrt to what the specs. say and how things are actually used in practice.


>  To me this doesn't follow, but I
> can only come up with a counterexample as a thought experiment:
> Suppose we have a current-version resource A advancing to new versions
> from time to time. Suppose that this is implemented not by varying 200
> responses, but by modulating 302 or 307 redirects, so that as A
> advances from V1 to V2, its representations change from those of some
> resource B1 to being those of some other resource B2. Now suppose that
> a representation of B2 is made available (as a draft, say) in advance
> of this switchover for A. The repr. of B2 has some Last-modified: that
> precedes the point in time at which it becomes a representation of A.

By Roy's defn, two resources can only be the same *if* they have the same mapping function over all time. As you describe A and the Bn here that is not the case - none of the Bn named things are the same as the A named thing or (in general) other Bm (n<>m) named things - there they provide identical representations of a moment.

> Kind of twisted? So tell me how where I've gone wrong, and what the
> better story is? Are representations you get via redirection not
> representations that correspond to the originally requested resource,
> as well as to the redirect target?

Whilst I don't know that I buy the argument I've been using... 301/302 and 307, if used correctly, all tell you that the same resource has alternate names, with more or less encouragement to perist in using the original name or the redirection target name. 307 appears to have arisen as an HTTP 1.1 replacement for 302 to address of misuse of 302.

If you've gone wrong anywhere, its in an possible assumption that different names necessarily refer to different resources. If one thinks of the URI pointing slots in a sorting office and the resources as being the things that occupy those slots and web get requests as returning awww:representations of whatever thing is in the slot indexed by the URI - 301/302/307 is about reflecting a change of the slot in which the resources resides. [But "...cool URIs..." oh yes they do sometimes and 301/302/307 are about trying to ameliorate the problems when they do].

> 
> Jonathan
> 

Stuart

Received on Wednesday, 15 July 2009 09:21:42 UTC