Re: Gen-ART LC review of draft-reschke-webdav-post-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]