W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2007

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

From: Cullen Jennings <fluffy@cisco.com>
Date: Mon, 15 Jan 2007 17:24:09 -0800
Message-Id: <43C6CED4-7BA0-4CB0-9A97-2308E59991AB@cisco.com>
Cc: ietf@ietf.org, w3c-dist-auth@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC