Re: Draft -16 out now
Geoffrey M Clemm <geoffrey.clemm <at> us.ibm.com>
2006-12-01 21:17:55 GMT
I agree with Julian's points below. In particular:
- Changing the interpretation of DAV:owner would introduce
-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
I did review draft 16, and in general, my conclusion
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.
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
> > chair hat on, it did not seem like failing to fix this was going
> > 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
> in in the LOCK request, not what "creator" (which is the
> 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
> > 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
> > see no objections to that and glad to do it. If you want it fixed
> > everywhere, I think that will require reopening the unresolved
> > 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
> lock is a URI, not a resource. If it would be the resource, locking
> (multiple) bindings wouldn't interoperate.
> If you really think we didn't reach consensus on these points, then
> really think we can give up hope on an RFC2518 revision which at least
> clarifies locking. Right now, it resolves some problems, and adds
> > I also agree the use of section 13 instead of 9 in bug 238 is
> > I'm trying to get my head around the "dav: error response"
> That's admittedly a new issue, but probably can be resolved relatively
> > ...
> >>> Once publication is requested, Ted as the AD would have
> >>> opportunity to review and ask us to correct problems
and it would go
> >>> for IETF LC. This would be another opportunity to identify
> >>> 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
> >> tracked, and the people submitting them frequently get zero
> >> from the authors and the IESG (last experienced with XCAP).
> >> said, I don't think it's a good quality check for a document
> > Hmm - I know some times it seems this way but the IESG usually
> > pretty close look at Last Call comments. My vague recollection
> > XCAP work was their was significant discussion of your comments
> > the document was updated to address some of them. I also seem
> > that Lisa with her AD role actually took some of your comments
> > them as DISCUSS against the document. I'm not claiming for a
> > the handling of XCAP was flawless or that the end result does
> > 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,
> 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