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

RE: Core versioning issues and nits

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 5 Feb 2001 14:58:56 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
> -----Original Message-----
> On Behalf Of Geoffrey M. Clemm
>    > 10) Interactions between LOCK and VERSION-CONTROL
>    >
>    > State whether a locked resource can be placed under
>    > version-control, and whether the lock-token must be supplied
>    > with the VERSION-CONTROL method.
>    Sounds reasonable.
> Actually, the interaction between the versioning protocol and
> the locking protocol is completely defined in 1.5.4, namely
> that a property defined in the versioning protocol MUST NOT
> be modified on a locked resource unless accompanied by a
> valid lock token.  In particular, in this case, placing a
> resource under version control adds a DAV:checked-in property
> on that resource, which requires a lock token if the resource
> is locked.
> This might be worth adding to the FAQ, but I don't want to
> repeat this on every method that updates a property (which
> most of them do).

Please look again.  Section 1.5.4 states:
"If a write-locked resource has a non-computed property defined by this
document, the property value MUST NOT be changed by a request unless the
appropriate lock token is included in the request."

How does this _completely_ _define_ the locking and VERSION-CONTROL
interactions?  It contradicts your explanation, since the draft
explicitly says "non-computed property", and your explanation includes
computed properties set as a by-product of versioning methods!

More seriously, I'm starting to get very disturbed by the response
"we'll clarify in the FAQ".  Delta-V is an internet-draft defining a
protocol for the purposes of interoperability.  It should therefore
provide a complete description of the protocol.  Once the protocol is
published we'll no doubt find under-specified areas and may need to
document these in a FAQ until we can correct them in the transition to
Draft. However, it seems like very bad policy to publish a draft that we
know to be incomplete or confusing with the intention to clarify it in a
non-normative non-archival document.

Received on Monday, 5 February 2001 17:59:57 UTC

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