Re: Version identifier in URL
Jim Whitehead (ejw@ics.uci.edu)
Thu, 30 May 1996 17:40:46 -0700
Larry Masinter writes:
>Separate out the problem of
> a) construct a URL for a previous version of a resource
> given the current version of a resource and information
> about the server's versioning system
> b) determining from two URLs what their version relationship
> might be.
>
>I think it's reasonable to use URL-decoration for (a) and not for (b).
I find this concisely describes the different approaches of employing the
URL parameter or URL query field vs. the link meta-information approach.
Larry Masinter later writes:
>Well, there's already precedent for form URLs, for example, e.g.,
>
> http://host.dom/form-handler?x=a+y=b+z=c
>
>even though the client treats any URL it receieves as 'opaque', they
>can still be constructed. I see some value in just continuing this
>tradition for versions.
>
>In fact, how about making a "version" just a special kind of
>query?
Dan Connolly agreed, stating:
>Fair enough. ?version=xxx seems reasonable for (a)
Thus, there appears to be some agreement that employing the URL parameter
or URL query field would be useful for specifying the version of an entity.
However, it is not entirely clear to me what the tradeoffs are between
using the URL parameter mechanism (e.g., ";version={version identifier}")
versus using the URL query mechanism (e.g., "?version={version
identifier}"). Can any members of the list shed some light on the intent
of these two mechanisms? This information is unavailable in either the
HTTP specification or RFC 1738 (Uniform Resource Locators).
I agree with David Fiander's comment:
>Two more things: 1) if we're not supposed to use URL parameters,
>why are they in the spec? and 2) the URL parameter makes sense,
>because one can think of different revisions of a document as
>different documents, much like the VMS or ISO 9660 filesystem
>method of indicating different file revisions with a ";revno" on
>the file name.
- Jim Whitehead <ejw@ics.uci.edu>