- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 26 Mar 2001 10:13:15 -0500
- To: ietf-dav-versioning@w3.org
From: Steve K Speicher [mailto:sspeiche@us.ibm.com] > Acquiring a LOCK on a checked-in version-controlled resource is > harmless, but versioning semantics will prevent the content of > the checked-in version-controlled resource from changing anyway. Take the following typical actions of a non-versioning aware client: LOCK /foo GET /foo PUT/foo UNLOCK /foo If the resource is a VCR, then I think what you are saying is that the LOCK will succeed and the PUT will fail (if DAV:auto-version is "never"), since the resource is DAV:checked-in and modifying it would therefore change an already existing version of /foo (not good). Yes, modifying the body of a checked in version controlled resource is forbidden (in Section 2.10). Note: The PUT is being applied to a VCR, not a version, so it wouldn't change an existing version of /foo in any case. Though, if the PUT would fail with Locked status-code (assuming it would) but the client would realize that they owned the lock on the resource and think, "Now what do I do?". It would not fail with a Locked status code (remember, a checkin is not a lock). I realize that wanting your versioning server to be DAV class 2 compatible, you wouldn't/shouldn't have DAV:auto-version of "never". Correct. Do I have a point? I guess I just want some justification on my interpretation of this I'm not sure what you have in mind by "justification". You can't modify a checked-in VCR, since that would break the semantics that the content of the VCR is the same as its DAV:checked-in version. and if the PUT does fail, with what status-code: "423 Locked", ??? The error response (defined in section 2.10, "Additional PUT Semantics"), would be a 403 (if the resource couldn't be checked out) or a 409 (if the resource could be checked out) with a DAV:cannot-modify-version-controlled-content tag in the response body. Cheers, Geoff
Received on Monday, 26 March 2001 10:12:40 UTC