Hi Roni,
thanks for the feedback. Comments in-line.
On 12.04.2010 16:49, Roni Even wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-reschke-webdav-post-06
Reviewer: Roni Even
Review Date: 2010-04-12
IETF LC End Date: 2010-05-07
IESG Telechat date: (if known):
Summary: This draft is roughly ready for publication as a Proposed
Standard.
I have three nits of which I am not sure since I am reading this draft
without the entire context.
Nits comments:
1. In the abstract there is the following paragraph: “On the other
hand, WebDAV-based protocols such as the Calendar Extensions to
WebDAV (CalDAV) frequently require clients to pick a unique URL,
although the server could easily perform that task.” This is also
mentioned in the introduction. I am not sure why is this mentioned
here and if there is a specific recommendation for this case. How
this relates to POST. My assumption (not being an expert on the
topic) is that there were reasons for making the client pick the
unique URI for the CalDAV and CardDAv applications.
CalDAV requires the client to pick the URL *because* the authors of the
spec didn't want to specify POST-to-create. As far as I know, this is
considered to be a problem in CalDAV, and makes implementations harder
than it should have been.
draft-reschke-webdav-post addresses this problem by specifying how POST
can be used in WebDAV-based protocols. My understanding is that
CalDAV/CardDAV implementers are planning to use it to make the protocol
more efficient where possible.
2. In section 3.2.1 “A PROPFIND/allprop request SHOULD NOT return
this property “. Is there a case where PROPFIND/allprop request
may return this property or did you mean “SHALL NOT”
(a) For consistency with other WebDAV specs (RFCs 3253, 3648, 3744,
4331, ...); (b) returning the properties upon allprop would be harmless;
it woulde be just a waste of bytes on the wire.
3. I noticed that you asked the RFC editor to remove appendix A and
B. What about the Index.
I'll leave that to the RFC Editor to decide; they usually drop the Index
on short specs like these; it got here mainly because I'm using the
index metadata in the XML source for cross-referencing purposes.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf