Re: Review of draft-ietf-deltav-versioning-10.4/5

On Tue, Dec 05, 2000 at 02:35:49PM -0500, Geoffrey M. Clemm wrote:
>        From: Juergen Reuter [mailto:reuterj@ira.uka.de]
>...
>    Section 7.2: OPTIONS
>    - ------------------
>    > If the server supports checking out a version selector
> 
>    i.e. checking out a version selector is an optional feature and should
>    be moved to Optional WebDAV Versioning?
> 
> We're currently addressing this in a separate thread.  My proposal
> is that support for checking out a version-controlled resource be
> mandantory (since it is easy for both client-workspace and server-workspace
> servers to implement).
>...
>    Section 9.2: CHECKOUT
>    - -------------------
>    > A versioning server MUST support either version selector CHECKOUT or
>    > version CHECKOUT, and MAY support both.
> 
>    These two concepts should be explained somewhere (e.g. in the terms
>    section or in the introductory section).  As far as I understand,
>    version selector CHECKOUT is appropriate only when a single user
>    accesses a versioned resource?  And as soon as two or more users want
>    to access it, you need working resources and hence have to apply
>    version CHECKOUT?  If so, this should be somewhere explained (e.g. as
>    rationale or concepts, for example in the introduction).
> 
> I agree that these variants need to be better explained and contrasted.
> 
> I believe that we should break this up into three categories:
> public checkouts (in place checkouts, must be supported)
> client workspaces (working resources, optional)
> server workspaces (server side workspaces, optional).

Again: I disagree with this position. Especially now that you're trying to
attach a "mandatory" condition onto it.

What *should* be mandatory is that the client obeys the Location: header if
the server returns one on a CHECKOUT.

This automatically provides for both "public checkouts" and "client
workspaces" (to use your terms). If the server does not return a Location,
then you have a "public checkout." If the server returns a Location pointing
at a working resource, then you have a "client workspace."

This also satisfies your assumption that it is "easy." I'll tell you right
now that a public checkout is NOT easy for me (i.e. you're assuming too
much). Returning a Location header is cake.

Why do you suggest that a client should ignore a returned Location header?

Server workspaces are set up by the client manually, and that support is
detectable through OPTIONS.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 8 December 2000 07:14:34 UTC