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

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

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 21 Dec 2000 17:23:43 -0500 (EST)
Message-Id: <200012212223.RAA07485@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
   From: Tim_Ellison@uk.ibm.com

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


       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.

I agree that this functionality has advantages, but since it
was not critical for versioning, we decided to leave it to be
defined by some other group that really needs it. 

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

       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?)

That's what I meant ... I should have said "omit the property", not
a "null value".

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


       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.

If you just say "MUST be the top level element", then this is violated
by any later spec that wants to allow the client to ask for it to be
elsewhere (e.g. use a header to ask that it be nested in some other
XML).  So for extensibility, you need to open up this constraint in
this fashion.

      (II.4) Require version-name to be XML, for internationalization.

   Removed the restrictin that it be a string, but did not require it to be

       So what's a guy to do?  If it is not necessarily XML it must be
       handled as a String -- which means all of those <'s and &'s must
       be escaped.  Of course if a different client retrieves the comment
       and the XML is un-escaped on the way out, it won't be internationalized
       to the client's taste.
       I guess that the objection to it's being XML is that the comment
       is typically accessible by other (non-NLS'd) tools that would only
       expect a String.

Yes, this was just a case of "editor fatigue".  I'll change this to say
that XML is required.

      (II.5) Move all DAV:supported-xxx properties to the OPTIONS response.
	  Move all DAV:xxx-collection-set properties to the OPTIONS


       Do we need DAV:supported-live-properties?
       Servers are required to protect the names of all live properties
       (whether they support them or not), so PROPPATCH will fail if the
       property is unsupported.
       Servers should not define a live property that it does not support,
       and PROPFIND would return 404 Not Found.

Since the protocol does not distinguish between dead and live properties,
a server has no way of knowing whether the PROPPATCH was to a dead
property or to a live property that it doesn't know about.

Received on Thursday, 21 December 2000 17:24:38 UTC

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