- From: Cullen Jennings <fluffy@cisco.com>
- Date: Mon, 15 Jan 2007 17:24:09 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf@ietf.org, w3c-dist-auth@w3.org
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>
Received on Tuesday, 16 January 2007 01:25:29 UTC