Next message: Vasta, John: "Missing advanced preconditions from PUT, MKCOL, COPY?"
Date: Fri, 15 Sep 2000 10:13:51 -0400 (EDT)
Message-Id: <200009151413.KAA09778@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: draft-ietf-deltav-versioning-08 now available
Thanks for the review, Ron! Reviews from working group members who
aren't on the design team are especially useful and appreciated.
From: Ron Jacobs <rjacobs@gforce.com>
Just a few comments/questions on draft-ietf-deltav-versioning-08,
but first, I am wondering what the status is of the
long-anticipated updated scenarios document. Might I suggest that
the scenarios document would be very useful during the last call of
the specification? Seems like the scenarios could nip in the bud
many of the "it works this way -- no -- it works that way" kind of
exchanges on this mailing list. :)
I was hoping to get some other folks to write up the scenarios,
but if that doesn't happen soon, I'll just go ahead and do it.
I agree that the scenario document will be of great value during
the last call phase, so I'll make that my first priority as soon
as the current threads die down.
Section 3.1: To me, "unknown" sounds more like one of the potential
values for this attribute. Maybe the name could be "if-unknown"
(which I don't really like either) or something that indicates that
the value is a choice to be taken conditionally.
Anything that can be done to improve the name would be good.
Between "unknown" and "if-unknown", I probably prefer "unknown",
but I agree that "unknown" is not the optimal choice. Suggestions
welcomed!
Section 3.1.1: Shouldn't this attribute be in the DAV: namespace?
If so, then the example should indicate D:unknown for the new
attribute.
That's fine with me. If nobody feels otherwise, I'll make the change.
Section 9.1: There isn't one! Maybe section 9 is intended to be
section 8.1 with all subsequent sections renumbered.
Drat! I apparently forgot to hit F9 to update the references.
Sorry about that.
Section 10.1: The description could contain a reference to section
12 which defines basic versioning reports. Also, should error
response codes for REPORT be specified here?
The errors seem to be handled reasonably well with the standard 4xx
response codes. Did you have any particular errors in mind?
Section 11.1: If the request-URL identifies a versionable resource
mustn't the request body not identify a version? If so, this should
be specified rather than relying upon the example in section 11.1.1
as a specification.
I agree. Will fix.
Section 11.2 (and others): Is it necessary for each method to have
its own DAV:*-requires-lock-token precondition element tag name?
Since the request method is implicit, could not all of these be
<DAV:requires-lock-token>? For that matter, if the name of the
method should remain in the precondition tag name, then why not for
all preconditions which would be more scalable?
The main reason I included the method name in some error tags was
in case the error resulted from auto-versioning behavior, and so
effectively several methods get invoked from one request, and this
would help the client explain what went wrong.
I could go either way on this, though, so other folks should chime
in here if they care.
Section 11.5: Should the two occurrences of the
<DAV:must-select-version/> precondition be combined?
Or perhaps different error tokens should be returned. Anybody have a
preference?
Section 11.5, again: An example for the collection case would be
useful because the 207 result code seems to always benefit from an
example. :)
I agree. Do you care whether this example appears in the protocol
document or in the scenarios document?
Section 11.6: How is a request to list the labels on a version
marshaled? Or is this mention in the first sentence left over from
a previous draft?
This is a left over. We now just use a property. I'll fix this.
Section 12.*: For each report, what is the effect of a depth header
in the REPORT request? Not specifying this leaves room for widely
varying server-side implementations. For example, the
DAV:available-report, is the response DAV:report-set for the union
or intersection of the collection's resources? Or, is the response
a 207 multi-status response? If so, then examples are needed.
A depth report is returned in a 207 multi-status. I'll add this
statement to the document to make it unambigous.
Thanks again for the review!
Cheers,
Geoff