RE: Deleting versions

I am certainly happy to drop these two sentences, for the
reason Tim gives.  Anyone want to argue for keeping them in?

Cheers,
Geoff

-----Original Message-----
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
Sent: Tuesday, May 29, 2001 1:36 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Deleting versions




Following the principal that the document does not redefine existing
standards, and only describes extensions and departures, I think you could
drop the following:

> A 403 (Forbidden) status indicates
> that an error has occurred that the client cannot
> resolve, and therefore the request should not be
> resubmitted.  A 409 (Conflict) status indicates that
> an error has occurred that the client can resolve,
> after which the request could be resubmitted.

on the grounds that it is an incomplete description of these 'stati'
already defined by HTTP/1.1.

Regards,

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

"Clemm, Geoff" <gclemm@rational.com> wrote:

I agree with Tim's responses.  To make sure that nobody misunderstands
the semantics of the method preconditions and postconditions, I propose
to modify section 1.6 to read as follows:

---------------------

1.6  Method Preconditions and Postconditions

A "precondition" of a method describes the state on the server that must be
true
for that method to be performed.  A "postcondition" of a method describes
the
state on the server that must be true after that method has completed.
If a precondition is violated by a request or a postcondition cannot
be satisfied, the response status of the request MUST be 403
(Forbidden) or 409 (Conflict).  A 403 (Forbidden) status indicates
that an error has occurred that the client cannot resolve, and
therefore the request should not be resubmitted.  A 409 (Conflict)
status indicates that an error has occurred that the client can
resolve, after which the request could be resubmitted.

In order to allow better client handling of 403 and 409 responses, a
distinct XML element type is associated with each method
precondition and postcondition of a request.  When a particular
precondition is violated or a particular postcondition cannot be
satisfied, the appropriate XML element MUST be returned as the child
of a top-level DAV:error element in the response body, unless
otherwise negotiated by the request.  In a 207 Multi-Status response,
this element would appear in the appropriate DAV:response-description
element.

----------------------

Lisa: Does this address your concern?

Anyone: Is this wording OK?

Cheers,
Geoff


-----Original Message-----
From: Tim Ellison [mailto:tim@peir.com]
Sent: Friday, May 25, 2001 5:43 PM
To: DeltaV
Subject: RE: Deleting versions




> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: 25 May 2001 17:58
> To: DeltaV
> Subject: Deleting versions
>
>
>
> I know not all implementations of DeltaV will allow deleting old
versions,
> but the specifications specifically allows it.  I've been looking
> into that
> functionality and encountered some issues and questions.
>
> #1)  Is there some way of finding out, before trying the delete, if it's
> possible to delete a version?  Before you say
> "supported-method-set", allow
> me to point out that this property is not shown to exist on versions.

Sure it is.  All resource properteis described in versioning-15 sec 3.1
states "The version-control feature introduces the following REQUIRED
properties for any WebDAV resource.", and since "The version-control
feature
MUST be supported if any other versioning feature is supported." it follows
that you can always ask a versioning resource for its supported methods.

> #2) It looks like there's a set of error msgs the server can return if it
> decides to prevent the user from deleting the referenced version, the
root
> version, or all versions.  What error msg should the server return if it
> decides to prevent the user from deleting the "current" version
> (though one
> that is not checked out)?

Please clarify what you mean by the "current" version?

> Or what if the server decides to prevent the only
> remaining version from being deleted?

This case is not called out by the spec., so I would expect 403 Forbidden
with no interoperable extended error info.  Just as there will be other
cases that servers (say for implementation reasons) refuse methods and have
interop way of explaining why.

> #3) I don't understand the following text from 3.12:
> "(DAV:update-predecessor-set): If a version is deleted, any reference to
> that version in a DAV:predecessor-set MUST be replaced by a copy of the
> DAV:predecessor-set of the deleted version."  Does that mean that before
> deleting a version, the client must munge the predecessor-set
> properties of
> a bunch of other versions?

Yes, potentially.  The postcondition is required to fix up the history to
show a continuous ancestry for the remaining versions.

> But the predecessor-set is protected!

... from clients.  There are many examples of protected properties that a
server can/will modify.

> Or does
> it mean that the server must update the predecessor-set before performing
> the action, and if it cannot, it returns the error msg?  Please
> explain this
> better in the draft & to the list...

It is a postcondition of the DELETE method for a version, therefore if it
cannot be made true it MUST be as though the method was never sent.  No
partial results will be left by the server, whether the fix up is done
before/after the action is up to the implementation -- the spec states
effectively that by the time 'the response is dispatched' the postcondition
is true.  This is the same for all methods (not just DeltaV).

> #4) Can situations arise where resources can have no versions?

No.  Take a look at the 3.12 postcondition
     (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 can
> actually think of two ways this might be achieved:
>  - A client deletes all the versions (but not the version-controlled
> resource)

See above.

>  - A null resource gets versioning turned on but no body is added

A what? <g>

> Must clients be able to deal with VCRs with zero versions?  If
> not, then we
> need to make a requirement on servers that they must not ever create a
VCR
> with zero versions.

The way to create a version-controlled resource is with VERSION-CONTROL
which always creates a version-controlled resource based on a version.  If
the target resource was versionable the new version is created, or the
VERSION-CONTROL can reference an existing version in the request body.

Tim

Received on Tuesday, 29 May 2001 15:47:18 UTC