RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

Comments intermixed...

		-----Original Message-----
		From:	Geoffrey M. Clemm []
		Sent:	Saturday, February 06, 1999 9:51 PM
		Subject:	Re: [long] Re: I-D

		Max: A thoroughly excellent (and excellently thorough)

		I'll respond to them in the context of
		(mailed a bit ago to this mailing list, and available on the
		web site).  This will give a preview of some of the
discussions that
		will take place at the upcoming design meeting.

		   From: Max Rible <>

		   My biggest issue with the new draft of the versioning
		   is the usage of gibberish temporary URIs where a user
might have
		   to cope with them or a system administrator might have to
clean them

		I agree.  I believe the argument to CHECKOUT, CHECKIN, and
		should always be a consistent human-comprehensible URL.

		[CK] This requires then that a checkout token be passed as
part of the request.
		        We can do this, but how then is a CHECKOUT different
from a LOCK?

		   Are there any actual cases where temporaries are actually

		   required, as opposed to a gibberish token that can be
used in
		   relation to a comprehensible URI?

		I believe the client should not need to be aware of the
location of
		any such temporaries.

		[CK] Agreed.  Clients should hide the protocol from the user

		   There is a certain utility to having the magic files in a
		   directory for ease of implementation-- you know you only
have to
		   treat a file in a special way if it's in a special
location.  In
		   my opinion, if you've already done the necessary work to
make MKREF function,
		   the additional amount needed to support checked-out files
		   configurations going anyplace should be small.

		I agree.

		[CK] How then does one quickly discover the defined

		   Is there a major flaw with the notion of CHECKOUT
creating a locked, 
		   mutable, non-autoversioned revision that the user holding
the lock can 
		   mutate arbitrarily until a CHECKIN is performed, at which
point the 
		   revision's name changes from a placeholder to a version

		I agree with the overall concept, i.e. CHECKOUT creates a
mutable resource
		at the specified URL, but I'd modify the following details:

		I wouldn't want it to be a "revision" because this places
		constraints on the mutable resource.  In particular, a
revision can
		have only one descendent on a given branch, but you
sometimes want to
		allow a revision to have multiple CHECKOUT's to a given
		(requiring a merge before any CHECKIN after the first).  But
I don't
		think that it being a "revision" was an essential part of
your point.

		Also, I would want the "lock" to be optional (I don't think
the "lock"
		mechanism scales well, and want it to be an optional part of
		versioning protocol).  Again, I believe this is not an
essential part
		of your point.

		[CK] The lock portion is option in -01.  I'm curious as to
why you don't
		        think the lock mechanism will scale?

		   CHECKOUT /foo/bar.html HTTP/1.1

		I'd add an (optional) "Workspace:" header, which you can add
		indicate that you are checking out into a non-default
workspace (a
		Workspace is the resource that specifies how revision
selection occurs
		across the entire web-site, via a "revision-selection-rule"


		   HTTP/1.1 201 Created
		   Location: /foo/bar.html
		   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
		   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

		I'd omit the Location header (it's always created at the
		specified by the CHECKOUT).

		The Revision-Id is no longer necessary, since you either are
		checking out into the default workspace, or you are checking
		out into a specific workspace.  In any case, your workspace
		determines which version you see, so no Revision-Id's need
		to be passed in requests or reponses.

		And I'd just use the LOCK command following the CHECKOUT if
I want a
		LOCK, rather than bundling LOCK with CHECKOUT (I don't
believe the
		frequency of CHECKOUT warrants worrying about an extra LOCK
method call in
		this case).

		[CK] Very confusing.  How did you identify the checkout?
You don't have
		        a lock-token and you used the same URL?  If you
return a reivision-id
		        then it is part of the revision graph by definition.
This doesn't make sense.

		[CK]  In order for a lock to make sense, it must be atomic
with the checkout.
		         As well, there must be interaction between lock and
checkout.  That is,
		         Non-versioning-aware clients that use LOCK must be
able to block
		         Versioning-aware clients otherwise they will clash
and non-versioning
		         Clients will not be able to react.

		[CK]  I also disagree with your premise about locks.  I find
that people frequently
		         want exclusive locks when they checkout a resource
even if they have
		         merge facilities.  It is a process issue.

		   and the combination of URI and Revision-Id can then be
