- From: <bugzilla@soe.ucsc.edu>
- Date: Mon, 30 Jan 2006 08:05:41 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=217
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
------- Additional Comments From julian.reschke@greenbytes.de 2006-01-30 08:05 -------
Here's some initial feedback for GULP. See proposed changes at
<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
request-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. 7:
OLD:
* If an internal member resource to no longer a member of the
collection, then the resource MUST no longer be indirectly
locked by L.
NEW:
* If an internal member resource is moved or deleted such that
the resource is no longer a member of the collection, then the
resource MUST no longer be indirectly locked by L.
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,
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. [[anchor8:
DISCUSS: so with "/a" and "/b" being URLs mapped to the same
resource, and "/a" being the lock root, can I address UNLOCK to
"/b"???]]
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 a shared write lock on the
same resource there will be five lock tokens, one for each principal.
NEW:
[[anchor9: Incorrect: there'd be five individual locks, each with
it's own lock token.]]
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:
[[anchor11: Duplicates language from Timeout header definition.]]
Section 7., para. 2:
OLD:
An exclusive write lock will prevent parallel changes to a resource
by any principal other than the write lock holder and in any case
where the lock token is not submitted (e.g. by a client process other
than the one holding the lock).
NEW:
An exclusive write lock will prevent parallel changes to a resource
by any principal other than the lock creator and in any case where
the lock token is not submitted (e.g. by a client process other than
the one holding the lock).
Section 7., para. 3:
OLD:
Clients MUST submit a lock-token, and be authenticated as the lock-
owner, in any request which modifies a write-locked resource. The
list of modifications covered by a write-lock include:
NEW:
Clients MUST submit a lock-token (that they are authorized to use),
in any request which affects the lockable state of the resource. The
list of modifications covered by a write-lock include:
Section 7., para. 8:
OLD:
2. A modification of an internal member URI of a write-locked
collection. An internal member URI of a collection is considered
to be modified if it is added, removed, or identifies a different
resource. More discussion on write locks and collections is
found in Section 7.4.
NEW:
2. For collections, any modification of an internal member URI. An
internal member URI is considered to be modified if it is added,
removed, or identifies a different resource. More discussion on
write locks and collections is found in Section 7.4.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Monday, 30 January 2006 16:06:49 UTC