Re: Draft -16 out now

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 
list,
until the problems in the current draft can be fixed.

Cheers,
Geoff

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 
have 
> > a significant chance of causing non interoperable implementations

> Yes, it would. That's why it's one of the significant changes from 
RFC2518.
> 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. 
If 
> > you think we should fix it in this one place using your proposed text, 
I 
> > 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 
on 
> > 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 
more.
> 
> > 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 
being 
> >> 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 
that 
> > the document was updated to address some of them. I also seem to 
recall 
> > that Lisa with her AD role actually took some of your comments and 
added 
> > them as DISCUSS against the document. I'm not claiming for a second 
that 
> > 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
>