Subject: [Bug 217] GULP integration

From: [email-masked]
Date: Sun, 5 Feb 2006 13:17:39 -0800

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

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