Cookies! What are they and do we need them?

At 12:51 AM 9/1/96, Daniel W. Connolly wrote:
>In message <c=US%a=_%p=msft%l=RED-44-MSG-960901001030Z-22529@mail.microsoft.com
>>, Yaron Goland writes:
>>The Derived and Version headers would not be able to handle a situation
>>where you check out the same document from several different locations.
>
>Interesting claim. Would you please elaborate, giving the argument
>behind it? What about that scenario could Derived-From and
>Content-Versio not handle/express?

  I don't really think that we should be trying to standardize a policy for
this, as it seems a higher-level issue than basic versioning support, but
the idea is that I might check the same file out 3 times from the same
server, creating 3 virtual sessions. When I later check the file back in, I
may need to attach a particular update to a particular checkout operation.
The cookie enables this (did I get it right, Chris?).

  The kind of solution that youare thinking of does not allow that kind of
control: a server could let me check out v 2.1 of /docs/misc more than
once, and on check in the "Derived-from:" header does not uniquely identify
which of the 3 checkouts is being affected. This is because they would all
share the same "Derived-from:" header.

   My proposal tries to make locking, version-id assignment, authorization,
and update as orthogonal as possible. A "LOCK" operation declares an
intention to write. A system like Chris's would be able to assign a final
version number at "LOCK" (check-out) time, so that the version identifier
that my final "PUT" would specify would also serve the function of a
cookie. Access control can then determine whether I am authorized to make
that PUT request based on my identity, as determined by existing HTTP
mechanisms. I want to make the detailed semantics of LOCK server-dependent,
so that many server policies can be provided. This does have the drawback
of introducing confusion, since LOCK is a bit of  misnomer. (would
RESERVE/RELEASE be better?)

    Having 3 operations involved for an updating operation
(LOCK/PUT/UNLOCK) also lets client and server negotiate version identifier
at 3 separate points in time, so that a version identifier can be assigned
by server or client, either at the request for the resource, the update
operation itself, or the relase of the resource. A server is always free to
assign a version identifier to a client on any of these operations, and the
client is free to suggest a new version identifier, at each point,
dependent on server approval.

   Does this make Chris's point, and my proposal both a bit clearer?

  -- David

PS. Note that I am sending only to the two lists; this replying is getting
me 3-5 copies of each note.

--------------------------------------------+--------------------------
David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/

Received on Sunday, 1 September 1996 15:25:41 UTC