HTTP mods: Variants, Derived-From:

Tim Berners-Lee <>
X-Delivered: at request of secret on
Date: Tue, 12 Oct 93 09:49:39 +0100
From: Tim Berners-Lee <>
Message-id: <>
Subject: HTTP mods: Variants, Derived-From:

I have changed
in two ways.  One is to merge the live-uri: and version-uri: fields
into one uri: field with a "vary=" parameter to speecify the  
granularity of the URI in
question, as I proposed on the list a week of so ago, with no  

I have added the obvious "Version:" field for symetry with
Content-Type: and Language: which are all now variant specifiers.
I have also added "Derived from" which is necessary to keep
track of parallel modifications a la CVS/RCS/SCCS/CMS etc.

I append some cut and splurdge from the spec.

Tim Berners-Lee


This gives a URI with which the object may be found.  There is no  
guarantee that the object can be retrieved using the URI specified.  
However, it is guaranteed that if an object is successfully retrieved  
using that URI it will be to a certain given degree the same object  
as this one. 

If the URI is used to refer to a set of variants, then the dimensiosn  
in which the variants may differ must be given with the "vary"  

	Syntax		URI: <uri>  [ vary = dimension [ , dimension  
]* ]
	dimension	content-type | language | version

If no "vary" parameters are given, then the URI may not return  
anything other than the same bit stream as this object.

Multiple occurencies of this field give alternative access names or  
addresses for the object.



This indicates that retrieval given the URI will return the same  
document, never an updated version, but optionally in a different  

		    vary=content-type, language, version

This indicates that the URI will return the smae document, possibly  
in a different rendition, possibly updated, and without excluding the  
provision of translations into different languages.


This indicates that accessing the URI in question will return exactly  
the same bitstream.


	This is a string defining the version of an evolving object.  
Its format is currently undefined, and so it should be treated as  
opaque to the reader, defined by the informatiuon provider.  The  
version field is used to indicate evolution along a single path of a  
partucular work.  It is NOT used to indicate derived works (use a  
link), translations, or renditions in different representations.

Note: It would be useful to have sufficient  semantics to be able to  
deduce whether one version predated or postdated another.  However,  
it may also be useful to be able to insert a particular local code  
management system's own version stamp in this field.  Typically,  
publishers will have quite complex version information containing  
hidden local semantics, giving value to the idea of this field being  
opaque to other readers ofthe document.

When an editied object is resubmitted using PUT for example, this  
field gives the value of the Version . This typically allows a server  
to check for example that two concurrent modifications by different  
parties will not be lost, and for example to use established version  
management techniques to merge both modifications.