Subject: Issue 202, Lock-Null resources

From: Julian Reschke <[email-masked]>
Date: Sun, 12 Mar 2006 19:26:37 +0100

Following up on issue 202 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=202>)...

I think the current wording in Section 7.3 is extremely confusing, 
because it describes to different models, of which one is deprecated. 
Furthermore, it uses way too many words to describe an extremely simple 
thing (an empty resource that is locked), and gives both models the same 
amount of room.

A very simple change to address this issue is to get rid of most of the 
text, and move the description of the deprecated model into an appendix 
(and no, an appendix can be normative if it isn't stated otherwise).

Proposed text below and in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz202>. 
Also note that in the text to be deleted, the following paragraph...:

     The client is expected to update the locked empty resource shortly
     after locking it, using PUT and possibly PROPPATCH.

..doesn't make any sense at all. Why "shortly"? What difference does 
that make?

Section 7.3., para. 4:
OLD:

     The original WebDAV model for locking unmapped URLs created "lock-
     null resources".  This model was over-complicated and some
     interoperability and implementation problems were discovered.  The
     new WebDAV model for locking unmapped URLs creates "locked empty
     resources".  Servers MUST implement either lock-null resources or
     locked empty resources, but servers SHOULD implement locked empty
     resources.  This section discusses the original model briefly and the
     new model more completely, because clients MUST be able to handle
     either model.

     In the original "lock-null resource" model, which is no longer
     recommended for implementation:

     o  A lock-null resource sometimes appeared as "Not Found".  The
        server responds with a 404 or 405 to any method except for PUT,
        MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.

     o  A lock-null resource does however show up as a member of its
        parent collection.

     o  The server removes the lock-null resource entirely (its URI
        becomes unmapped) if its lock goes away before it is converted to
        a regular resource.  Recall that locks go away not only when they
        expire or are unlcoked, but are also removed if a resource is
        renamed or moved, or if any parent collection is renamed or moved.

     o  The server converts the lock-null resource into a regular resource
        if a PUT request to the URL is successful.

     o  The server converts the lock-null resource into a collection if a
        MKCOL request to the URL is successful (though interoperability
        experience showed that not all servers followed this requirement).

     o  Property values were defined for DAV:lockdiscovery and DAV:
        supportedlock properties but not necessarily for other properties
        like DAV:getcontenttype.

     In the "locked empty resource" model, which is now the recommended
     implementation, a resource created with a LOCK is empty but otherwise
     behaves in every way as a normal resource.  It behaves the same way
     as a resource created by a PUT request with an empty body (and where
     a Content-Type and Content-Language was not specified), followed by a
     LOCK request to the same resource.  Following from this model, a
     locked empty resource:

     o  Can be read, deleted, moved, copied, and in all ways behave as a
        regular resource, not a lock-null resource.

     o  Appears as a member of its parent collection.

     o  SHOULD NOT disappear when its lock goes away (clients must
        therefore be responsible for cleaning up their own mess, as with
        any other operation or any non-empty resource)

     o  MAY NOT have values for properties like DAV:getcontentlanguage
        which haven't been specified yet by the client.

     o  Can be updated (have content added) with a PUT request.

     o  MUST NOT be converted into a collection.  The server MUST fail a
        MKCOL request (as it would with a MKCOL request to any existing
        non-collection resource).

     o  MUST have defined values for DAV:lockdiscovery and DAV:
        supportedlock properties.

     o  The response MUST indicate that a resource was created, by use of
        the "201 Created" response code (a LOCK request to an existing
        resource instead will result in 200 OK).  The body must still
        include the DAV:lockdiscovery property, as with a LOCK request to
        an existing resource.

     The client is expected to update the locked empty resource shortly
     after locking it, using PUT and possibly PROPPATCH.

     Clients can easily interoperate both with servers that support the
     old model "lock-null resources" and the recommended model of "locked
     empty resources" by only attempting PUT after a LOCK to an unmapped
     URL, not MKCOL or GET.

NEW:

     Alternatively and for backwards compatibility to [RFC2518], servers
     MAY implement Lock-Null Resources (LNRs) instead (see definition in
     Appendix D).  Clients can easily interoperate both with servers that
     support the old model LNRs and the recommended model of "locked empty
     resources" by only attempting PUT after a LOCK to an unmapped URL,
     not MKCOL or GET, and by not relying on specific properties of LNRs.

NEW:

  Appendix D.  Lock-Null Resources

     This specification deprecates the "Lock-Null Resources" (LNRs)
     defined in Section 7.4 of [RFC2518], and replaces them with empty
     locked regular resources (see Section 7.3).  However, it's still
     legal for servers to implement the deprecated model.

     A LNR differs from an empty locked resource in the following aspects:

     o  It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed)
        to any methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and
        UNLOCK.

     o  Most of its live properties, such as all the get* properties, will
        have no value as a lock-null resource does not support the GET
        method.  It MUST have defined values for lockdiscovery and
        supportedlock properties.

     o  Until a method such as PUT or MKCOL is successfully executed on
        the lock-null resource the resource MUST stay in the lock-null
        state.  However, once a PUT or MKCOL is successfully executed on a
        lock-null resource the resource ceases to be in the lock-null
        state.  (Note that an LNR thus can be used to create a collection,
        which is not possible with the simplified empty locked resource
        model anymore.)

     o  If it is unlocked, for any reason, without a PUT, MKCOL, or
        similar method having been successfully executed upon it then the
        resource MUST return to the null state.  (Note that with an empty
        locked resource, an empty regular resource would remain in place.)

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 12 Mar 2006 18:59:01 -0500

I agree with Julian's comments, and support his proposed changes.

Cheers,
Geoff

---

From: "John Barone" <[email-masked]>
Date: Mon, 13 Mar 2006 10:24:09 -0800

+1
 
-John

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Geoffrey M Clemm
Sent: Sunday, March 12, 2006 3:59 PM
To: Julian Reschke
Cc: WebDAV; [email-masked]
Subject: Re: Issue 202, Lock-Null resources

Cheers, 
Geoff