W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: FW: Meeting Notes for the 50th IETF Proceedings

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 4 Apr 2001 18:02:15 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E2329@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

   From: Fay, Chuck [mailto:CFay@filenet.com]

   I'm glad to see from the meeting notes that I wasn't the only one
   who wondered about Core versus Basic (Core + checkout + fork
   control).  I agree with Mark and Larry that Core is sufficient to
   implement versioning, and with Eric that some clients will be
   perfectly happy to deal with Core-level servers.  

I agree with this as well.

   So I believe
   DeltaV should have a package which is just Core.

It's important to separate "features" (what we used to call "options")
from "packages".  The consensus at the meeting was that a server
reports its capabilities in the form of a set of features (in the DAV
header from an OPTIONS request).  In the protocol, we define a small
set of feature sets, or "packages", that a server SHOULD support,
as a way to simplify the creation of interoperable clients.

This means that a server MAY support just the "version-control"
feature, but not any of the defined packages.  On the other hand,
to keep the interoperable client combinatorics in control, we
propose to define a small number of "packages" that reflect a 
set of features that appear to cover the majority of planned

   I would not
   replace Core with Basic.  Given that decision, I would rename Basic
   to avoid the implication that it's the minimum package, or
   otherwise make it clear that Core is the minimum.

Yes, all features require the "version-control" feature, which makes
it the logical minimum set of versioning features.  But it is still
reasonable to say that the smallest defined "package" consists of
more than that logical minimum set of versioning features.

Although Lisa has recently posted a suggestion that we actually 
return package names in OPTIONS, rather than feature names, I do
not agree with this suggestion, and this suggestion was not
supported by the working group in Minneapolis.

   I disagree with Geoff and JimW that adding checkout and fork control is
   cost for any server wishing to be DeltaV-compliant.

The minutes are a bit misleading there.  I agreed that it is reasonable
to have checkout and fork-control in the smallest defined "package",
but I did not agree that a server have to support this in order to
advertise any DeltaV support.  To the contrary, I believe as stated
above, namely that a server MAY just support the "version-control"
feature (which does not have CHECKOUT).

   Recall that checkout
   requires mutable VCRs on the server which hold intermediate state between
   checkout and checkin, whereas Core has no such requirement.

I agree.

   Core allows all
   server-resident resources to be immutable, which is arguably a more
   consistent model than the mixed model with checkout (mutable checked-out
   VCRs, everything else immutable).

More "consistent"?  I probably wouldn't go that far ... if you want to
have consistent property/content, unless you can come up with a way of
updating both in one HTTP request, you'll be creating inconsistent
immutable states on the server, which doesn't sound like a good thing
to me.  This is why although I agree that a server MAY just support
the version-control feature, it SHOULD support CHECKOUT.

   For existing versioning servers that
   disallow mutable objects, the cost of supporting checkout is non-trivial,
   because code would have to be written to subvert the fundamental design
   the server.

I agree.

Received on Wednesday, 4 April 2001 18:01:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC