Re: [Bug 19] DAV:no-lock

bugzilla@soe.ucsc.edu wrote:
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=19
> 
> lisa@osafoundation.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
> 
> 
> 
> ------- Additional Comments From lisa@osafoundation.org  2005-10-15 16:27 -------
> Fixed for draft version -08.
> ...

The change I see is:

Section 9., para. 30:
OLD:

    The If request header is intended to have similar functionality to
    the If-Match header defined in section 14.24 of RFC2616 [7].  However
    the If header is intended for use with any URI which represents state
    information, referred to as a state token, about a resource as well
    as ETags.  A typical example of a state token is a lock token, and
    lock tokens are the only state tokens defined in this specification.
    The <DAV:no-lock> state token is a special token that must never
    match an actual valid lock token.  The purpose of this is described
    in section 9.5.5.

NEW:

    The If request header is intended to have similar functionality to
    the If-Match header defined in section 14.24 of RFC2616 [7].  However
    the If header is intended for use with any URI which represents state
    information, referred to as a state token, about a resource as well
    as ETags.  A typical example of a state token is a lock token, and
    lock tokens are the only state tokens defined in this specification.
    The <DAV:no-lock> state token is an example of a state token that
    must never match an actual valid lock token.  The purpose of this is
    described in Section 9.5.3.


I'd say "will never match" instead if "must never match", because that's 
by definition, not because we tell server implementors to behave that way.

Best regards, Julian

Received on Sunday, 16 October 2005 15:42:54 UTC