Re: Draft -16 out now

Cullen Jennings schrieb:
>> Issue 244: 
>> <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=244> 
>> (lock creator vs owner)
>>
> 
> 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

Received on Friday, 1 December 2006 20:34:31 UTC