Next message: Geoffrey M. Clemm: "Versioning TeleConf Agenda, 3/13/00 (Monday) 2-3pmEST"
Date: Sun, 12 Mar 2000 13:10:53 -0500 (EST)
Message-Id: <200003121810.NAA22742@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Versioning Spec-03 Review - core versioning
Thanks for the great review, Jim! Sorry I wasn't able to get these changes
into the 04 draft, but I've made these changes in an 04.1 draft, which
I'll deposit in the webdav/deltav/protocol sometime early next week.
From: jamsden@us.ibm.com
Just a nit, I like examples to look real if possible. Definition of
predecessor/successor example could look more real and might be easier to
understand.
Do you mean the ascii art in the definitions section?
I'm not sure how you make ascii art describing a version
tree look "real" (:-).
2.1 never really says how a versioned resource is created. Should mention
the VERSION method.
We don't mention any of the method names that implement these
semantics. We could do so, but I thought we wanted to focus on
semantics in section 2, and leave the syntax issues for later.
2.2 Can the client specify the workspace in core versioning if they want to
reuse one? Or are they always returned by the server and the client has to
group them into a logical workspace?
Currently, they are always returned by the server in core versioning.
A server that wants to extend core versioning by supporting a workspace
resource that can be passed in with a CHECKOUT request is of course
free to do so.
2.3, end of the second paragraph: The same revision label can be applied to
a revision of any other versioned resource.
Done.
3.1.5 stable-href syntax isn't really a different syntax, but rather a
property of the use of an href in a context.
Yes. I removed the "syntax" language, so now its just a commonly
used property value.
3.2.1 indicate each revision can have a differen author.
Done.
3.3 shorten DAV:versioned-resource-resourcetype to just
DAV:versioned-resource. Its more consistent with DAV:collection, is
shorter, and less redundant (i.e.,
<DAV:resourcetype>DAV:versioned-resource-resourcetype</DAV:resourcetype>
has one too many resourcetypes's.
The issue here is that the definition of DAV:versioned-resource in
3.4.9 is that its value is an href, while the value of
DAV:versioned-resource-type is EMPTY. I suppose we could define
DAV:versioned-resource to have a value of ANY, and then have it be
EMPTY or an href, depending on where it appears, but to make the
value of the XML element ambiguous to save a few characters seems like a
poor tradeoff.
3.3.1 are the DAV:revisions ordered in any way?
No.
3.3.3 DAV:default-revision isn't consistent with the default workspace
concept. It introduces another revision selection mechanism. Need to
resolve this in the context of the default workspace.
I believe we need to simplify core versioning, and I believe that
adding the (simple) notion of the "default revision" in order to defer
"extended workspaces" and revision selection rules to advanced
versioning seems like a good tradeoff. An issue that we need to
discuss.
3.3.4 Saying auto-version is like CHECKOUT/PUT/CHECKIN is like saying MOVE
is COPY/DELETE. We may regret saying this later,
One difference is that MOVE is not COPY/DELETE, while CHECKOUT/CHECKIN
is the way to create a new revision (:-). I believe that saying that all
new revisions are created by some kind of CHECKOUT/CHECKIN is a
simplification that we should embrace.
I notice that we currently have a separate BASELINE operation for
versioned configurations that contain baselines. I'll fix this
to just use CHECKOUT/CHECKIN as well.
and the operation needs to be atomic.
Done.
3.4.2 I get nervous about DAV:revision. First, its not clear who will use
this or how easy it will be to use.
Any client that wants to save a reference to a specific version would
use this feature. As for ease of use, if it is hard to use a URL to
refer to a resource, then all of HTTP is in trouble (:-).
If clients are doing all the mappings
of human URLs to DAV:revision URLs, then this is OK, but seems like this is
usually the server's role.
The "human URL" is a workspace dependent name for a versioned resource.
The DAV:revision URL is a workspace independent URL for a specific revision
of a versioned resource.
There are two namespaces. The user defined namespace that identifies
the current (workspace dependent) names for versioned resources.
Then there is the server defined namespace that
identifies the revisions of those versioned resources. The versioned
resource is a very different resource from a particular revision of that
versioned resource, and both should be identified by URL's.
Second, once a server gives out this
information, it will be required to maintain it. That is, the server won't
be able to reorganize its contents in a way that might invalidate any of
these generated URLs. This might reduce server implementation flexibility.
It also reduces server implementation flexibility to require that
it remember old revisions of a versioned resource (:-). So for any
feature, you need to balance ease of implementation against value
to the client.
3.4.5 Are revision labels, like revision ids, required to be valid URL
segments?
I believe that we decided that neither revision id's or labels were
required to be valid URL segments, but that they could be made URL
segments by using the standard URL encoding mechanisms.
3.4.7 Indicate this property will be empty if there is not checked out
working resource.
Since this property "identifies the workspaces for the revisions currently
checked out from this revision", doesn't it follow that it will be empty
if there are none?
4. seemed to have lost some of the details on how versioning effects other
methods. I think MOVE, COPY, and DELETE need some attentation as well as
LOCK/UNLOCK.
If you look at the version of the spec that had a separate section for
each method, you will note that each section said virtually the same
two things. It significantly simplified the section to just say
those two things once.
Copying
a versioned resource copies only the selected revision to a new unversioned
resource?
Section 4 says that a method is always applied to the target of the
versioned resource. This indicates that only the selected revision (or
selected working resource) is copied. Whether or not it creates a
new unversioned or versioned resource depends on whether the destination
collection is unversioned or versioned (which is discussed in section 11).
All the proposed semantics for locking a versioned resource,
resource, workspace, activity, and configuration?
There is no proposed semantics for locking versioning metadata,
and I believe that is correct. Clients do not download a versioning
metadata resource, modify it, and then put it back to the client,
so there is no need for the overwrite protection provided by locking.
We do of course need to define ACL's for versioning metadata, but
that is a very different issue.
5.1, 207, needs to be consistent with result of PROPPATCH.
How is it currently not consistent?
5.2 Status codes reference MKRESOURCE instead of REPORT.
Done.
Looks like there
could be many more status codes.
Yes. I've added 400, 404, and 405. Any others come to mind? We don't
have to exhaustively ennumerate them, but rather just give the reader a
sense of what are the commonly expected responses.
Are any dependent on the report type?
Since it is a report method, any status information other than the standard
status codes probably should be placed in the response body of the report.
5.2.1 could these names be shortened from *-report-request to just
*-report.
Or we could just avoid the whole issue and have a separate method name
for each report, PROPERTY-REPORT, CONFLICT-REPORT, and COMPARE-REPORT.
There have been requests on the mailing list to not have "extensible"
methods, in order to simplify implementation on existing web server
technology.
Isn't the request implied by the context in which the element
appears? Example 5.3, D:available-report in a d:report-request is what I
mean. Note the example doesn't match this section in any case.
Done. This would of course change if we adopted the one-method per
report approach.
5.3.3 (and others) URI shouldn't contain the protocol and domain name.
Done.
5.4 Property report should be DASL. Too much work has be done on DASL for
us to just ignore it.
If DASL is an accepted IETF standard by the time the versioning protocol
comes up for last call, and it can produce this report, I'd be happy
to remove this report from the versioning protocol.
6.1 Didn't see anything that specified what was a versionable resource.
Could this vary from server to server?
Yes.
Are there just some resourcetypes that would never be versionable?
Should these be the ones we list?
The protocol states that workspace and activity resource-types are not
versionable, but a server can further restrict what can be versioned
(for example, some servers will not allow collections to be versioned).
Postconditions 2) copy of the versionable resource contents and properties
(should be ok as written though).
3) What is the DAV:resource-id?
This is defined by the binding protocol. Assumedly the binding protocol
will be accepted before the versioning protocol (otherwise, we'd have to
define this ourselves). Note: the binding working group has changed
the name from DAV:resource-id to DAV:urn, but this isn't reflected in
the versioning spec yet.
6.2 request marshalling 2) what about the workspace header? Can the client
specify a workspace to reuse?
Not in core versioning (but yes in advanced versioning).
Status codes 405: if the workspace can't be specified, then it can't be
invalid.
Done.
What about status codes for already checked out? What about violations of
the checkin policy?
Currently those are 409's (i.e. "Any other violated pre-condition of the
CHECKOUT request").
6.2.1 Content-Type not valid if there is no entity request body.
Done.
6.3 request marshalling 2) workspace that identifies not contains the
selected working resource.
Done.
Status codes: should 405 be 409 Conflict?
The line can be a bit hazy, but this seems more like a 405 to me, i.e.
the method cannot be performed on the specified inputs. Any other votes?
6.4 Remove reference to DAV:activity.
Done.
6.4 request marshalling 2) workspace that identifies not contains the
selected working resource.
Done.
Postconditions 1) I don't like a CHECKIN doing a PROPPATCH.
Done. The other reviewers didn't like this either, so I took that out,
and just had the body be a DAV:checkin-policy.
2) Couldn't find a definition of DAV:resourceid
That comes from the binding spec.
5) move stuff associated with activities to advanced.
Done.
6) do you mean current label instead of selected label?
Yes. Also, this should be (and has been) moved to advanced versioning.
6.4.1 D:identical-abort not defined in 3.5.3. Response body not defined.
Done.
6.5 LABEL only adds and removes labels, doesn't change labels.
Done.
Should LABEL take a depth header to apply the label to all the members?
I'm against depth operations unless they are unavoidable. With HTTP-1.1
allowing a connection to stay open, this is no longer a critical performance
issue, so I'd keep depth out of the LABEL semantics.
Request body not defined.
Done.
6.5.1 D:request not defined. element D:request terminated with D:response.
Done.
7.1 Reference to revision selection rule should move to advanced section.
Done.
Default workspace is not defined.
Changed to DAV:default-revision.
What is a Vary header?
That is the header a server is supposed to return to tell a proxy/browser
what headers will cause the reponse to vary (i.e. to tell it what headers
affect caching).
Last paragraph, why not just return the Revision-Selector header?
Which last paragraph?
Thanks again for the detailed review!
Cheers,
Geoff