W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 217] GULP integration

From: <bugzilla@soe.ucsc.edu>
Date: Mon, 30 Jan 2006 23:24:09 -0800
Message-Id: <200601310724.k0V7O9fi031240@ietf.cse.ucsc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:13 GMT