W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1996

Re: Seiwald Q & A -- "GET for EDIT" cookies

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Tue, 03 Sep 1996 15:24:04 -0700
To: Christopher Seiwald <seiwald@perforce.com>
cc: w3c-dist-auth@w3.org, www-vers-wg@ics.uci.edu
Message-ID: <9609031524.aa13886@paris.ics.uci.edu>
> 1. What about Content-Version and Derived-From? (Dan Connolly)  
> 	If I read the spec right, Content-Version reflects the contents
> 	of the document.  That is, if the same document is dished up
> 	twice it is supposed to have the same Content-Version value.

It reflects the contents of the Entity, which includes both the body
document and the entity-header fields (metainformation about the document).
If the server is providing different information per checkout, then it
is in fact changing the entity.

> 	As I argued before (and will continue arguing until I wear people
> 	down :-) the identity of the source is not sufficient information
> 	for a "checkin", because the VC system underneath the version-aware
> 	web server may wish to find any context associated with a prior
> 	"checkout".  
> 	Now Roy Fielding says that Content-Version is opaque and could
> 	be used exactly for this purpose, 'cause no one would be the wiser
> 	if the Content-Version were different for each checkout of the
> 	same document.  This is true, but now the names of these fields
> 	are losing their meaning, no?  If it's checkout context, call it
> 	"Checkout-Context" (or "Checkout-Cookie").

Checkout does not have meaning on all systems, whereas version has a generic
meaning (at times, too generic). It is intended to be as flexible as possible.
The "Content-" prefix is a requirement of MIME for what HTTP calls
entity-header field names.


BTW, I can set the www-vers-wg@ics.uci.edu list Reply-To at any time --
the reason it is not on by default is that many people find it annoying,
particularly when you have cross-list discussions (like this one).
Received on Thursday, 5 September 1996 12:33:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:08 UTC