Subject: [Bug 19] DAV:no-lock

From: [email-masked]
Date: Sat, 15 Oct 2005 16:27:28 -0700

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

------- Additional Comments From [email-masked]  2005-10-15 16:27 -------
Fixed for draft version -08.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Oct 2005 17:42:33 +0200

[email-masked] wrote:
> ...

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 17 Oct 2005 17:35:14 -0700

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:

> 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
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Oct 2005 09:13:04 +0200

> we will get complaints about lower-case 'must' in the text)

Again: this follows by definition (only an IETF document/activity cab 
put things into the DAV: namespace, thus a URI using the DAV: scheme 
never can identify a valid lock token).

Furthermore, keep in mind that RFC2119 explicitly asks for using 
capitalized words sparingly.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 18 Oct 2005 13:30:56 -0700

I agree with Julian's suggested text change ("will never match"  
instead of "must never match").

- Jim

On Oct 18, 2005, at 12:13 AM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>
>> 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)
>>
>
> Again: this follows by definition (only an IETF document/activity  
> cab put things into the DAV: namespace, thus a URI using the DAV:  
> scheme never can identify a valid lock token).
>

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Oct 2005 12:29:20 -0700

Ok, will do.

Lisa