WIth my WebDAV WG Chair hat on I would like to make a few comments.
On Jan 15, 2007, at 8:42 AM, Julian Reschke wrote:
... snip...
(4) Examples for open issues
(4a) One of the things RFC2518bis was supposed to fix was the
confusion around locking. Right now, it fails big time. For
instance, it fails to consistently distinguish between the "owner"
and the "creator" of a lock (issue 244), and is inconsistent with
respect to the term "lock root" (sometime it say it's a URI,
sometimes it says it's a resource; which is a significant
difference when a resourse is identified by multiple URIs) (issue
251).
This was identified as an issues in WGLC and Ted as our AD has been
working on it.
(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.
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.
(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.
Cullen <with my WebDAV Chair hat on>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf