Subject: lock-null's Still Locked after MKCOL or PUT conversion?

From: John Baumgarten <[email-masked]>
Date: Wed, 26 Jan 2005 13:54:10 -0800

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?

-Jake

John S "Jake" Baumgarten
Apple .Mac Backend Server Engineering

[email-masked]
Cupertino CA 95014 USA
www.apple.com

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Jan 2005 23:37:51 +0100

> 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

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: John Reese <[email-masked]>
Date: Fri, 28 Jan 2005 16:50:56 -0800

> URL creates an empty and locked (non-collection) resource.

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.

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?

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Jan 2005 10:06:46 +0100

> resource (in RFC 2518)?  I found this hard to deduce based from the

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.

> do locks remain if a resource is overwritten by a MOVE or COPY?

Same answers.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 29 Jan 2005 09:04:24 -0500

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

---

From: Joe Hildebrand <[email-masked]>
Date: Sun, 30 Jan 2005 16:51:12 -0700

> itself is extremely harmful.

Perhaps we should go ahead and start an implementation guide wiki (or 
similar), so that the "guidance" texts have a place to live, so that 
people feel like those clarifications won't get lost if they aren't in 
the spec.

Those who want a more explicit spec won't like this, since the text 
will clearly be non-normative, and there will be two places to go to 
figure out what to implement.  However, if it means that implementors 
don't have to solve the puzzle box themselves (if they know where to 
look), maybe that would be good enough.

> but it would be wrong and remiss of us to do so.

And I'm sure that folks who are concerned about the potential for 
interop problems feel similarly.  Let's see if we can't explore some 
ways to work together with each other without having to resort to the 
assumption that bad faith exists.

As I've said recently, standards-making is both a technical *and* a 
political process.  Finding a way to achieve consensus, while not 
giving up on core convictions such as these requires copious amounts of 
maturity, camaraderie, or self-deprecating humor.

> Ah, those were the days (:-).

Um, this last bit may have strayed slightly from the collegiate tone 
that Ted was just trying to coax us towards.  Anything else I could 
stay would push us even further from that ideal.

-- 
Joe Hildebrand
Denver, CO, USA

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 30 Jan 2005 21:07:26 -0500

I'd like to thank Joe for his continued patience and good humor.
I will try harder in the future to emulate his good example (:-).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Jan 2005 13:23:46 +0100

> people feel like those clarifications won't get lost if they aren't in 

Funny enough, we *do* have a Wiki running on webdav.org 
(<http://www.webdav.org/wiki/projects/SubWiki>), installed by Greg 
Stein. We could give that one a try.

> Those who want a more explicit spec won't like this, since the text will 
> clearly be non-normative, and there will be two places to go to figure 
> out what to implement.  However, if it means that implementors don't 
> have to solve the puzzle box themselves (if they know where to look), 
> maybe that would be good enough.

Also, discussion and collaboration over there may end in text that can 
go into potential spec errata, spec revisions or new documents.

> ...

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 31 Jan 2005 09:30:43 -0800

The goal of writing protocol specifications is to create an on-demand
communicative experience conveying sufficient knowledge about the data
models, behavior, and on-the-wire marshalling of protocol elements such that
an implementor can create a protocol implementation that is correct with
respect to the specification, and is interoperable with other
implementations. 

To the best of my knowledge, there is no research on the effectiveness of
RFCs at communicating a protocol specification. As a result, there is simply
no factual basis for either side of the argument concerning adding, or not
adding, clarification text. The largely anecdotal evidence supports both
sides. RFCs are long, and generally getting longer, leading to more shallow
review. As a result, we should keep them as short as possible, with little
or no clarification text. On the other side, even the most successful
protocols have interoperability issues. It is my understanding that upwards
of 25% of the code base of FTP protocol libraries is dedicated to handling
interoperability issues with specific implementations. The IETF process
itself has been developed assuming that interoperability problems are
inevitable in implementations of RFCs, and need to be worked out over time.

Arguments from first principles can also support both sides. Given a
protocol that provides a clear description of its data model, behavior, and
on-the-wire marshalling, an implementor should be possible to use logical
implication to determine protocol behavior in all circumstances. Hence, no
clarification text should be necessary, since in the extreme one would list
all possible implications. Even when backing off from the extreme, it is
difficult to pick a criteria for which implications to explicitly include,
and which ones to omit. 

At present our specifications are only partially written using formal
languages, and there are no explicitly defined logical implication rules for
operating on specification assertions. As a result, it is *not* reasonable
to assume that even careful readers will be using the same set of
implication rules to answer questions about the specification. In fact,
given the lack of formally expressed implication rules, there is no way to
determine if different implication sets would lead to conflicting
conclusions about the specification. In this situation, the best proxy for
such knowledge is a situation where experienced protocol specifiers draw
different conclusions about protocol behavior. Since these experts have some
form of interal mechanism for making implications from protocol assertions,
lack of agreement is indicative of a situation where the application of
different implication rule sets lead to contradictory conclusions in the
specification. In such situations, it is useful to add clarification text to
disambiguate the outcomes of applying contradictory implication chains.

Since protocol specifiers can reasonably have differing opinions on the
value of clarifying text, what is a reasonable rule of thumb working groups
can use to determine when to include clarification text?

Ted Hardie's guidance here is right-on. If you have a situation where:

1) Expert opinion in a working group is divided after significant
discussion, or 
2) It took expert opinion considerable effort to develop a consensus
understanding of a non-normative behavior,

... then ... 

*) If adding clarification text seems likely to increase interoperability,
it should be included. If it seems likely to have no effect, or decrease
interoperability, omit it. Additionally, any added text should be judged to
be worth the cost in additional specification length.

That is, if you have reasonable evidence supporting the conclusion there is
an implication chain conflict among experienced readers, then if you can
develop clear language clarifying the issue, it should be included. Since
many implications are straightforward, and do not lead to disagreement, this
criteria acts to discourage widespread inclusion of clarification text.
Furthermore, any addition should weight its cost in terms of adding
specification length. A multi-page example to settle a minor point is
probably not a good tradeoff. One or two sentences to clarify a point is
likely a reasonable tradeoff.

Finally, it should be recalled that interoperability problems are
fantastically expensive. Changing a single interoperability problem in the
field can take years, and require significant engineering time across
multiple organizations. If we as protocol specifiers can eliminate such
errors, we save other engineers much time and money, and save end users from
frustration and delay.

- Jim