W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2006

Re: Draft -16 out now

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Fri, 1 Dec 2006 16:17:55 -0500
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Cullen Jennings <fluffy@cisco.com>, Ted Hardie <hardie@qualcomm.com>, Lisa Dusseault <lisa@osafoundation.org>, WebDav <w3c-dist-auth@w3.org>, w3c-dist-auth-request@w3.org
Message-ID: <OFBDF92DE9.26D4730E-ON85257237.0072FFD9-85257237.00753D72@us.ibm.com>
I agree with Julian's points below.  In particular:
- Changing the interpretation of DAV:owner would introduce a significant
interoperability problem.
-There has always been consensus that the root of a lock is a URI, not a
resource, but that text never seems to make it into a draft.

I did review draft 16, and in general, my conclusion is
that without significant change (such as adopting much of the content of
Julian's draft), this draft would do more harm than good, and that it
would be better for the WebDAV community to just issue a brief errata 
until the problems in the current draft can be fixed.


Julian wrote on 12/01/2006 03:34:14 PM:
> Cullen Jennings schrieb:
> >> Issue 244: 
> >> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=244> 
> > Thought I might like to see this fixed, when I looked at this with my 
> > chair hat on, it did not seem like failing to fix this was going to 
> > a significant chance of causing non interoperable implementations

> Yes, it would. That's why it's one of the significant changes from 
> Existing clients rely on the fact that DAV:owner is whatever they passed 

> in in the LOCK request, not what "creator" (which is the authenticated 
> principal who did the LOCK).

> That's something completely different. If we even don't get simple 
> things like this right, we really should stop.
> >> Issue 251:
> >> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=251> 
> >> (lock root being a URI, not a resource)
> > 
> > On this one, it seems that the issue occurs in many places in the text 

> > and is one of the main areas of unresolved consensus around locking. 
> > you think we should fix it in this one place using your proposed text, 
> > see no objections to that and glad to do it. If you want it fixed 
> > everywhere, I think that will require reopening the unresolved issues 
> > locking and I view that as a 6 month to 2 year project.
> Cullen, sorry, but again this is not something where there was any 
> disagreement. This is not an unresolved issue at all. The root of the 
> lock is a URI, not a resource. If it would be the resource, locking and 
> (multiple) bindings wouldn't interoperate.
> If you really think we didn't reach consensus on these points, then I 
> really think we can give up hope on an RFC2518 revision which at least 
> clarifies locking. Right now, it resolves some problems, and adds some 
> > I also agree the use of section 13 instead of 9 in bug 238 is a bug.
> > 
> > I'm trying to get my head around the "dav: error response" thread.
> That's admittedly a new issue, but probably can be resolved relatively 
> simply.
> > ...
> >>> Once publication is requested, Ted as the AD would have the 
> >>> opportunity to review and ask us to correct problems and it would go 

> >>> for IETF LC. This would be another opportunity to identify any true 
> >>> show stopper problems that absolutely needed to be fixed.
> >>> Cullen <with me chair hat on>
> >>
> >> My experience is that comments sent during IETF Last Call aren't 
> >> tracked, and the people submitting them frequently get zero feedback 
> >> from the authors and the IESG (last experienced with XCAP). That 
> >> said, I don't think it's a good quality check for a document anymore.
> >>
> > 
> > Hmm - I know some times it seems this way but the IESG usually takes a 

> > pretty close look at Last Call comments. My vague recollection of the 
> > XCAP work was their was significant discussion of your comments and 
> > the document was updated to address some of them. I also seem to 
> > that Lisa with her AD role actually took some of your comments and 
> > them as DISCUSS against the document. I'm not claiming for a second 
> > the handling of XCAP was flawless or that the end result does not have 

> > significant problems, but I do think your comments were heard.
> The problem with the IESG LC process in general is that it completely 
> lacks visibility. You don't know whether people read your comments, any 
> you usually do not get any feedback at all, until it is too late (that 
> is, the IESG approved the document). Fix that process issue, and IESG 
> Last Call actually will become a useful test for a spec.
> Best regards, Julian
Received on Friday, 1 December 2006 21:18:23 UTC

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