Re: comments on deltav-10.5 from Yaron Goland, Act One

See <tim> tags below.



"Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 2000-12-21 03:23:21 PM

Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>

To:   ietf-dav-versioning@w3.org
cc:
Subject:  Re: comments on deltav-10.5 from Yaron Goland, Act One





Here is the response from the working group to Yaron's comments.
These changes appear in the current (10-11) working draft.

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

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

Done.

<tim>
    Shame.  I'll have to see this, but either you have LOTS of
    tokens or have chosen which are 'ignoreable'.  For the record
    I was in favour of keeping the attribute.
</tim


   (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.

Done.  (I think I caught them all).

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

The working group felt a "null" value was appropriate for this,
rather than defining an "unknown" value.

<tim>
    Again, for the record, I am in favour of servers not defining
    this property if they cannot provide a reasonable value for it.
    (I don't know what the "null" vallue will be?)
</tim>

   (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.

Done.

<tim>
    What does 'explicitly negotiated otherwise' mean?  If it means that
    particular clients and servers can have an out of (protocol) band
    conversation to do something else, then of course this is true; for
    any number of things.  I'm not sure what this statement adds.
</tim>


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

Done.

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

This will be reflected in the "scenarios" document, since this is just
one of many interesting examples that are worth describing.

   (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/>

Done.

   (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".

Done wherever there was a chance of ambiguity.

   (I.9) Indicate which live properties are controlled by a lock.

Done (in particular, every versioning live property is controlled by
a write lock).

Cheers,
Geoff

Received on Thursday, 21 December 2000 11:04:29 UTC