W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

comments on deltav-10.5 from Yaron Goland, Act One

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 7 Dec 2000 11:46:45 -0500 (EST)
Message-Id: <200012071646.LAA16049@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

Yaron has reviewed the core versioning parts of the protocol and had
the following set of comments.  His current work responsibilities did
not provide enough time for him to produce an email review, but as he
was a co-author of RFC-2518, I particularly wanted his feedback, so I
called him to get his comments, and agreed to post them to the mailing
list.  Note that this will be my interpretation of Yaron's points, so
if I misunderstood or misrepresent them, Yaron will try to follow-up

OK, enough prologue ... on with the show.  In Act I, we have the
points that I agree with and that I believe will be
non-controversial. I propose that I just make these suggested change
unless someone disagrees.

In Act II (a separate message), I'll enumerate the changes that either
I agree with or don't care, but which I think might be controversial.
If you only have time to review Act I or Act II, Act II is probably
more interesting.

In the final Act (another separate message), I'll enumerate the
changes that I do not agree with, but which Yaron would like to
propose.  It's not clear yet whether there is anything in Act III
... I haven't thought through all of Yaron's suggestions.

------- Act I --------------

(I.1) Get rid of DAV:must-support attribute, and instead define tokens
      for use in an If header.

(I.2) Add an intermediate node above any list of property names in a
      report request or response, so that the report can be extended
      with additional XML markup.

(I.3) Add an "unknown" value for checkin-date.

(I.4) Require that the 403/409 response body token appear as the top
      level element "unless explicitly negotiated otherwise", so that
      clients get predictable behavior, but later specs can allow
      clients to request other behavior.

(I.5) Need to define the precondition for when cannot place a resource
      at this place. (one per resource type).

(I.6) Have an example show additional elements in request body being
      ignored by the request.

(I.7) Add a response body to VERSION-CONTROL, so that can indicate whether
      it is a no-op or not.  <DAV:already-under-control/>

(I.8) Whenever a statement of the form "the xxx specified in the yyy
      element" refers to an element in the request body, it should
      explicitly say "the xxx specified in the yyy element in the
      request body".

(I.9) Indicate which live properties are controlled by a lock.
Received on Thursday, 7 December 2000 11:47:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC