- From: <bugzilla@soe.ucsc.edu>
- Date: Mon, 30 Jan 2006 23:24:09 -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
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From julian.reschke@greenbytes.de 2006-01-30 23:24 -------
Well, only part of the changes were done, so I guess we need to discuss the
remainding differences (see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz217>):
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.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:
[[anchor8: This is now correct but can be said much simpler.]]
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:
[[anchor10: Duplicates language from Timeout header definition.]]
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.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Tuesday, 31 January 2006 07:24:18 UTC