> 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. .....Roy BTW, I can set the email@example.com 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).