- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Wed, 31 Jan 2001 15:08:10 -0800
- To: <ietf-dav-versioning@w3.org>
Properties: 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 DAV:creator-displayname? 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: 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 utility. OPTIONS: 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 Allow: GET, HEAD, PUT, OPTIONS, DELETE, TRACE, PROPFIND, PROPPATCH, LOCK, UNLOCK, COPY, MOVE, VERSION-CONTROL, CHECKOUT, CHECKIN 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-set> <D:supported-method D:name="VERSION-CONTROL" /> <D:supported-method-set> ... 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