Re: [Bug 19] DAV:no-lock

What about changing it to a MUST?  That makes it even more clear (and  
we will get complaints about lower-case 'must' in the text)

Lisa

On Oct 16, 2005, at 8:42 AM, Julian Reschke wrote:

>
> 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 Tuesday, 18 October 2005 00:35:25 UTC