Re: Comments on draft-ietf-deltav-versioning

jamsden@us.ibm.com
Mon, 15 Nov 1999 15:30:29 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525682A.0070C683.00@d54mta03.raleigh.ibm.com>
Date: Mon, 15 Nov 1999 15:30:29 -0500
Subject: Re: Comments on draft-ietf-deltav-versioning



Thanks Tim for the great feedback. Here's some comments on your comments:

Section 2.1 Creating versioned resources
"When a resource is created in a versioned collection ... it is created as
a
versioned resource."
Why?
<jra>
Currently, a versioned collection cannot contain an unversioned resource.
This is one of the issues we haven't resolved yet. A revision of a
versioned collection should minimally create a version of the namespace. It
seems that the state of the resources accessed through that namespace
should be independent. However, it would not be possible to create a
baseline of a revision of a versioned collection that contained references
to unversioned resources.

An issue with the language above: a resource is not actually created in a
versioned collection, its created in some server-dependent private store,
and a binding is added to the collection. So in this case, the versioning
of the collection and the resource can be independent. Its only the binding
that needs to be fixed in the revision.
</jra>

Section 2.2 Modifying a Versioned Resource
1) I think the comparison drawn in paragraph 2 is unhelpful, since lock and
checkout semantics are so different.  It doesn't help to explain anything
about checkout.
<jra>
I agree. I think it is dangerous to couple checkin/checkout with
unlock/lock. We're trying to assume what the user ment about the the lock,
but depending on the lock scope and type, it my have nothing to do with
checkout. We can't assume there's only exclusive write locks.
</jra>

3.6.2 DAV:checkin-policy
1) "if the resource is identical to"
How is identical going to be defined?  That there has been no
PUT/PROPPATCH's successfully applied to the resource, or that props and
content are bytewise indistinguishable ... or server defined?
2) The DTD allows for ANY element as a checkin-policy.  The spec should
state what a server should do if it does not support the checkin policy,
and
which are mandatory.
<jra>
Identical defined by same GUID? Note that some live properties can change
without the resource state changing as they depend on things that happen in
other resources.

ANY is required to allow extensibility for checkout policies.
</jra>

3..2 DAV:revision-selection-rule
1) para. 1 first sentence "versioned resource is selected" should read
"versioned resource that is selected"
2) para 2 "If it selects a particular revision, it may also detect a
conflict"  IMHO an RSR that is in conflict should not select any revision.
3) last para. but 3 re: DAV:rsr-latest.  Here latest means chronologically
latest, in section 1.2 Terms Activity latest means last in the succ/pred
lineage.  It should be consistent (and IMHO it should be succ/pred
lineage).
<jra>
But the RSR is ordered to give preference to which revision you want. So
having it be a merge rule shouldn't make it impossible for you to see a
revision. Otherwise, complies or builds you need to do to resolve one
conflict may not be possible until you resolve them all.
</jra>

4.2 PUT
para. 2 "PUT MUST fail unless the versioned resource has a DAV:auto-version
property and no Target-Selector has been specified."
Why is it conditional on no Target-Selector being specified?  this seems
strange.
<jra>
I think this was to restrict auto-versioning to non-versioning aware
clients only. As you suggest, we don't necessarily need to do this.
</jra>

4.9 LOCK
"A write lock on a versioned resource checks out the target ... into the
default workspace"  No -- this cannot be true.

4.10 UNLOCK
"An UNLOCK ... checks in ..."  No, please, no!  Lock/unlock,
checkin/checkout should be orthogonal.
<jra>
Well Geoff, there's another clear sentiment.
</jra>