- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 12 Mar 2006 19:26:37 +0100
- To: WebDAV <w3c-dist-auth@w3.org>
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
Received on Sunday, 12 March 2006 18:28:08 UTC