used for any
		   number of PUT and PROPPATCH operations.

		I agree (replacing "Revision-Id" with "optional

		   When the user says

		   CHECKIN /foo/bar.html HTTP/1.1
		   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
		   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

		   the current version is frozen, given a non-temporary name
(such as "1.2.1"),
		   and the lock is released.

		Yes (replacing Revision-Id with optional Workspace-Id, and
making the
		Lock-Token optional, in case you checked it out without a

		[CK] I think the Workspace-Id concept is confusing and adds
an extra layer
		        of burden on clients.  Maybe I just don't get it.

		   If they UNCHECKOUT that URI/revision-id
		   configuration, the revision quietly goes away.

		Yes (i.e. the "working-resource" goes away).

		   The same thing applies to configurations:  do they need
to exist
		   in special areas?

		In draft-clemm-webdav-versioning, configurations have a much
		constrained purpose (and definition) than in
		In particular, they are effectively the mechanism for
defining an
		immutable-revision of a tree of resources (rooted at some
		They can then be specified in the revision-selection-rule of
a workspace to
		cause the appropriate revisions to appear in that workspace
at the
		appropriate URL's.

		To illustrate the characteristics of the more constrained
		I'll answer Max's questions as if they were asked about the
		constrained definition.

		*** NOTE ***
		Max would not have asked these questions about the more
		definition ... he would have known the answers given below!
But his
		questions and suggestions are very good for illustrating why
		more constrained definition might be preferable.
		*** END NOTE ***

		   Couldn't they be a part of a user's home
		   directory on a server?  Direct references would make it
		   to give the illusion of a configuration in your home
directory, but
		   now you have issues regarding cleaning up a user's files
		   moving their home directory from one machine to another
or removing
		   it entirely.

		Like other CM metadata such as a "branch" or a "label", you
would not
		normally expect to find one in your home directory.

		   Is a configuration so different from a collection that it
should be
		   treated as a separate sort of entity?  It looks like a
		   that has a special sort of name (the configuration ID)
and holds
		   nothing but MKREF-created links to particular versions of

		This is a read-only collection (it is immutable), and it is
just a flat
		list of revision references, with machine-generated names,
		mem1, mem2, mem3.  So it's nothing a human would ever
directly use to find
		a revision of a particular resource (but is *is* something
that a
		workspace could use to efficiently find such a revision).

		   (An aside:  should it be possible to use MKREF to link to
		   particular version of a file, allowing the reference to
provide the 
		   Revision-Id or Configuration-Id header to a client who
knows nothing 
		   of them?)  Are there any fundamental differences that
would make
		   it difficult to consider a configuration as a collection
		   some added rules and functionality?

		The creation of a configuration is an optimized
server-specific operation.
		Although it always results in a (read-only) collection, its
		and storage will depend on factors that would not allow
		creation or modification by a client.

		   Should configurations be able to contain other
configurations, or
		   simply references to them?  I can easily see that a
		   user might wish to partition it when it gets large and


		[CK] I can see why you would want to have a configuration be
based on
		         another, but I don't understand containment.  If a
configuration is
		         a revision selection or a "thread" selection, then
containment makes
		         no sense?

		   I'm thinking of software development solutions:  a
configuration might
		   represent a project, with subconfigurations containing


		[CK] So the disconnect is becoming more clear here.  In -01,
a configuration
		        is viewed a the selection of a revision or a
revision thread.  In this
		        context, a configuration would not be a project, but
the project at a
		        point in time.

		   You'd want automatic inheritance from the core project so
any time
		   someone else added a file to the configuration, you got a
		   to it.

		This is something you handle with workspace
		not with configurations (you can't add or remove files from
		a configuration is immutable).

		   A large project with a couple of dozen subprojects would
		   otherwise be a pain to bring into a workspace, unless you
had a
		   development tool that dealt with all the repetetive
actions for you.


		   (Direct references to other configurations could be used
		   provide the illusion of nested configurations, but would
		   a lot of transactions make the parent configuration and
then each
		   child configuration inheriting from the originals.)

		I'm not quite sure what this means, but I'd probably agree
with it
		if I did (:-).

		   Might there occasionally be call for having non-reference
members of
		   a configuration?  I could easily see a checkin set that
has no other
		   reason for existence than its membership in a workspace.

		Everything in a configuration is a reference to something
		(either a revision or another configuration).  To make
something be
		an immediate member would complicate the semantics with no

		   Regarding the specification of the BRANCH command:

		   Why was the decision made to use 

			  Content-Type: text/html
			  Content-Length: xxxx

		   instead of 

			  BRANCH /foo/bar.html HTTP/1.1
			   Revision-Id: VER:FHHR4959
			  Content-Type: text/html
			  Content-Length: xxxx

		I agree that it should be the latter (except that a
Workspace header
		rather than a Revision-Id should be passed in).  I also
prefer the
		method name "CHECKOUT-NEW", since this method is useful for
		non-branch based servers as well.

		   There has also been a massive growth in the number of
available DAV
		   properties.  PROPFIND allprop operations may lead to very
		   responses even with Depth: 1, which would slow down
		   for users due to network speeds.  It might be worthwhile
to add this
		   facet to the open issue ALLPROP_AND_COMPUTED.

		I believe strongly that defining useful properties should
		precedence over any desire that ALLPROP should run fast.  I
		would vote to just nuke ALLPROP as a mistake, but as long as
		clients know to never use it, I suppose it doesn't do that

		   Regarding SETDEFAULT:  why is it specified as sending an
XML body?
		   It it seems that 
			   SETDEFAULT uri HTTP/1.1
			   Revision-Id: DAV:none
		   is equivalent to the request with a body and consistent
		   other usages in the specification.  Are there other data
		   may be used with SETDEFAULT at some point?

		I believe SETDEFAULT is unnecessary, once you have the
notion of
		a default workspace, and therefore should be removed from
the protocol.


Received on Tuesday, 9 February 1999 01:52:34 UTC