W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Comments on -12: properties, REPORT, OPTIONS

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Wed, 31 Jan 2001 15:08:10 -0800
To: <ietf-dav-versioning@w3.org>

In Section 1.5.2:

1) "A protected property cannot be updated with a PROPPATCH request."

This this is a requirement, I recommend changing the "cannot" to a "MUST
NOT" since that is the intent of the text, and "MUST NOT" has a specific
meaning according to RFC 2119.

2) On the flip side, if a DeltaV property is not protected, is it the case
that it MUST be writable using PROPPATCH, unless the property definition
explicitly states otherwise (of course, writable assuming you have write
access permissions).  In particular, does a client have a guarantee that it
will always be able to write to, say, DAV:comment, and

3) "Note that a given property can be protected on one kind of resource, but
not protected on another kind of resource."

This sounds a bit odd to me.  What examples do we have of this?


REPORT doesn't fit in Section 23.  REPORT is a new, complex method that
predominantly extends the capabilities of RFC 2518, rather than clarifying
existing capabilities in 2518. So far, REPORT is only used in this draft,
hence though it may have utility broader than just the DeltaV draft, so far
there aren't any additional users.  It may make sense, at some point in the
future, to include this in the Distributed Authoring specification.  But for
now, having it in a section titled "Clarifications and Extensions to RFC
2518" is a bit strange -- the *entire* specification could be labeled
extensions to 2518.  Additionally, sometimes people view appendicies as
being non-normative -- do you want to send the message that you can safely
ignore implementing REPORT?  The definition of REPORT can be placed
elsewhere in the specification, and just note that the authors recommend it
be incorporated into a revision of RFC 2518, due to its potentially broad


Section 23.6:

1) I think it makes sense to keep things open for additional OPTIONS
extensions.  So, I would rephrase this as, if you include an XML request
body with OPTIONS, here is what it means, and it must include the following
XML element.  Right now you're cutting off all possible future extension to
OPTIONS that doesn't use XML, and that is overcontraining.

2) I'm not sure why the "supported-method-set" capability is present, since
it duplicates the existing functionality of OPTIONS, specifically the Allow
header.  If the example in 23.6.1 were correct, it would highlight this.
The correct *response* for the example in 23.6.1 is:

HTTP/1.1 200 OK
DAV: 1, 2, version-control
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="uft-8"?>
<D:options-response xmlns:D="DAV:">
     <D:supported-method D:name="VERSION-CONTROL" />

So, the same information is in the Allow header, and the supported-method
element.  IMO, there is no clear advantage to duplicating this capability.

3) Within supported-live-property-set, and supported-report-set, why not
marshall the live properties, and reports, as comma separated lists?  It has
the dual advantage of being more compact, and easier to read. DeltaV clients
must have the ability to parse comma separated lists, so it's not like this
is a huge imposition.

4) What are the semantics if there is an XML request body for OPTIONS, and
this request body does not include a DAV:supported-method-set,
DAV:supported-live-property-set, or DAV:supported-report-set at all (i.e.,
what happens if one or more are just plain omitted)?

- Jim
Received on Wednesday, 31 January 2001 18:08:47 UTC

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