Subject: [Bug 217] GULP integration

From: [email-masked]
Date: Mon, 30 Jan 2006 08:05:41 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=217

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked][email-masked]

------- Additional Comments From [email-masked]  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.