Next message: Geoffrey M. Clemm: "Re: VERSION"
Date: Thu, 18 May 2000 17:39:09 -0400 (EDT)
Message-Id: <200005182139.RAA06064@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: draft-ietf-deltav04.5 now available
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
> For efficiency ... may report only a subset of the labels ...
Oops! Then there is, just because of efficiency reasons, no reliable
way to recover all labels, even if I have full access rights? I
think, this s a flaw.
<tim>
I was also surprised to read this.
The I agree that servers should be required to disclose all labels .
</tim>
Fixed.
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Section 5
---------
> Note that if a method modifies only a binding to a resource and not
> the resource itself (e.g. DELETE, MOVE, BIND, UNBIND), the method is
> being applied to the collection containing that binding, so the method
> is not affected by versioning unless that collection is under version
> control.
Ok, but what happens, for example, when you try to DELETE a stable
URL? Does that mean that the associated revision is to be deleted?
Trying to MOVE a stable URL should fail (e.g. 405 (Method not
allowed)), right? The same questions arise when you apply DELETE or
MOVE on a versioned resource whose target is a revision.
<tim>
I would like to see the section substantially expanded. I believe there
are a number of " interesting " interactions with existing methods that
need to be explained.
</tim>
Could you enumerate the interactions you have in mind?
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
In the current protocol there is no means of determining if a server
supports multiple mutable revisions for a particular versioned resource.
Do we believe it is sufficient for clients to attempt to overwrite a
revision to determine whether the capability exists?
We could add a token to the DAV: header for this, but just trying it
would be fine with me.
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
To be friendly, we should say somewhere that the date properties (i.e.
check-in date) optional, since we should work on time un-aware servers.
Done.
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
I think it would be extremely useful if a check-in returned the ID of the
revision that was just created. I see no other reliable way of clients
discovering what they just did to the history.
Done. A stable URL must now be returned in a Location header.
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Assume you are a basic versioning client. If you perform a checkout to
create a working resource and then issue a delete to remove it from a
collection, what would the steps be to uncheckout the working resource. Do
we have any way of finding that working resource again?
When you issue a "DELETE", you are actually deleting the versioned
resource from the collection that contains it. If that is the last
binding to that versioned resource, that versioned resource and all of
its working resources are now inaccessible.
If there still is a binding to that versioned resource, you can ask
the versioned resource for its DAV:working-resource-id-set, and then
find the working resource that way.
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Do we really need a method for UNCHECKOUT?
How about a check-in policy of <DAV:uncheckout/>
I made that change in one of the earlier drafts, but as I recall, Jim
Amsden strenuously objected.
I personally would be more than happy to make it be a
checkin policy, since it is no more strange than "keep-checked-out"
or "overwrite".
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Section 2.3 has interesting sumer semantics when read literally. It states
explicitly that locks only apply to URLs with the same target selector
value.
Yes, that was how I intended it to read.
This implies that the client cannot lock a labelled revision by
it's URL and label target selector, and others can make modifications by
specifying no target selector or an explicit revision ID etc. that selects
the same resource.
I assume you meant "... that the client *can* lock a ..."
And if so, yes, that is the result I intended. Do you disagree
with those semantics, or do you just find them interesting
(in a good way :-) ?
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Section 3.1.4
-------------
The href element is frequently used throughout WebDAV and should be
known to the reader of this protocol, which is an extension to WebDAV;
hence I think this section can be dropped.
I always like to drop things ... does anyone object?
<tim/> It's so small, leave it in.
OK, I usually prefer to err on the side of too much rather than too
little, so I'll keep it in.
Cheers,
Geoff