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