Re: Issue 202, Lock-Null resources

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

Cheers,
Geoff

Julian wrote on 03/12/2006 01:26:37 PM:
> 
> 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
> 
>