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

This looks fundamentally quite good; it covers all the versioning
scenarios I've ever encountered and more.  Kudos to the authors
who must have put in some very long hours on it!

***

My biggest issue with the new draft of the versioning standard
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
up.  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'm thinking usability here:  if incomprehensible, unmemorable temporary 
names are being used in WebDAV, it should be easy to make the usage 
[a] seamless from the point of view of the end user and [b] straightforward 
for the system administrator who will inevitably have to clean up
the incomprehensibly named files cluttering the temporary area.
Is the intention here that a client program would use PROPFIND
to locate all these obscurely named resources?  That all such
resources have a lifetime and will automatically be reaped?

There is a certain utility to having the magic files in a magic
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 and
configurations going anyplace should be small.

***

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 number?  
(i.e.  
CHECKOUT /foo/bar.html HTTP/1.1
Host: www.foobar.com
...

returns

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

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

CHECKIN /foo/bar.html HTTP/1.1
Host: www.foobar.com
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.  If they UNCHECKOUT that URI/revision-id
configuration, the revision quietly goes away.

***

The same thing applies to configurations:  do they need to exist
in special areas?  Couldn't they be a part of a user's home
directory on a server?  Direct references would make it possible
to give the illusion of a configuration in your home directory, but
now you have issues regarding cleaning up a user's files when
moving their home directory from one machine to another or removing
it entirely.

***

Is a configuration so different from a collection that it should be
treated as a separate sort of entity?  It looks like a collection
that has a special sort of name (the configuration ID) and holds
nothing but MKREF-created links to particular versions of files.
(An aside:  should it be possible to use MKREF to link to a 
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 with
some added rules and functionality?

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

I'm thinking of software development solutions:  a configuration might
represent a project, with subconfigurations containing subprojects.
You'd want automatic inheritance from the core project so any time
someone else added a file to the configuration, you got a reference
to it.  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 to 
provide the illusion of nested configurations, but would require
a lot of transactions make the parent configuration and then each
child configuration inheriting from the originals.)

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.

***

Regarding the specification of the BRANCH command:

Why was the decision made to use 

       BRANCH VER:FHHR4959 HTTP/1.1
       Host: www.foobar.com
       Content-Type: text/html
       Content-Length: xxxx

instead of 

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

?

The current method makes for a great deal of extra work, and seems
inconsistent with the other usages in the specification.  Without
this, revision IDs need only be unique for a given resource; now, they
must be unique across an entire server.  I was originally expecting
that a lot of "Revision-Id" headers would be exactly the same as the
version number in your source control system; requiring revision ID's
to be unique across all files would make the raw data less readable
to human beings.  (This should also be called out explicitly in
2.10.1, which only specified that it must identify a specific
revision of a given resource.)

This also creates a complication for developers attempting to
implement the WebDAV standard.  If the WebDAV functionality is provided
as a plug-in module for an existing web server, that server might 
wind up doing some extra work in attempting to resolve a rather
mysterious URI-- lacking a leading slash, it might reject it 
entirely.  (Netscape Enterprise Server 3.5.1, for instance, will
immediately return 404 Not Found without even talking to plugins
registered for the method used.)  Granted, this isn't illegal by
the HTTP 1.1 standard, but it could certainly delay the progress
of WebDAV until the server technology has a chance to catch up.
If there's no strong reason to go with BRANCH revision-id, I
suggest switching to BRANCH uri.

***

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

***

I presume that the results of asking for DAV:defaulthistory,
DAV:activecheckouts, DAV:directlineage, and DAV:fulllineage
should *not* be included in a PROPFIND allprop response?  Also, don't
the new PROPPATCH parameters violate WebDAV spec 12.9.1, since an
identical DAV:href is turning up in multiple DAV:response
tags under the same DAV:multistatus?  (It's probably worth just
making an addendum to the WebDAV spec in the grammar section.)

***

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 with
other usages in the specification.  Are there other data that
may be used with SETDEFAULT at some point?

-- 
%% Max Rible %% max@glyphica.com %% http://www.amurgsval.org/~slothman/ %%
%% "Before enlightenment:  sharpen claws, catch mice.                   %%
%%  After enlightenment:  sharpen claws, catch mice."            - me   %%

Received on Monday, 1 February 1999 22:56:30 UTC