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

From: "Roni Even" <[email-masked]>
Date: Mon, 12 Apr 2010 17:49:40 +0300

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.
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"
3.	I noticed that you asked the RFC editor to remove appendix A and B.
What about the Index.

Roni Even

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Apr 2010 17:09:27 +0200

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
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
>    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