Next message: Tim Ellison/OTT/OTI: "Defaults"
Date: Tue, 7 Mar 2000 23:48:50 -0500 (EST)
Message-Id: <200003080448.XAA16142@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Comments on deltav-versioning-03.1
From: "Vasta, John" <jvasta@Rational.Com>
Here are some comments and questions I have after going through the
3.1 draft:
4.1 Auto-versioning is disabled if a Workspace header is
supplied. Should it also be disabled if a Revision-Selector header is
used?
Yes. Fixed.
5.1 MKRESOURCE: The introduction says that resources can be created
and their properties initialized in one atomic operation, but the rest
of the section does not explicitly say that a new resource should be
destroyed if there was any error in setting a property. If that is
really what is intended, I think there should be more explicit
language to make that clear.
The postconditions state that if there are any errors, no new resource
is created, and any existing resource at the request URL is
unaffected.
6.1 VERSION: Under Response Marshalling, it says "The following status
codes can appear in the DAV:status element". But the response cannot
be multi-status, so there is no DAV:status element.
Fixed.
6.2 CHECKOUT: Under Response Marshalling, it says "The DAV:response
MUST contain an href containing the DAV:versioned-resource property of
the selected revision". But the href in the example looks more like a
working resource URL, which makes more sense to me. Should it be a
working resource URL?
Yes. Fixed.
6.3 UNCHECKOUT: DAV:status appears in Response Marshalling here too.
Fixed.
6.4 CHECKIN: shouldn't the activity language be removed from this
section, since it only concerns basic versioning?
Yes. Fixed.
It sounds like arbitrary properties can be applied to the new
revision. What if there is an error setting a property? Should the
checkin be "undone"? It seems like it could be difficult for some
servers to get the resource back into the checked out state: the new
revision must be destroyed, but its contents must be preserved to
become the working resource for the previous revision, after it is
checked out again. And if the resource is a collection, it is harder
to preserve the contents of the destroyed revision.
Also, if a property operation fails, should the response be
multi-status? If not, the DAV:status language does not apply.
Good points. All we really wanted hear was the DAV:checkin-policy.
I'll change the language so that only DAV:checkin-policy can appear
in the request body, and all these issues go away.
6.4.1 The example checkin-policy is "identical-abort", which no longer
seems to exist.
Yes. I replaced this with "keep-checked-out".
6.5 LABEL: it isn't clear if multiple label operations can be
specified in one request. It says "The body of the request contains an
XML document with either a DAV:add or a DAV:delete member", which
sounds singular, but then it says "The specified labels have been
added and deleted from the specified revision", which sounds plural.
If more than one label operation can be requested, what if one fails?
Are all other label operations undone? If not, should the response be
multi-status, so a client can know which operations succeeded and
which failed?
If a delete operation is requested for a non-existent label, is that
an error?
Since HTTP-1.1 can keep connections open, there seems little point
to batch up label requests like this (resulting in the complexity
John identifies). I propose we just limit the LABEL request to adding
or deleting a single label, and keep things simple.
6.5.1 The example introduces a DAV:request element, but it is not
defined anywhere. Also, the closing tag should be </D:request>, not
</D:response>.
I'll change this so that it is just a DAV:add or DAV:delete
element.
13.1 MERGE: the DAV:status language appears here too.
Fixed.
Thanks for the detailed review John!
Cheers,
Geoff