Subject: NEW PREFERENCE - depth-noroot (request for expert review)

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jan 2017 12:16:03 +0100

Hi there,

draft-murchison-webdav-prefer-13 defines a new "prefer" directive (RFC 
7240) in 
<https://tools.ietf.org/html/draft-murchison-webdav-prefer-13#section-4>.

Please review and provide feedback.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 13 Jan 2017 00:44:09 +1300

> Please review and provide feedback.

After reading the preference section I am left wondering:

1) what does Appendix B.4 have to do with it?
 there is no use of the preference in the examples.

2) what happens when Depth:0 is given in the request with depth-noroot?

3) what happens when the Depth header is omitted in the request with
depth-noroot?

4) what methods this preference is actually valid for?
 The depth-noroot text references Depth header existence *or implicit*,
but the Depth header leaves it open and explicitly says any method can
re-define Depth. That does not bode well for implementations getting
interoperability correct. Particularly for the impliciat-Depth methods.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jan 2017 13:17:11 +0100

>  there is no use of the preference in the examples.

My copy says Appendix B.1...

It says:

>    This preference is only intended to be used with WebDAV methods whose
>    definitions explicitly provide support for the Depth [RFC4918] header
>    field.  Furthermore, this preference only applies when the Depth
>    header field has a value of "1" or "infinity" (either implicitly or
>    explicitly).

So it would be ignored.

> 3) what happens when the Depth header is omitted in the request with

Defaults apply, as stated above...

> interoperability correct. Particularly for the impliciat-Depth methods.

I don't see a problem here. The preference is defines for methods that 
use the Depth: request header field (including future ones). Clients can 
always check whether the preference was applied.

Best regards, Julian

(But thanks for checking!)