W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2002

RE: Interaction of DAV:auto-version and DAV:checkout-fork

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 28 Jul 2002 08:59:39 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107A5CC3C@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

The only behavior that seems to me to be consistent with the standard
is (a), rejecting the request.  The only way that CHECKOUT can succeed
on a version that has DAV:checkout-fork as DAV:discouraged, and already
has a successor, would be if the CHECKOUT had a DAV:fork-ok argument,
and there is no way for a versioning-unaware client to add a DAV:fork-ok
argument to the auto-checkout.


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Sunday, July 28, 2002 4:37 AM
To: ietf-dav-versioning@w3.org
Subject: Interaction of DAV:auto-version and DAV:checkout-fork


consider the following scenario:

- "a" is a version controlled resource with some kind of auto-versioning
enabled, for instance DAV:checkout-unlocked-checkin,

- it's DAV:checked-in property refers to a version with a DAV:checkout-fork
property of DAV:discouraged and a non-empty DAV:successor-set property.

Non-versioning aware client attempts to modify the resource.

Possible outcomes:

a) request is rejected (409 with

b) request is accepted and the version history will fork.

I think both behaviours are allowed, but which one makes more sense? Right
now, I'm preferring to reject the request (standard operations on a
checked-in resource shouldn't introduce forks into the version history).

Received on Sunday, 28 July 2002 09:00:13 UTC

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