Re: Remaining issues with the bind draft -- process

Geoffrey M Clemm wrote:

>I strongly support choice #3 (issuing a locking draft).
>If we are considering defining locking behavior in a 
>separate draft that isn't about locking (i.e. the bind draft),
>then I think doing so in a separate draft makes the most sense.
>  
>
Apologies for jumping into this thread late, I've been traveling on 
business and unable to keep up with the discussion. Anyway, I'd like to 
offer my (non-binding) +1 on issuing GULP as a seperate draft - this 
approach seems to be the most reasonable way to proceed at this juncture.

Elias

>Especially if Julian has done most of the editorial work
>(thanks, Julian!), we should be able to focus on it after
>the binding draft is finalized, and get it out soon afterwards
>(once it is decoupled from the many unresolved issues in
>the rest of 2518bis).
>
>Cheers,
>Geoff
>
>Julian wrote on 04/05/2004 06:13:27 PM:
>
>  
>
>>Ted Hardie wrote:
>>
>>    
>>
>>>Speaking personally, my concern here would be that if those 
>>>clarifications were not
>>>present, BIND behavior became non-deterministic.  If 2518bis was done, 
>>>      
>>>
>and
>  
>
>>>BIND pointed to it to solve that hypothetical problem, all might be 
>>>goodness; if
>>>it will not be done, on the other hand, getting the job done in the 
>>>      
>>>
>spec 
>  
>
>>>which
>>>will be completed might be the practical way to go.
>>>
>>>Again, my personal two cents,
>>>            regards,
>>>                Ted
>>>      
>>>
>>If we rephrase that as "There should be a standards-track document 
>>clarifying WebDAV looking as soon as possible.", I'll absolutely agree. 
>>However, I think that document shouldn't be BIND, if only for the simple 
>>    
>>
>
>  
>
>>reason that it matters to those who don't plan to implement BIND at all 
>>as well.
>>
>>If we can't get RFC2518bis finished soon, I think the approaches (2) and 
>>    
>>
>
>  
>
>>(3) presented in 
>><http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html> 
>>    
>>
>
>  
>
>>would make more sense:
>>
>>--
>>2) Come up with a separate spec that updates RFC2518 and just summarizes
>>all that we changed or intend to change regarding locking (like
>>deprecation of lock-null resources, fixes to LOCK and lock refresh, If
>>header syntax, and lockdiscovery extensions). That would still be a
>>"draft standard" as RFC2518, but it would make things easier for
>>RFC2518bis as well, because all these changes would be written down in a
>>spec that came out prior to the revision, so wouldn't be "new" anymore.
>>It would also encourage implementors to actually *implement* these
>>changes and extensions *before* RFC2518bis comes out.
>>
>>3) A drastic approach would be to de-couple locking entirely from
>>RFC2518 ("updating" RFC2518 again). That would look similar to how
>>RFC3253 is organized (locking would become an optional module, and
>>everything that needs to be said about locking would reside in that
>>separate document). Of course that approach would have a significant
>>impact on RFC2518bis, because optimally, it wouldn't say anything about
>>locking anymore either.
>>--
>>
>>I'm willing to help working on either; we just need working group 
>>consensus to do this as it would affect the (currently dormant?) 
>>activities on RFC2518bis.
>>
>>As an experiment, I've already extracted locking from RFC2518. This 
>>turned out to be relatively simple *except* for the locking semantics 
>>built into the "If" header checks (which will require some more 
>>thinking). BTW: RFC2518 shrinks by about 30% (interested parties just 
>>email me for a copy).
>>
>>Regards, Julian
>>
>>-- 
>><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>>    
>>

Received on Tuesday, 13 April 2004 14:53:27 UTC