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

Comments below...

-----Original Message-----
From: Max Rible [mailto:max@glyphica.com]
Sent: Monday, February 01, 1999 7:55 PM
To: WEBDAV WG
Subject: [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!

[CK] Thanks!

***

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?

[CK] The point of using "giberish" in the draft is to reinforce
     that the server determines the value.  A server could make it
     giberish or something else.  One limitation we have is the
     strong reluctance in IETF to "munge" URLs.

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?

[CK] I think it is important to remember that these are protocol-level
     resources.  I would assume that the UI on top of the protocol hides
     all this.  For example, you "checkout" and "checkin" based on the
     resource name you desire.  The working copy resource is part of the
     implementation and isn't visible to the user.  As well, there is
     always the DAV:displayname property.

[CK] That is really a per-server administrative function.  A server may
     choose, for example, to put all working copies in /tmp/wc.  As well,
     they might choose to have a lifetime.  Although that is dangerous 
     because many systems support long-running checkouts.  Especially if
     the checkout doesn't involve a lock.  That is, it will merge on
     check-in.

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.

[CK] The general idea was that this is up to the server.  A "checkout"
     request returns the location/URL which is managed by the server.

***

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.

[CK] I don't think so.  The idea is that a CHECKOUT creates a working copy.
     Technically this is not part of the revision graph for the resource.
     It must be mutable because clients need to be able to make multiple
     changes.  You can't version it because it isn't part of the version
     graph.  It is just a scratch space where PUTs and PROPPATCHs can be
     performed until the resource is ready.  CHECKIN then assigns a revision
     id and makes it part of the graph.  Working copies don't have revision
     ids.  Also, UNCHECKOUT cancels a CHECKOUT.  You can't issue UNCHECKOUT
     once you've issued a CHECKIN.  The draft should be clearer on this
point.

***

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.

[CK] The idea here was to put them in a unified place so that standard
     DAV discovery mechanisms can be used.  Otherwise we need to add
     new methods to discover the configurations.  These would be exactly
     the same as the normal folder discovery mechanism, just under a 
     new name.  We could do that -- we were just trying to use existing
     DAV semantics where appropriate.

***

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?

[CK] Configurations are very similar, but also very different.  A
     configuration collection can be referenced in the Configuration-Id
     header.  That is not true of all MKREF collections.  As well, changes
     to the resources in the context of a configuration are automatically
     represented inside the configuration collection.  That is, if I
     rename foo.htm to bar.htm using MOVE in the /c/1 configuration, then
     inside /c/1 there will be a reference to bar.htm.

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.

[CK] This is a really interesting question.  Conceptually, why not?
     However, that is really hard to represent in the resources.  As
     well, some of the semantics start to get really messy.  What does
     it mean to have nested configurations?  What does it mean for a
     resource to be "in" nested configurations.  We opted to say that a
     configuration can be derived from another, but there isn't a notion 
     of containment.

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.)

[CK] Another way to think of this is that the collections in the
     namespace represent the project and sub-project relationships
     and that configurations represent various "releases" of those
     projects.  In this way the "V2" configuration can be derived
     from the "V1" configuration.

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.

[CK] The idea here was that configurations are a way of grouping resources
     that exist in the DAV namespace.  Our thoughts were that you have
     resources and make them part of configurations.  That is /foo/bar.htm
     is a resource whose revisions might be part of zero or more
configurations.
     But /foo/bar.htm exists to DAV on its own and isn't a sub-element of
     a configuration.  Not to say your idea isn't good -- I'm just trying
     to explain our thinking here.

***

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.

[CK] This is something I should have made clearer.  Both are valid.
     The VER:... notion is used to refer to a specific revision via
     a URI.  You can also specify the URL and the Revision-Id header.
     Chalk this up to a bad example.

***

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.

[CK] This is an excellent point.  It seems reasonable to use properties,
     but live vs. dead selection is interesting and DAV:allprop is
     becoming a very expensive operation.

***

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.)

[CK] The idea here is that you want a separate DAV:response for
     each DAV:href.  If you place DAV:defaulthistory inside of 
     the DAV:prop, you'd get a different response.  I'll take a
     look at the DAV spec again.

***

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?

[CK] The idea was to allow the user to specify additional information
     as well as allow the DAV:none to cancel.  We could do this all 
     through headers, but XML seemed appropriate.

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

[CK] Thanks for the feedback.  We really appreciate you taking the 
     time to read and comment.  We have a working group meeting next
     week and I'll make sure we talk about the issues you have raised
     here.  Thanks again!

Received on Tuesday, 2 February 1999 15:10:12 UTC