Subject: Re: Draft -16 out now

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Dec 2006 12:01:18 -0800

On Nov 29, 2006, at 5:00 AM, Julian Reschke wrote:

>
>
> 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

> 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.

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 document also lists open LC issues (with no proposed  
>>> resolution), and any kind of constructive feedback on those would  
>>> be very welcome. Alternatively, reviewing the open issue list at  
>>> <http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi? 
>>> product=WebDAV-RFC2518-bis> would be useful as well.
>> I also when thought that whole list (but not the stuff that was  
>> added in November) and asked similar questions. I tried to focus  
>> on issues that were raised before the end of the WGLC. One of the  
>> problems with any document is we can always find yet one more  
>> problem with it so I try to focus on things before WGLC. I do  
>> realize that if we fine a total show stopper bug at any point, we  
>> do have to deal with it. (I just had to deal with a very bad bug  
>> that was found promptly after the RFC was published).
>
> Cullen, the date when something was entered into Bugzilla doesn't  
> indicate when it was raised first. Keep in mind that people raised  
> issues on the mailing list, not Bugzilla. The fact that they *are*  
> in Bugzilla at all is because I tried to keep track of open issues  
> in a systematic way.

True enough.

>
>> Once we sort out this secure network text, I want to request  
>> publication of this. All complex drafts reach a point where you  
>> need to enough has been done, it's not perfect, but it is worth  
>> publishing. I feel the time has come for this draft (actually I  
>> think it is long past). The rate of incremental improvement is  
>> approaching the limit. The time and energy the WG has is small.  
>> The draft is a significant improvement over the previous RFC.  
>> Publishing this does not mean we can' every publish a bis draft to  
>> fix/improve the problems with this draft.
>
> I respectfully disagree. Many parts of the current document are a  
> mess, and although it fixes many issues from RFC2518, it introduces  
> lots of new ones. At this stage, I think a short errata document  
> for RFC2518 would be much more valuable than publishing this draft.

Ok - I accept that may be the case and may in fact may be the  
community consensus. I think that IETF LC is the right place to judge  
consensus on if this should be published and would like to leave this  
issue to that point.

>
>> 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.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Dec 2006 21:34:14 +0100

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

> 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'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.

> ...
>>> 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.
>> 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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 1 Dec 2006 16:17:55 -0500

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

> > chair hat on, it did not seem like failing to fix this was going to 
have

---

From: Manfred Baedke <[email-masked]>
Date: Sat, 02 Dec 2006 00:14:12 +0100

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:
> text

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Dec 2006 15:27:42 -0800

On Dec 1, 2006, at 12:34 PM, Julian Reschke wrote:

> That's admittedly a new issue, but probably can be resolved  
> relatively simply.

100% agree. This is the category of things that I through into the  
"Typo" category.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Dec 2006 15:40:26 -0800

On Dec 1, 2006, at 12:34 PM, Julian Reschke wrote:

>> 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.

This is not really a problem specific to this WG or document - I am  
pretty sure that the vast majority of IETF LC comments do get read  
but I know the IESG has been trying to reduce the odds of things  
getting missed at this stage. You will likely see some updated text  
in the LC email boiler plate some time soon to help with exactly this  
problem. Anyways, I don't think it is particularly relevant to this  
document but yes, noted and people are trying to improve this.

Cullen