- From: <bugzilla@soe.ucsc.edu>
- Date: Sun, 5 Feb 2006 13:17:39 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=217
------- Additional Comments From julian.reschke@greenbytes.de 2006-02-05 13:17 -------
I've re-read Sections 6, 7 and 9 and have additional comments about GULP in
particular, and locking in general. For some of the problems I've made proposed
changes, in other case I just annotated my version of the draft. See
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz217>
and below:
Section 6.1., para. 3:
OLD:
2. A resource becomes directly locked when a LOCK request to the URL
of that resource creates a new lock. The "lock-root" of the new
lock is that resource. If at the time of the request, the URL is
not mapped to a resource, a new empty resource is created and
directly locked.
NEW:
2. A resource becomes directly locked when a LOCK request to the URL
of that resource creates a new lock. The "lock-root" of the new
lock is that URL. If at the time of the request, the URL is not
mapped to a resource, a new empty resource is created and
directly locked.
Section 6.1., para. 9:
OLD:
6. An UNLOCK request deletes the lock with the specified lock token,
provided that the request is addressed to a resource that is
either directly or indirectly locked by that lock. After a lock
is deleted, no resource is locked by that lock.
NEW:
6. An UNLOCK request deletes the lock with the specified lock token.
After a lock is deleted, no resource is locked by that lock.
Section 6.2., para. 2:
OLD:
However, there are times when the goal of a lock is not to exclude
others from exercising an access right but rather to provide a
mechanism for principals to indicate that they intend to exercise
their access rights. Shared locks are provided for this case. A
shared lock allows multiple principals to receive a lock. Hence any
principal with appropriate access can use the lock.
NEW:
However, there are times when the goal of a lock is not to exclude
others from exercising an access right but rather to provide a
mechanism for principals to indicate that they intend to exercise
their access rights. Shared locks are provided for this case,
allowing multiple principals to receive a lock.[[anchor8: Avoid a
potential misunderstanding: each principal will need its own shared
lock, they will *not* share the same lock!]]
Section 6.2., para. 7:
OLD:
A successful request for a new shared lock MUST result in the
generation of a unique lock token associated with the requesting
principal. Thus if five principals have taken out shared write locks
on the same resource there will be five locks and five lock tokens,
one for each principal.
NEW:
[[anchor9: This is now correct but can be said much simpler.]]
Section 6.4., para. 1:
OLD:
The creator of a lock has special privileges to use the locked
resource. The server MUST restrict the usage of a lock token to the
creator of the lock, both for shared and exclusive locks. For multi-
user shared lock cases, each authenticated principal MUST obtain its
own shared lock.
The server MAY allow privileged users other than the lock creator to
destroy a lock (for example, the resource owner or an administrator)
as a special case of lock usage.
NEW:
The creator of a lock has special privileges to use the locked
resource. The server MUST restrict the usage of a lock token to the
creator of the lock, both for shared and exclusive locks. For multi-
user shared lock cases, each authenticated principal MUST obtain its
own shared lock. [[anchor11: Misleading. Lock creator checks only
apply (as a MUST level requirement) to lock token submission in the
If header; removing the lock using UNLOCK is a separate thing.
Furthermore, making a special statement about shared locks IMHO is
confusing here.]]
The server MAY allow privileged users other than the lock creator to
destroy a lock (for example, the resource owner or an administrator)
as a special case of lock usage.[[anchor12: Mention RFC3744, Section
3.5 (DAV:unlock privilege)?]]
Section 6.4., para. 2:
OLD:
If an anonymous user requests a lock, the server MAY refuse the
request.
NEW:
If an anonymous user requests a lock, the server MAY refuse the
request. [[anchor13: Does this really need to be stated? After all,
a server MAY refuse the request for lots of other reasons, even if
the user is authenticated.]]
Section 6.5., para. 1:
OLD:
A lock token is a type of state token, represented as a URI, which
identifies a particular lock. Each lock has exactly one unique lock
token generated by the server. Clients MUST NOT attempt to interpret
lock tokens in any way.
NEW:
A lock token is a type of state token, represented as a URI, which
identifies a particular lock. [[anchor14: "state token" is defined in
10.4 as "any URI which represents state information"; proposing to
move the definition into Section 3.]]Each lock has exactly one unique
lock token generated by the server. Clients MUST NOT attempt to
interpret lock tokens in any way.
Section 6.5., para. 4:
OLD:
Submitting a lock token does not confer full privilege to use the
lock token or modify the locked resource. Write access and other
privileges MUST be enforced through normal privilege or
authentication mechanisms, not based on the possible obscurity of
lock token values.
NEW:
[[anchor15: This repeats stuff from the previous subsection.]]
Section 6.6., para. 2:
OLD:
Clients MUST assume that locks may arbitrarily disappear at any time,
regardless of the value given in the Timeout header. The Timeout
header only indicates the behavior of the server if extraordinary
circumstances do not occur. For example, a sufficiently privileged
user may remove a lock at any time or the system may crash in such a
way that it loses the record of the lock's existence.
NEW:
[[anchor16: Duplicates language from Timeout header definition. This
may be the better place, but then please let's cleanup the Timeout
header definition.]]
Section 7.3., para. 3:
OLD:
A successful lock request to an unmapped URL MUST result in the
creation of an locked resource with empty content. Subsequently, a
successful PUT request (with the correct lock token) provides the
content for the resource, and a server that normally uses the client-
provided content-type MUST also use the content-type and content-
language information from this request.
NEW:
A successful lock request to an unmapped URL MUST result in the
creation of an locked resource with empty content. Subsequently, a
successful PUT request (with the correct lock token) provides the
content for the resource.
Section 7.4., para. 1:
OLD:
A write lock on a collection, whether created by a "Depth: 0" or
"Depth: infinity" lock request, prevents the addition or removal of
member URLs of the collection by principals other than the lock
creator.
NEW:
A write lock on a collection, whether created by a "Depth: 0" or
"Depth: infinity" lock request, prevents the addition, removal or
modification of an internal member URL or of its mapping, unless the
associated lock token is submitted with the request.
Section 7.4., para. 2:
OLD:
A zero-depth lock on a collection affects changes to the direct
membership of that collection. When a principal issues a write
request to create a new resource in a write locked collection, or
isses a DELETE, MOVE or other request that would remove an existing
internal member URL of a write locked collection or change the
binding name, this request MUST fail if the principal does not
provide the correct lock token for the locked collection.
NEW:
A zero-depth lock on a collection affects changes to the direct
membership of that collection. When a principal issues a write
request to create a new resource in a write locked collection, or
issues a DELETE, MOVE or other request that would remove an existing
internal member URL of a write locked collection or change the
binding name, this request MUST fail if the client does not provide
the correct lock token for the locked collection.
Section 7.4., para. 4:
OLD:
o DELETE a collection's direct internal member
NEW:
o DELETE a collection's direct internal member,
Section 7.4., para. 5:
OLD:
o MOVE a member out of the collection
NEW:
o MOVE a member out of the collection,
Section 7.4., para. 6:
OLD:
o MOVE a member into the collection
NEW:
o MOVE a member into the collection,
Section 7.4., para. 7:
OLD:
o MOVE to rename a member within a collection
NEW:
o MOVE to rename a member within a collection,
Section 7.4., para. 8:
OLD:
o COPY a member into a collection
NEW:
o COPY a member into a collection,
Section 7.4., para. 16:
OLD:
If a lock creator causes the URL of a resource to be added as an
internal member URL of a depth-infinity locked collection then the
new resource MUST be automatically added to the lock. This is the
only mechanism that allows a resource to be added to a write lock.
Thus, for example, if the collection /a/b/ is write locked and the
resource /c is moved to /a/b/c then resource /a/b/c will be added to
the write lock.
NEW:
If a lock request causes the URL of a resource to be added as an
internal member URL of a depth-infinity locked collection then the
new resource MUST be automatically added to the lock. This is the
only mechanism that allows a resource to be added to a write lock.
Thus, for example, if the collection /a/b/ is write locked and the
resource /c is moved to /a/b/c then resource /a/b/c will be added to
the write lock.
Section 7.7., para. 1:
OLD:
A client MUST NOT submit the same write lock request twice. Note
that a client is always aware it is resubmitting the same lock
request because it must include the lock token in the If header in
order to make the request for a resource that is already locked.
However, a client may submit a LOCK method with an If header but
without a body. This form of LOCK MUST only be used to "refresh" a
lock. Meaning, at minimum, that any timers associated with the lock
MUST be re-set.
A server may return a Timeout header with a lock refresh that is
different than the Timeout header returned when the lock was
originally requested. Additionally clients may submit Timeout
headers of arbitrary value with their lock refresh requests.
Servers, as always, may ignore Timeout headers submitted by the
client. Note that timeout is measured in seconds remaining until
expiration.
If an error is received in response to a refresh LOCK request the
client MUST NOT assume that the lock was refreshed.
NEW:
[[anchor25: IMHO all of this can go. This paragraph is just
misleading; repeating a LOCK request with an existing lock token in
the If header is going to fail for an exclusive lock anway.]]
[[anchor26: Just point to the paragraph in the LOCK definition here.
At a minimum, fix above sentence to say "request" instead of
"method".]]
Section 9.10.1., para. 1:
OLD:
A LOCK request to an existing resource will create a lock on the
resource identified by the Request-URI, provided the resource is not
already locked with a conflicting lock. The resource identified in
the Request-URI becomes the root of the lock. Lock method requests
to create a new lock MUST have a XML request body which contains an
'owner' XML element and other information for this lock request. The
server MUST preserve the information provided by the client in the
'owner' field when the lock information is requested. The LOCK
request MAY have a Timeout header.
NEW:
A LOCK request to an existing resource will create a lock on the
resource identified by the Request-URI, provided the resource is not
already locked with a conflicting lock. The resource identified in
the Request-URI becomes the root of the lock. Lock method requests
to create a new lock MUST have a XML request body which contains
information for this lock request. The server MUST preserve the
information provided by the client in the 'owner' field when the lock
information is requested. The LOCK request MAY have a Timeout
header.
Section 9.10.4., para. 1:
OLD:
A successful LOCK method MUST result in the creation of an empty
resource which is locked (and which is not a collection), when a
resource did not previously exist at that URL. Later on, the lock
may go away but the empty resource remains. Empty resources MUST
then appear in PROPFIND responses including that URL in the response
scope. A server MUST respond successfully to a GET request to an
empty resource, either by using a 204 No Content response, or by
using 200 OK with a Content-Length header indicating zero length and
no Content-Type.
NEW:
A successful LOCK method MUST result in the creation of an empty
resource which is locked (and which is not a collection), when a
resource did not previously exist at that URL. Later on, the lock
may go away but the empty resource remains. Empty resources MUST
then appear in PROPFIND responses including that URL in the response
scope. A server MUST respond successfully to a GET request to an
empty resource, either by using a 204 No Content response, or by
using 200 OK with a Content-Length header indicating zero length and
no Content-Type. [[anchor54: This section repeats text from Section
6, but in an inconsistent way.]]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Sunday, 5 February 2006 21:17:48 UTC