W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 19] DAV:no-lock

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 16 Oct 2005 17:42:33 +0200
Message-ID: <435274E9.3000002@gmx.de>
To: w3c-dist-auth@w3.org

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 GMT

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