Re: Draft -16 out now

I definitely agree with Julian and Geoff.
Obviously, Julian has put quite some effort in merging the results of 
the WG last call reviews into his draft. I have difficulties to 
understand why this progress should be thrown away.

Regards,
Manfred

Geoffrey M Clemm wrote:
>
> 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
> >