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

RE: Deleting versions

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 4 Jun 2001 10:37:35 -0700
To: "DeltaV" <ietf-dav-versioning@w3.org>, <Tim_Ellison@uk.ibm.com>
Message-ID: <HPELJFCBPHIPBEJDHKGKMEAGCGAA.lisa@xythos.com>

I responded to Tim last week but neglected to cc' the list...

(I think) Tim said:
> The entire postcondition statement is:
>      (DAV:must-be-root-version): If the root version of a version
>      history is deleted, there MUST be another version that is the
>      new root version, i.e. that is the ancestor of all other versions
>      in the version history.
>
> I think it is easily implied that you cannot therefore delete *all*
> versions of a version history and satisfy this postcondition; but
> I have no
> objection to adding to this statement if you really think it needs it.

Actually, I think the problem is that I (do other readers?) still don't
look
in the preconditions and postconditions for normative requirements.  I
think
of them as error/status codes, but in fact a lot of the postconditions make
requirements.  And, in the case of this requirement, the use of the passive
voice makes it a bit of work to figure out whether the client is
responsible or the server is responsible.

So yes, a clear statement like "The server MUST NOT allow the last version
to be deleted" would be useful.


> No, that's great!<g>  The lock null resource is a nonce concept
> that is not
> required by Delta-V.

Since the lock null resource is enshrined in RFC2518, I do not think it's
merely a nonce concept (yes, I had to look it up :)

But you have a point about the purpose, let me try again and see if I get
it
better:  the lock-null feature allows people to lock something before it's
created so that there's no window, or gap, when somebody else can lock it
(after it's created but before the creator has finished with it).
Agreement?

> I see no argument for VERSION-CONTROL or CHECKOUT, but MKWORKSPACE is a
> more likely candidate since it is akin to MKCOL.  This would obviously
> require a modification to RFC2518's statement that the lock null resource
> MUST fail methods that are not in the named list.

I agree.  Rather than relying on the not-fully-prescient wording of
RFC2518,
I'd suggest saying that MKWORKSPACE can be allowed on a write-locked null
resource, but no other DeltaV methods.

The modification to RFC2518 is not required because it states "any HTTP/1.1
or DAV methods ".  DeltaV methods, obviously, are not covered by this,
because if HTTP/1.1 was meant to be inclusive, then DAV wouldn't have been
called out explicitly.
:)


lisa
Received on Monday, 4 June 2001 13:39:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT