LNRs (lock null resources) in RFC2518bis

Hi,

this is an attempt to summarize the current status regarding RFC2518bis' 
deprecation of lock-null resources, and what's IMHO left to do.

History:

In RFC2518, applying LOCK to an unmapped URL creates a so-called Lock 
Null Resource (LNR), which reserves the URL, but doesn't create a 
full-blown resource. Subsequently applying PUT or MKCOL transforms the 
LNR into a locked resource or collection. Not doing so causes the LNR to 
disappear after the associated lock expires.

Experience has shown that LNRs have made server implementations much 
more complicated, and many servers never have implemented them correctly 
(for instance, IIS). Furthermore (as as far as I can tell), there's 
little evidence of real-world clients that actually require LNRs to work 
as defined by RFC2518 (there may have been one response suggesting 
otherwise that I currently can't locate; maybe this was from Apple??)


Consensus points:

I think there's broad consensus that we want allow servers to implement 
a simpler model, and clients to require to interoperate with these 
simplified servers.

The stripped-down requirements are:

R1) A successful LOCK applied to an unmapped URL creates an empty, 
locked, regular resource (called ELR from here).

And that's it. No additional requirements.


We have disagreement on:

1) Are servers still allowed to implement the old model?

2) If so, how do we express this in the spec?



To make progress on these remaining questions, let's have a look at the 
additional requirements of LNRs over ELRs:

R2) Live properties and collection containment reflect the LNR status of 
the resource (see 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.4> and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.7.6> 
for details).

R3) The LNR can be converted into an ELR by applying PUT or MKCOL.

R4) If it isn't, it disappears.



Let' assume for a moment that we continue to allow servers to implement 
LNRs. What would be the impact for clients that expect the simplified 
behaviour?

I1) The resource may go away when the client lets the lock expire: this 
is an edge condition. If a client really handles this case, it will have 
to do a subsequent DELETE, and getting a 404 upon that one would be 
completely harmless.

I2) Clients may be confused by some specifics of PROPFIND on the parent 
(member not listed) or on the resource itself (some live properties 
missing), but this will be completely harmless as long as the client 
sends a PUT after the LOCK, which is the likely use case anyway.

So to me it seems that allowing servers to continue to support the old 
model is harmless.


Current draft (10):

The current draft says that servers MUST support either ELRs or LNRs, 
and that they SHOULD implement ELRs 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.7.6>). 
It also says that servers implementing LNRs are not compliant to this 
spec, which I think is a spec bug (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.E.1.p.13>). 
It also requires servers (MUST level) to accept a Content-Type request 
header upon PUT, which is a totally new requirement, and really has 
nothing to do with the whole issue (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.7.6.p.9>).


I think this needs to be improved. Suggestion:

- Make only those aspects of ELRs required that are actually relevant to 
the client, meaning that a subsequent PUT with the correct If header 
leads to a regular locked resource being created.

- Suggest that implementing ELRs is the simplest way to achieve these 
requirements.

- Thus allow servers to continue implementing LNRs; clients that really 
care can discover the type of resource being created by doing a 
subsequent PROPFIND on the LOCKed URL.


That's it.

Feedback appreciated,

Julian

Received on Monday, 9 January 2006 21:41:19 UTC