Perils of "guidance" (was Re: lock-null's Still Locked after MKCOL or PUT conversion?)

This situation with lock-null resources is a good illustration
of the perils of placing "guidance" on how to use a given feature
in specifications that don't define that feature.

In 2518bis, we are adjusting the behavior that results when you
apply LOCK to an unmapped URI, because of interoperability problems
with the "lock-null resource" approach defined in RFC-2518.

If all of our other specifications (e.g., DeltaV and ACL) carefully
gave guidance on how to handle lock-null resources (and there are
far more problematic interactions between DeltaV and ACL with 
lock-null resources, than there are between BIND and locking or etags),
we would have a huge mess on our hands when RFC-2518bis was released.

It is that kind of experience that cause the authors of the BIND
specification to keep pushing back strongly on placing in a
specification guidance on features defined in 
other specifications, especially for aspects of those features
currently under design discussion (such as whether or not you have
to apply UNLOCK to the URL to which the LOCK was originally applied).

And to be clear, there certainly is the need for documents that
give implementation guidance to implementors (and with the internet,
there are a variety of inexpensive mechanisms for distributing
that information), but putting that guidance in the specification
itself is extremely harmful.

It would be very easy (and very tempting) for the authors that are
largely exhausted by this process to just agree to put in random
bits of this kind of guidance even though we know it is harmful,
but it would be wrong and remiss of us to do so.

I believe the recent support from Roy has demonstrated that there are
experienced and successful protocol designers that agree with the
position taken by the authors.  It used to be the case that the
chair of the WebDAV working group gave guidance and suggestions,
but ultimately respected the judgement and experience of the authors. 
Ah, those were the days (:-).

Cheers,
Geoff

Julian wrote on 01/29/2005 04:06:46 AM:
> 
> John Reese wrote:
> > On Wed, 26 Jan 2005 23:37:51 +0100, Julian Reschke
> > <julian.reschke@gmx.de> wrote:
> > 
> >>John Baumgarten wrote:
> >>
> >>>All-
> >>>
> >>>I've searched through the mail archives and 2518 and 2518bis-06, so
> >>>forgive me if this is a well-known issue.
> >>>
> >>>After a lock-null has been converted to a either a collection or
> >>>"regular" resource via a MKCOL or PUT, respectively, should the
> >>>resulting resource still be locked?
> >>
> >>In RFC2518: yes. That's the whole point.
> >>
> >>In RFC2518bis: the concept doesn't exist anymore. LOCK to an unmapped
> >>URL creates an empty and locked (non-collection) resource.
> >>
> >>Best regards, Julian
> > 
> > 
> > And what happens if you MOVE or COPY a resource onto a lock-null
> > resource (in RFC 2518)?  I found this hard to deduce based from the
> > RFC.
> 
> MOVE with Overwrite implicitly deletes the resource, so it will be gone 
> (with it's lock): 
> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.9.3>.
> 
> The behaviour for COPY will depend on whether the server implements 
> RFC2518's definition 
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.8.4>) or 
> RFC3253's clarification 
> (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.7>). In 
> the latter case (if you supply the lock token), the resource will be 
> updated, staying locked.
> 
> > In 2518bis, I guess I have the same question -- on the new, empty,
> > locked resource, a PUT to overwrite the content retains the LOCK.  But
> > do locks remain if a resource is overwritten by a MOVE or COPY?
> 
> Same answers.
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>