Re: Creating a separate Locking-bis protocol specification

A working group has the opportunity when revising a standard
to declare a previously optional aspect of the original spec to be
mandatory.  It happens quite frequently in security documents
(where there is almost a track of new algorithms starting as
optional, becoming mandatory, then being deprecated), and
it happens often enough in APPs contexts that no one would
be surprised if a locking draft that succeeded RFC-2518's
description of locking declared it mandatory.

I am not saying that this *should* happen, but the discussion
of a successor document should take into account that this
would be in scope for such a document.

			regards,
				Ted Hardie



At 6:44 PM -0500 1/18/05, Geoffrey M Clemm wrote:
>Locking support (level 2 WebDAV) is explicitly optional in RFC-2518.
>So I fail to see how defining it in a separate specification has anything
>substantive to do with whether or not a client implementor can rely
>on it being implemented in a server.
>
>So I would phrase the question somewhat differently, e.g.:
>
>"Separating out the optional locking semantics from RFC-2518bis and
>placing it in its own separate specification allows us to resolve 
>the locking issues
>in RFC-2518 in a more expeditious manner.  I'd specifically like to
>hear from client implementors, some of whom (Adobe) rely on locking, as
>to whether they agree that it is important to resolve the locking issues
>more rapidly, by de-coupling them from the rest of the issues in RFC-2518bis."
>
>Cheers,
>Geoff
>
>Lisa wrote on 01/18/2005 03:06:37 PM:
>
>>
>>  Removing locking from base WebDAV is a major step.  Before we take it,
>>  I'd specifically like to hear from client implementors, some of whom
>>  (Adobe) rely on locking being implemented in the server.
>>
>>  Client implementors, please identify yourselves and speak up!
>>
>>  Lisa
>>
>>  On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote:
>>
>>  >
>>  > Julian Reschke wrote:
>>  >
>>  >> Ok,  so do we have consensus to add the following [...]?
>>  >
>>  > I've been considering the various options suggested to address this
>>  > issue since it was raised, along with the various implications. For
>>  > the record, I don't have any problem with the suggested language
>>  > (below) being added to the BIND specification as it seems to address
>>  > Lisas' concerns, while leaving the actual locking behavior specified
>>  > in the core WebDAV specification.
>>  >
>>  > For future reference, I would also like to see similar clarification /
>>  > specification of locking behavior in the presence of multiple bindings
>>  > to a resource appear in either 2518bis or a separate locking
>>  > specification. My preference, once again, is for locking to be broken
>>  > out into a separate specification, as suggested and discussed
>>  > previously on this list. I believe that there was /rough concensus/ on
>>  > that approach the last time it came up.
>>  >
>>  >
>>  > Cheers,
>>  > Elias
>>  > _________________________
>>  >
>>  >> 2.x UNLOCK and Bindings
>>  >>
>>  >> Due to the specific language used in section 8.11 of [RFC2518], it
>>  >> might be thought that an UNLOCK request to a locked resource would
>>  >> unlock just the binding of the Request-URI.  This is not the case,
>>  >> however.  Section 6 of [RFC2518] clearly states that locks are on
>>  >> resources, not URIs, so the server MUST allow UNLOCK to be used to
>>  >> unlock a locked resource through any binding to that resource.  The
>>  >> authors of this specification anticipate and recommend that future
>>  >> revisions of [RFC2518] maintain this behavior.
>>  >
>>  >
>>  >
>>
>>

Received on Wednesday, 19 January 2005 00:08:38 UTC