Next message: Clemm, Geoff: "RE: Versioning TeleConf Time Change?"
Message-Id: <200009141754.NAA02566@tux.w3.org>
Date: Thu, 14 Sep 2000 13:53:05 -0400
To: ietf-dav-versioning@w3.org
From: Ron Jacobs <rjacobs@gforce.com> (by way of "Ralph R. Swick" <swick@w3.org>)
Subject: RE: draft-ietf-deltav-versioning-08 now available
[freed from spam trap -rrs]
Date: Thu, 14 Sep 2000 13:46:00 -0400 (EDT)
Message-ID:
<CC2AF3B5727BD411907F00A0CC63594C0F0948@exchange.gforcesystems.com>
From: Ron Jacobs <rjacobs@gforce.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Geoff,
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. :)
These comments are on core versioning only.
Section 1.3: I agree with Jim Amsden's comment within his Sept. 5th posting
that
Version History should be Versioned Resource.
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.
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.
Section 9.1: There isn't one! Maybe section 9 is intended to be section 8.1
with all
subsequent sections renumbered.
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?
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.
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?
Section 11.5: Should the two occurrences of the <DAV:must-select-version/?
precondition
be combined?
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. :)
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?
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.
Thanks, Ron