W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2006

Re: Draft -16 out now

From: Cullen Jennings <fluffy@cisco.com>
Date: Fri, 1 Dec 2006 12:01:18 -0800
Message-Id: <DC09A325-9068-451D-8ECB-A362089015F3@cisco.com>
Cc: Ted Hardie <hardie@qualcomm.com>, Lisa Dusseault <lisa@osafoundation.org>
To: Julian Reschke <julian.reschke@gmx.de>, WebDav <w3c-dist-auth@w3.org>

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  

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.
Received on Friday, 1 December 2006 20:01:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC