Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for Distributed Authoring - WebDAV) to Proposed Standard

Cullen Jennings schrieb:
> ...
>> (4b) Unnecessary new requirements: an example is the new (MUST-level) 
>> requirement to submit a Depth header with PROPFIND (issue 213). This 
>> is just one of several cases where the draft made changes for no 
>> apparent reason; that is, there was no problem with what RFC2518 said 
>> previously.
> 
> On the Feb  8, 2006 conference call, several people on the call came to 
> agreement to, I quote
>     "Agreed to add text to the document specifying that clients MUST 
> include a Depth
>     header in every PROPFIND request."
> Since that point in time, the only email I have seen on this is that you 
> have objected it and one other person sent a "+1" to few pages full of 
> changes you were proposing that included removing this MUST among many 
> others changes. I have no idea if that person was specifically 
> supporting this change or not but for purposes of this, I will assume 
> there were. Given the people on the call, and the fact that this text 
> has been in the version 14 (published Feb 2006), 15, 16, and 17 of the 
> draft and I have only received objections from one or two people. I feel 
> pretty comfortable saying there is WG consensus for the text as it.

Cullen, I think this is an example of a process failure.

(1) I can't recall whether I objected during the call, or whether I just 
resigned in order to get to other topics. It was raised on the mailing 
list, and at least one person has agreed to that it's a problem. Nobody 
on the mailing list (AFAIR) has supported that change. So where's the 
consensus for it?

(2) In any case, this is a (needless) change to RFC2518, adding useless 
work for client implementors.

(3) Sorry, but this almost smells like a strategy. Push-back from the WG 
is ignored, and changes with no consensus are kept in subsequent drafts. 
Later on, the fact that the change has been in these drafts is being 
re-interpreted that there was some kind of support, when there wasn't.

> My understanding of this issue is that you believe that this statement 
> causes no harm but is unnecessary since for backwards compatibility 
> reasons it is already specified what a server does for a request that 
> does not have this header. My recollection of the conference call (and I 
> admit my notes on this are not great) was that people argued that at 
> some future point in time, one could decide for servers not to provide 
> backwards compatible support for 2518 clients, and at that point the 
> server could return an error and this would facilitate reduced bugs and 
> improved diagnostics.

I really have no idea why we would ever change the definition of the 
default. This seems to be a very theoretical argument.

Just to explain what we're talking about:

1) RFC2518 defines Depth 0, 1 and infinity for PROPFIND. The default (no 
header specified) is Depth: infinity.

2) In reality, many existing servers come configured to reject depth: 
infinity (including httpd/mod_dav), rejecting potentially expensive 
requests.

3) RFC2518bis therefore specifically mentions that clients should not 
rely on the ability to do depth: infinity PROPFINDs.

I think that at this point, we were done. We are documenting how the 
protocol works today, and there simply was no additional problem to 
address. Adding the new client requirement simply is pointless.

>> (4c) Issue 237 raises a security issue that isn't discussed in 
>> RFC2518, and I think it's quite important. As far as I can tell, 
>> there's some sort of agreement that this really is a user agent 
>> problem. That being said, all user agents expose this problem, and the 
>> W3C WEBAPI working group was quite unresponsive when it was mentioned. 
>> Thus, it seems to me that RFC2518bis *minimally* needs to minimally 
>> mention the problem, making server implementors/admins at least aware.
> 
> There was no working group consensus for changes to the draft related to 
> this. We had two people post on the list about it. Julian said we should 
> add some text explaining it, the other person said it was not specific 
> to dav and we should not add text about it. As chair I can not claim 
> there was any consensus to include this. The fact that only two people 
> comment on a fundamental security issue with WebDAV is a testament to 
> the amount of energy in the WG to review this document. Thank you for 
> bringing this up in IETF LC, I think it is good that it has been brought 
> to the attention of the Security ADs.

I am very nervous to publish a revision of RFC2518 with a known, very 
real security issue. Note that I do agree it's not specific to WebDAV 
from a theoretical point of view, but it is likely to occur in the 
context of collaborative authoring, and now what we have been made aware 
of it, it seems to me that it would be best to just document it.

Best regards, Julian

Received on Wednesday, 17 January 2007 13:13:22 UTC