Subject: Combined set of issues around lock tokens, examples, schemes

From: Lisa Dusseault <[email-masked]>
Date: Sat, 22 Oct 2005 10:07:48 -0700

There are several issues that intersect around lock token requirements 
and examples.

  - Some examples use the "locktoken" scheme which is defined nowhere
  - The examples that use strings like "locktoken:a-lock-token" could be 
converted to "opaquelocktoken:a-lock-token" but then that would be an 
example of an invalid URI according to the rules of the 
"opaquelocktoken" scheme and we generally want to provide "best 
practices" examples (note, however, at the slight expense of 
readability)
  - In the meantime, RFC4122 appeared and makes it unnecessary for 
WebDAV to define how to do a UUID -- and we noticed that it defines a 
scheme as well (urn:uuid:)

What about resolving these by getting rid of the opaquelocktoken 
scheme?  The specification requirements would still make it legal to 
use any legal URI that was unique, so existing servers using 
"opaquelocktoken" would not be made non-compliant by this change.  It 
would simplify the spec by relying more on RFC4122 and defining one 
fewer new scheme and a bit of syntax associated with that scheme.

In summary a recommended (but not the only) form for lock tokens would 
be a UID in RFC4122 format, for example:
   "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

This seemed to make sense to Julian, Jim, Geoff and myself on the call 
today, so if we missed anything, or anybody has objections, please 
raise them.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Oct 2005 20:53:18 +0200

>  - Some examples use the "locktoken" scheme which is defined nowhere

Correct. The spec shouldn't do that.

> practices" examples (note, however, at the slight expense of readability)

Yes.

>  - In the meantime, RFC4122 appeared and makes it unnecessary for WebDAV 
> to define how to do a UUID -- and we noticed that it defines a scheme as 
> well (urn:uuid:)

That's a change that's already in -- draft 07 doesn't specify how to 
generate UUIDs anymore.

Section 6.4 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.6.4>) 
  says:

--
In order to guarantee uniqueness across all resources for all time a 
server MAY use the Universal Unique Identifier (UUID) [9] mechanism to 
generate a lock token:

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly 
while still guaranteeing the lock token to be unique across all 
resources for all time. With the 'opaquelocktoken' scheme, the server 
MAY reuse a UUID with extension characters added. If the server does 
this then the algorithm generating the extensions MUST guarantee that 
the same extension will never be used twice with the associated UUID.

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID 
production is the string representation of a UUID. Note that white space 
(LWS) is not allowed between elements of this production.

Extension = path ; path is defined in section 3.3 of RFC2396 [5]
--

Besides fixing the obvious editorial problems here (ABNF examples and 
spec in the same paragraph), I don't see why we need to take out even more.

> scheme?  The specification requirements would still make it legal to use 
> any legal URI that was unique, so existing servers using 

The "opaquelocktoken" scheme is defined in RFC2518. Existing servers use 
it and are unlikely to stop using it (unless there's a replacement that 
provides exactly the same sematics). If RFC2518bis is going to 
"obsolete" RFC2518, I think it needs to keep the scheme declaration. On 
the other hand, if it doesn't keep it, I'll probably submit that as a 
separate spec.

Again: if it ain't broke don't fix it. I don't see any benefit in 
removing it, but lots of additional work and confusion if we do.

>   "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

It just happens to be a simple URN scheme that fulfills the requirements 
for lock tokens. RFC2518 always allowed different schemes, and we should 
not make the impression that this changed.

> today, so if we missed anything, or anybody has objections, please raise 
> them.

+1 on having valid lock tokens in examples
+1 on using urn:uuid URIs to do that
+1 on simplifying the definition of "opaquelocktoken" by simply 
referring to the UUID generation instructions in RFC4122 (already done 
in draft 07)
-1 on removing the definition of "opaquelocktoken"

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 23 Oct 2005 14:22:44 +0200

OK,

below a proposal to resolve issues 20 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=20>, "Lock 
Token Examples"), 91 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=91>, "chapter 
name for lock token uri schemes"), 102 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=102>, "lock 
tokens in examples") and 99 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=99>, "Risks 
Connected with Lock Tokens").

It does this by

- fixing examples (URI scheme, syntax, whitespace), always using 
syntactically legal urn:uuid URIs

- rewriting section 6.4, getting rid of 6.5 consequently

- fixing the security consideratios, basically re-using the text from 
RFC2518 and just fix what was broken or out-of-date

- move "opaquelocktoken" definition into appendix with minimally 
required spec text

The changes are:

Section 6., para. 16:
OLD:

    This specification provides a lock token URI scheme called
    opaquelocktoken that meets the uniqueness requirements.  However
    resources are free to return any URI scheme so long as it meets the
    uniqueness requirements.  According to current IETF best practices,
    implementations SHOULD use registered URI schemes to ensure
    uniqueness.

NEW:

    A robust method for generating a lock token fulfilling the uniqueness
    requirements is to leverage the "Universally Unique IDentifier"
    (UUID) mechanism.  URI schemes that can use UUIDs are the "UUID" URN
    Namespace defined in [9] and the "opaquelocktoken" URI scheme defined
    in Appendix C.

    However resources are free to return any URI scheme so long as it
    meets the uniqueness requirements.  According to current IETF best
    practices, implementations SHOULD use registered URI schemes to
    ensure uniqueness.

Section 6., para. 19:
OLD:

  6.4  Lock Token URI Schemes

    In order to guarantee uniqueness across all resources for all time a
    server MAY use the Universal Unique  Identifier (UUID) [9] mechanism
    to generate a lock token:

    The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly
    while still guaranteeing the lock token to be unique across all
    resources for all time.  With the 'opaquelocktoken' scheme, the
    server MAY reuse a UUID with extension characters added.  If the
    server does this then the algorithm generating the extensions MUST
    guarantee that the same extension will never be used twice with the
    associated UUID.

    OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
    production is the string representation of a UUID.  Note that white
    space (LWS) is not allowed between elements of this production.

  6.5  Lock Capability Discovery

NEW:

  6.4  Lock Capability Discovery

Section 7., para. 77:
OLD:

          COPY /~fielding/index.html HTTP/1.1
          Host: www.ics.uci.edu
          Destination: http://www.ics.uci.edu/users/f/fielding/index.html
          If: <http://www.ics.uci.edu/users/f/fielding/index.html>
              (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

NEW:

          COPY /~fielding/index.html HTTP/1.1
          Host: www.ics.uci.edu
          Destination: http://www.ics.uci.edu/users/f/fielding/index.html
          If: <http://www.ics.uci.edu/users/f/fielding/index.html>
              (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

Section 8., para. 219:
OLD:

          MOVE /container/ HTTP/1.1
          Host: www.example.com
          Destination: http://www.example.com/othercontainer/
          Overwrite: F
          If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
              (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)

NEW:

          MOVE /container/ HTTP/1.1
          Host: www.example.com
          Destination: http://www.example.com/othercontainer/
          Overwrite: F
          If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
              (<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)

Section 8., para. 260:
OLD:

        HTTP/1.1 200 OK
        Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

NEW:

        HTTP/1.1 200 OK
        Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
        Content-Type: text/xml; charset="utf-8"
        Content-Length: xxxx

Section 8., para. 261:
OLD:

        <?xml version="1.0" encoding="utf-8" ?>
        <D:prop xmlns:D="DAV:">
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype><D:write/></D:locktype>
             <D:lockscope><D:exclusive/></D:lockscope>
             <D:depth>infinity</D:depth>
             <D:owner>
               <D:href>
                 http://www.ics.uci.edu/~ejw/contact.html
               </D:href>
             </D:owner>
             <D:timeout>Second-604800</D:timeout>
             <D:locktoken>
               <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
        00a0c91e6be4</D:href>
             </D:locktoken>
             <D:lockroot>
               <D:href>http://example.com/workspace/webdav
                 /proposal.doc</D:href>
             </D:lockroot>
           </D:activelock>
         </D:lockdiscovery>
        </D:prop>

NEW:

        <?xml version="1.0" encoding="utf-8" ?>
        <D:prop xmlns:D="DAV:">
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype><D:write/></D:locktype>
             <D:lockscope><D:exclusive/></D:lockscope>
             <D:depth>infinity</D:depth>
             <D:owner>
               <D:href>
                 http://www.ics.uci.edu/~ejw/contact.html
               </D:href>
             </D:owner>
             <D:timeout>Second-604800</D:timeout>
             <D:locktoken>
               <D:href
        >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
             </D:locktoken>
             <D:lockroot>
               <D:href
        >http://example.com/workspace/webdav/proposal.doc</D:href>
             </D:lockroot>
           </D:activelock>
         </D:lockdiscovery>
        </D:prop>

Section 8., para. 263:
OLD:

     Note that the locktoken and lockroot href elements would not contain
     any whitespace.  The line return appearing in this document is only
     for formatting.

  8.11.7  Example - Refreshing a Write Lock

NEW:

  8.11.7  Example - Refreshing a Write Lock

Section 8., para. 265:
OLD:

       LOCK /workspace/webdav/proposal.doc HTTP/1.1
       Host: example.com
       Timeout: Infinite, Second-4100000000
       Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
       Authorization: Digest username="ejw",
          realm="[email-masked]", nonce="...",
          uri="/workspace/webdav/proposal.doc",
          response="...", opaque="..."

NEW:

       LOCK /workspace/webdav/proposal.doc HTTP/1.1
       Host: example.com
       Timeout: Infinite, Second-4100000000
       Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
       Authorization: Digest username="ejw",
          realm="[email-masked]", nonce="...",
          uri="/workspace/webdav/proposal.doc",
          response="...", opaque="..."

Section 8., para. 268:
OLD:

        <?xml version="1.0" encoding="utf-8" ?>
        <D:prop xmlns:D="DAV:">
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype><D:write/></D:locktype>
             <D:lockscope><D:exclusive/></D:lockscope>
             <D:depth>infinity</D:depth>
             <D:owner>
               <D:href>
               http://www.ics.uci.edu/~ejw/contact.html
               </D:href>
             </D:owner>
             <D:timeout>Second-604800</D:timeout>
             <D:locktoken>
               <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
        00a0c91e6be4</D:href>
             </D:locktoken>
             <D:lockroot>
               <D:href>http://example.com/workspace/webdav
                 /proposal.doc</D:href>
             </D:lockroot>
           </D:activelock>
         </D:lockdiscovery>
        </D:prop>

NEW:

        <?xml version="1.0" encoding="utf-8" ?>
        <D:prop xmlns:D="DAV:">
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype><D:write/></D:locktype>
             <D:lockscope><D:exclusive/></D:lockscope>
             <D:depth>infinity</D:depth>
             <D:owner>
               <D:href>
               http://www.ics.uci.edu/~ejw/contact.html
               </D:href>
             </D:owner>
             <D:timeout>Second-604800</D:timeout>
             <D:locktoken>
               <D:href
        >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
             </D:locktoken>
             <D:lockroot>
               <D:href
        >http://example.com/workspace/webdav /proposal.doc</D:href>
             </D:lockroot>
           </D:activelock>
         </D:lockdiscovery>
        </D:prop>

Section 8., para. 292:
OLD:

        UNLOCK /workspace/webdav/info.doc HTTP/1.1
        Host: example.com
        Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
        Authorization: Digest username="ejw",
           realm="[email-masked]", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

NEW:

        UNLOCK /workspace/webdav/info.doc HTTP/1.1
        Host: example.com
        Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
        Authorization: Digest username="ejw",
           realm="[email-masked]", nonce="...",
           uri="/workspace/webdav/proposal.doc",
           response="...", opaque="..."

Section 8., para. 295:
OLD:

     In this example, the lock identified by the lock token
     "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
     successfully removed from the resource
     http://example.com/workspace/webdav/info.doc.  If this lock included
     more than just one resource, the lock is removed from all resources
     included in the lock.  The 204 (No Content) status code is used
     instead of 200 (OK) because there is no response entity body.

NEW:

     In this example, the lock identified by the lock token
     "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully
     removed from the resource
     http://example.com/workspace/webdav/info.doc.  If this lock included
     more than just one resource, the lock is removed from all resources
     included in the lock.  The 204 (No Content) status code is used
     instead of 200 (OK) because there is no response entity body.

Section 9., para. 38:
OLD:

        If: (<opaquelocktoken:a-write-lock-token> ["I am an ETag"]), (["I
        am another ETag"])

NEW:

        If: (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
             ["I am an ETag"]),
            (["I am another ETag"])

Section 9., para. 39:
OLD:

    The previous header would require that the resource identified in the
    Request-URI be locked with the specified lock token and in the state
    identified by the "I am an ETag" ETag or in the state identified by
    the second ETag "I am another ETag".  To put the matter more plainly
    one can think of the previous If header as being in the form (or (and
    <opaquelocktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am
    another ETag"])).

NEW:

    The previous header would require that the resource identified in the
    Request-URI be locked with the specified lock token and in the state
    identified by the "I am an ETag" ETag or in the state identified by
    the second ETag "I am another ETag".  To put the matter more plainly
    one can think of the previous If header as being in the form (or (and
    <urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> ["I am an ETag"])
    (and ["I am another ETag"])).

Section 9., para. 44:
OLD:

         COPY /resource1 HTTP/1.1
         Host: www.example.com
         Destination: http://www.example.com/resource2
         If: <http://www.example.com/resource1>
              (<opaquelocktoken:a-write-lock-token> [W/"A weak ETag"]), 
(["strong ETag"]),
             <http://www.bar.bar/random>
              (["another strong ETag"])

NEW:

         COPY /resource1 HTTP/1.1
         Host: www.example.com
         Destination: http://www.example.com/resource2
         If: <http://www.example.com/resource1>
              (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
               [W/"A weak ETag"]),
              (["strong ETag"]),
             <http://www.bar.bar/random>
              (["another strong ETag"])

Section 9., para. 45:
OLD:

     In this example http://www.example.com/resource1 is being copied to
     http://www.example.com/resource2.  When the method is first applied
     to http://www.example.com/resource1, resource1 must be in the state
     specified by "(<opaquelocktoken:a-write-lock-token> [W/"A weak
     ETag"]) (["strong ETag"])", that is, it either must be locked with a
     lock token of "opaquelocktoken:a-write-lock-token" and have a weak
     entity tag W/"A weak ETag" or it must have a strong entity tag
     "strong ETag".

NEW:

     In this example http://www.example.com/resource1 is being copied to
     http://www.example.com/resource2.  When the method is first applied
     to http://www.example.com/resource1, resource1 must be in the state
     specified by "(<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC> [W/"A
     weak ETag"]) (["strong ETag"])", that is, it either must be locked
     with a lock token of "urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC"
     and have a weak entity tag W/"A weak ETag" or it must have a strong
     entity tag "strong ETag".

Section 9., para. 49:
OLD:

          If: (Not <opaquelocktoken:write1> <opaquelocktoken:write2>)

NEW:

          If: (Not <urn:uuid:E90CB889-97CA-49b9-AC33-111111111111>
               <urn:uuid:E90CB889-97CA-49b9-AC33-222222222222>)

Section 9., para. 50:
OLD:

    When submitted with a request, this If header requires that all
    operand resources must not be locked with opaquelocktoken:write1 and
    must be locked with opaquelocktoken:write2.

NEW:

    When submitted with a request, this If header requires that all
    operand resources must not be locked with
    urn:uuid:E90CB889-97CA-49b9-AC33-111111111111 and must be locked with
    urn:uuid:E90CB889-97CA-49b9-AC33-222222222222.

Section 9., para. 58:
OLD:

     DELETE /specs/rfc2518.txt HTTP/1.1
     Host: www.example.com
     If: <http://www.example.com/specs/> 
(<opaquelocktoken:a-write-lock-token>)

NEW:

      DELETE /specs/rfc2518.txt HTTP/1.1
      Host: www.example.com
      If: <http://www.example.com/specs/>
          (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>)

Section 13., para. 19:
OLD:

     Description:  The href contains a single lock token URI which refers
        to the lock (i.e., the OpaqueLockToken-URI production in section
        6.4).

NEW:

     Description:  The href contains a single lock token URI which refers
        to the lock.

Section 14., para. 85:
OLD:

          <?xml version="1.0" encoding="utf-8" ?>
          <D:multistatus xmlns:D='DAV:'>
           <D:response>
             <D:href>http://www.example.com/container/</D:href>
             <D:propstat>
               <D:prop>
                 <D:lockdiscovery>
                  <D:activelock>
                   <D:locktype><D:write/></D:locktype>
                   <D:lockscope><D:exclusive/></D:lockscope>
                   <D:depth>0</D:depth>
                   <D:owner>Jane Smith</D:owner>
                   <D:timeout>Infinite</D:timeout>
                   <D:locktoken>
                     <D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-
          00a0c91a9d76</D:href>
                   </D:locktoken>
                   <D:lockroot>
                     <D:href>http://www.example.com/container/</D:href>
                   </D:lockroot>
                   </D:activelock>
                 </D:lockdiscovery>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
             </D:propstat>
           </D:response>
          </D:multistatus>

NEW:

          <?xml version="1.0" encoding="utf-8" ?>
          <D:multistatus xmlns:D='DAV:'>
           <D:response>
             <D:href>http://www.example.com/container/</D:href>
             <D:propstat>
               <D:prop>
                 <D:lockdiscovery>
                  <D:activelock>
                   <D:locktype><D:write/></D:locktype>
                   <D:lockscope><D:exclusive/></D:lockscope>
                   <D:depth>0</D:depth>
                   <D:owner>Jane Smith</D:owner>
                   <D:timeout>Infinite</D:timeout>
                   <D:locktoken>
                     <D:href
          >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>
                   </D:locktoken>
                   <D:lockroot>
                     <D:href>http://www.example.com/container/</D:href>
                   </D:lockroot>
                   </D:activelock>
                 </D:lockdiscovery>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
             </D:propstat>
           </D:response>
          </D:multistatus>

Section 19., para. 24:
OLD:

    This specification requires the use of Universal  Unique Identifiers
    (UUIDs) [9] for lock tokens, in order to guarantee their uniqueness
    across space and time.  The security considerations for UUIDs do not
    apply because WebDAV does not assume that lock tokens are supposed to
    be hard to guess or require integrity.  In addition, UUIDs MAY
    contain a IEEE 802 node ID, usually the host address.  Since a WebDAV
    server will issue many locks over its lifetime, the use of node IDs
    might cause the WebDAV server to reveal its IEEE 802 address.
    Several risks are related to this:

NEW:

    This specification recommends the use of Universal Unique Identifiers
    (UUIDs) for lock tokens, in order to guarantee their uniqueness
    across space and time.  UUIDs, as defined in [9], contain a "node"
    field which "consists of the IEEE address, usually the host address.
    For systems with multiple IEEE 802 nodes, any available node address
    can be used."  Since a WebDAV server will issue many locks over its
    lifetime, the implication is that it will also be publicly exposing
    its IEEE 802 address.

    There are several risks associated with exposure of IEEE 802
    addresses.  Using the IEEE 802 address:

Section 19., para. 28:
OLD:

  19.8  Hosting malicious scripts executed on client machines

NEW:

     Section 4.5 of [9] details an alternate mechanism for generating the
     "node" field of a UUID without using an IEEE 802 address, which
     alleviates the risks associated with exposure of IEEE 802 addresses
     by using an alternate source of uniqueness.

  19.8  Hosting malicious scripts executed on client machines

Section 20., para. 4:
OLD:

    This specification also defines a URI scheme for the encoding of lock
    tokens, the opaquelocktoken URI scheme described in section 6.4.

NEW:

    This specification also defines the "opaquelocktoken" URI scheme for
    the encoding of lock tokens (see Appendix C).

NEW:

  Appendix C.  'opaquelocktoken' URI Scheme

    The 'opaquelocktoken' URI scheme defined below uses the Universal
    Unique Identifier (UUID) mechanism ([9], Section 4) to easily
    generate lock tokens fulfilling the uniqueness requirements stated in
    Section 6.3.

      OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
      ; UUID: see [RFC4122], Section 3.
      ; path: see [RFC3986], Section 3.3.

    Note that the optional "path" postfix allows to generate many lock
    tokens from a single URI, by appending an varying string such as a
    sequence number.

    Example:

      opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017

--- draft-ietf-webdav-rfc2518bis-latest.xml	2005-10-21 16:12:09.000000000 +0100
+++ draft-ietf-webdav-rfc2518bis-latest.20.xml	2005-10-23 13:02:21.000000000 +0100
@@ -601,7 +601,7 @@
    </t>
   </section>
   
-  <section title="Lock Tokens">
+  <section title="Lock Tokens" anchor="lock.tokens">
     <t>
    A lock token is a type of state token, represented as a URI, which 
    identifies a particular lock.  A lock token is returned in the Lock-
@@ -619,11 +619,16 @@
    resources and servers without fear of confusion. 
     </t>
     <t>
-   This specification provides a lock token URI scheme called 
-   opaquelocktoken that meets the uniqueness requirements.  However 
-   resources are free to return any URI scheme so long as it meets the 
-   uniqueness requirements.  According to current IETF best practices, implementations
-   SHOULD use registered URI schemes to ensure uniqueness. 
+      A robust method for generating a lock token fulfilling the 
+      uniqueness requirements is to leverage the "Universally Unique IDentifier"
+      (UUID) mechanism.  URI schemes that can use UUIDs are the "UUID" URN
+      Namespace defined in <xref target="RFC4122"/> and the "opaquelocktoken"
+      URI scheme defined in <xref target="opaquelocktoken.uri.scheme"/>.
+    </t>
+    <t>
+     However resources are free to return any URI scheme so long as it meets the 
+     uniqueness requirements.  According to current IETF best practices, implementations
+     SHOULD use registered URI schemes to ensure uniqueness. 
     </t>
     <t>
    Submitting a lock token does not confer full privilege to use
@@ -640,31 +645,6 @@
     </t>
   </section>
   
-  <section title="Lock Token URI Schemes">
-    <t>
-   In order to guarantee uniqueness across all resources for all time 
-   a server MAY use the <xref target="RFC4122">Universal Unique 
-   Identifier (UUID)</xref> mechanism to generate a lock token:
-    </t>
-    <t>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</t>
-    <t>The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly 
-      while still guaranteeing the lock token to be unique across all 
-   resources for all time.  With the 'opaquelocktoken' scheme, the server MAY 
-   reuse a UUID with extension characters added.  If the server does this then
-      the algorithm generating the extensions MUST guarantee that the same 
-   extension will never be used twice with the associated UUID. 
-    </t>
-    <t>
-   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The 
-   UUID production is the string representation of a UUID. Note 
-      that white space (LWS) is not allowed between 
-   elements of this production. 
-    </t>
-    <t>
-   Extension = path  ; path is defined in section 3.3 of <xref target="RFC2396">RFC2396</xref> 
-    </t>
-  </section>
-  
   <section title="Lock Capability Discovery">
     <t>
    Since server lock support is optional, a client trying to lock a 
@@ -1039,7 +1019,7 @@
      Host: www.ics.uci.edu 
      Destination: http://www.ics.uci.edu/users/f/fielding/index.html 
      If: <http://www.ics.uci.edu/users/f/fielding/index.html> 
-         (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) 
+         (<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) 

    >>Response 
@@ -2441,8 +2421,8 @@
      Host: www.example.com 
      Destination: http://www.example.com/othercontainer/ 
      Overwrite: F 
-     If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) 
-         (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) 
+     If: (<urn:uuid:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) 
+         (<urn:uuid:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) 

    >>Response 
@@ -2688,7 +2668,7 @@
  >>Response 
   
    HTTP/1.1 200 OK 
-   Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4> 
+   Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4> 
    Content-Type: text/xml; charset="utf-8" 
    Content-Length: xxxx 
     
@@ -2706,12 +2686,12 @@
         </D:owner> 
         <D:timeout>Second-604800</D:timeout> 
         <D:locktoken> 
-          <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
-   00a0c91e6be4</D:href> 
+          <D:href
+   >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href> 
         </D:locktoken> 
         <D:lockroot> 
-          <D:href>http://example.com/workspace/webdav 
-            /proposal.doc</D:href> 
+          <D:href
+   >http://example.com/workspace/webdav/proposal.doc</D:href> 
         </D:lockroot> 
       </D:activelock> 
     </D:lockdiscovery> 
@@ -2729,11 +2709,6 @@
    seconds).  Note that the nonce, response, and opaque fields have not 
    been calculated in the Authorization request header. 
           </t>
-          <t>
-   Note that the locktoken and lockroot href elements would not contain 
-   any whitespace.  The line return appearing in this document is only 
-   for formatting. 
-          </t>
     </section>
     
     <section title="Example - Refreshing a Write Lock">
@@ -2744,7 +2719,7 @@
    LOCK /workspace/webdav/proposal.doc HTTP/1.1 
    Host: example.com 
    Timeout: Infinite, Second-4100000000 
-   Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4> 
+   Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4> 
    Authorization: Digest username="ejw", 
       realm="[email-masked]", nonce="...", 
       uri="/workspace/webdav/proposal.doc", 
@@ -2770,12 +2745,12 @@
         </D:owner> 
         <D:timeout>Second-604800</D:timeout> 
         <D:locktoken> 
-          <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-
-   00a0c91e6be4</D:href> 
+          <D:href
+   >urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href> 
         </D:locktoken> 
         <D:lockroot> 
-          <D:href>http://example.com/workspace/webdav 
-            /proposal.doc</D:href> 
+          <D:href
+   >http://example.com/workspace/webdav /proposal.doc</D:href> 
         </D:lockroot> 
       </D:activelock> 
     </D:lockdiscovery> 
@@ -2919,7 +2894,7 @@
   
    UNLOCK /workspace/webdav/info.doc HTTP/1.1 
    Host: example.com 
-   Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> 
+   Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> 
    Authorization: Digest username="ejw", 
       realm="[email-masked]", nonce="...", 
       uri="/workspace/webdav/proposal.doc", 
@@ -2933,7 +2908,7 @@
       <t>
       
    In this example, the lock identified by the lock token 
-   "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 
+   "urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is 
    successfully removed from the resource 
    http://example.com/workspace/webdav/info.doc.  If this lock included 
    more than just one resource, the lock is removed from all resources 
@@ -3118,7 +3093,7 @@
   
   <section title="If Header" anchor="if-header">
     <figure>
-      <artwork>
+      <artwork type="abnf2616">
    If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) 
    No-tag-list = List 
    Tagged-list = Resource 1*List 
@@ -3179,8 +3154,9 @@
       <figure>
         <preamble>Example - no-tag-list production</preamble>
         <artwork><![CDATA[
-   If: (<opaquelocktoken:a-write-lock-token> ["I am an ETag"]), (["I 
-   am another ETag"]) 
+   If: (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
+        ["I am an ETag"]),
+       (["I am another ETag"]) 
         ]]></artwork>
       </figure>
       <t>
@@ -3189,7 +3165,7 @@
    state identified by the "I am an ETag" ETag or in the state 
    identified by the second ETag "I am another ETag".  To put the 
    matter more plainly one can think of the previous If header as being 
-   in the form (or (and &lt;opaquelocktoken:a-write-lock-token&gt; ["I am an 
+   in the form (or (and &lt;urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC&gt; ["I am an 
    ETag"]) (and ["I am another ETag"])). 
       </t>
     </section>
@@ -3220,7 +3196,9 @@
      Host: www.example.com 
      Destination: http://www.example.com/resource2 
      If: <http://www.example.com/resource1> 
-          (<opaquelocktoken:a-write-lock-token> [W/"A weak ETag"]), (["strong ETag"]), 
+          (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>
+           [W/"A weak ETag"]),
+          (["strong ETag"]), 
          <http://www.bar.bar/random> 
           (["another strong ETag"]) 
     ]]></artwork>
@@ -3229,9 +3207,9 @@
    In this example http://www.example.com/resource1 is being copied to 
    http://www.example.com/resource2.  When the method is first applied 
    to http://www.example.com/resource1, resource1 must be in the state 
-   specified by "(&lt;opaquelocktoken:a-write-lock-token&gt; [W/"A weak ETag"]) 
+   specified by "(&lt;urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC&gt; [W/"A weak ETag"]) 
    (["strong ETag"])", that is, it either must be locked with a lock 
-   token of "opaquelocktoken:a-write-lock-token" and have a weak entity tag 
+   token of "urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC" and have a weak entity tag 
    W/"A weak ETag" or it must have a strong entity tag "strong ETag". 
       </t>
       <t>
@@ -3254,13 +3232,14 @@
      </t>
       <figure>
         <artwork><![CDATA[
-     If: (Not <opaquelocktoken:write1> <opaquelocktoken:write2>) 
+     If: (Not <urn:uuid:E90CB889-97CA-49b9-AC33-111111111111>
+          <urn:uuid:E90CB889-97CA-49b9-AC33-222222222222>) 
         ]]></artwork>
       </figure>
       <t>
    When submitted with a request, this If header requires that all 
-   operand resources must not be locked with opaquelocktoken:write1 and must 
-   be locked with opaquelocktoken:write2. 
+   operand resources must not be locked with urn:uuid:E90CB889-97CA-49b9-AC33-111111111111 and must 
+   be locked with urn:uuid:E90CB889-97CA-49b9-AC33-222222222222. 
       </t>
       <t>
    The Not production is particularly useful with the "&lt;DAV:no-lock&gt;" 
@@ -3294,9 +3273,10 @@
             <figure>
         <preamble>Example - Matching lock tokens with collection locks</preamble>
         <artwork><![CDATA[
- DELETE /specs/rfc2518.txt HTTP/1.1 
- Host: www.example.com 
- If: <http://www.example.com/specs/> (<opaquelocktoken:a-write-lock-token>) 
+  DELETE /specs/rfc2518.txt HTTP/1.1 
+  Host: www.example.com 
+  If: <http://www.example.com/specs/>
+      (<urn:uuid:E90CB889-97CA-49b9-AC33-0C653DF3FDAC>) 
     ]]></artwork>
     <postamble>For this example, the lock token must be compared to the 
         identified resource, which is the 'specs' collection identified by
@@ -3571,9 +3551,7 @@
       be returned unless some other error is returned.  On the other hand,
       if the client did not include a conditional header in the request,
       then the server MUST NOT use this error.
-      
     </t>
-    
   </section>
   
   <section title="414 Request-URI Too Long">
@@ -3740,8 +3718,7 @@
     <t hangText="Namespace: ">DAV:</t> 
     <t hangText="Purpose: ">The lock token associated with a lock. </t>
     <t hangText="Description: ">The href contains a single lock token URI which refers 
-            to the lock (i.e., the OpaqueLockToken-URI production in 
-            section 6.4). </t>
+            to the lock.</t>
    <t hangText="Extensibility: ">MAY be extended with additional child elements or 
             attributes which SHOULD be ignored if not recognized. </t>
     </list>
@@ -4500,8 +4477,8 @@
               <D:owner>Jane Smith</D:owner> 
               <D:timeout>Infinite</D:timeout> 
               <D:locktoken> 
-                <D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-
-     00a0c91a9d76</D:href> 
+                <D:href
+     >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href> 
               </D:locktoken> 
               <D:lockroot> 
                 <D:href>http://www.example.com/container/</D:href> 
@@ -5120,27 +5097,34 @@
   
   <section title="Risks Connected with Lock Tokens">
     <t>
-   This specification requires the use of <xref target="RFC4122">Universal 
-   Unique Identifiers (UUIDs)</xref> for lock tokens, in order to guarantee 
-   their uniqueness across space and time.  The security considerations 
-      for UUIDs do not apply because WebDAV does not assume that lock tokens
-      are supposed to be hard to guess or require integrity.   In addition,
-      UUIDs MAY contain a IEEE 802 node ID, usually the host address.  Since a 
-      WebDAV server will 
-   issue many locks over its lifetime, the use of node IDs might cause the 
-      WebDAV server to reveal its IEEE 802 address. Several risks are related
-      to this:
-    </t>
-    <t><list style="symbols">
-      <t>It is possible to track the movement of hardware from subnet to 
-   subnet.</t> 
-    
-      <t>It may be possible to identify the manufacturer of the hardware 
-   running a WebDAV server. 
+       This specification recommends the use of Universal
+       Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
+       their uniqueness across space and time.  UUIDs, as defined in <xref target="RFC4122" />,
+       contain a "node" field which "consists of the IEEE address,
+       usually the host address.  For systems with multiple IEEE 802 nodes,
+       any available node address can be used."  Since a WebDAV server will
+       issue many locks over its lifetime, the implication is that it will
+       also be publicly exposing its IEEE 802 address.
+    </t>
+    <t>
+       There are several risks associated with exposure of IEEE 802
+       addresses.  Using the IEEE 802 address:
+    </t>
+    <t>
+      <list style="symbols">
+       <t>It is possible to track the movement of hardware from subnet to
+       subnet.</t>
+       <t>It may be possible to identify the manufacturer of the hardware
+       running a WebDAV server.</t>
+       <t>It may be possible to determine the number of each type of computer
+       running WebDAV.</t>
+    </list></t>
+    <t>
+      Section 4.5 of <xref target="RFC4122"/> details an alternate mechanism
+      for generating the "node" field of a UUID without using an IEEE 802
+      address, which alleviates the risks associated with exposure of IEEE
+      802 addresses by using an alternate source of uniqueness.
     </t>
-      <t>It may be possible to determine the number of each type of 
-   computer running WebDAV. </t>
-     </list></t>
   </section>
   
   <section title="Hosting malicious scripts executed on client machines">
@@ -5191,9 +5175,8 @@
    referred to as "DAV:creationdate" for brevity. 
   </t>
   <t>
-   This specification also defines a URI scheme for the encoding of 
-   lock tokens, the opaquelocktoken URI scheme described in section 
-   6.4. 
+   This specification also defines the "opaquelocktoken" URI scheme for the
+   encoding of lock tokens (see <xref target="opaquelocktoken.uri.scheme"/>).
   </t>
   <t>
    To ensure correct interoperation based on this specification, IANA 
@@ -5643,6 +5626,29 @@
   </section>
 </section>
 
+<section title="'opaquelocktoken' URI Scheme" anchor="opaquelocktoken.uri.scheme">
+  <t>
+   The 'opaquelocktoken' URI scheme defined below uses the Universal Unique
+   Identifier (UUID) mechanism (<xref target="RFC4122"/>, Section 4) to
+   easily generate lock tokens fulfilling the uniqueness requirements
+   stated in <xref target="lock.tokens"/>.
+  </t>
+<figure><artwork type="abnf">
+  OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
+  ; UUID: see [RFC4122], Section 3.
+  ; path: see [RFC3986], Section 3.3.
+</artwork></figure>
+  <t>
+    Note that the optional "path" postfix allows to generate many lock tokens
+    from a single URI, by appending an varying string such as a sequence
+    number.
+  </t>
+<figure><preamble>Example:</preamble><artwork type="abnf">
+  opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017
+</artwork></figure>
+</section>
+  
+
 </back>
 </rfc>

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 23 Oct 2005 16:03:56 -0700

On Oct 22, 2005, at 11:53 AM, Julian Reschke wrote:
>>
>
> The "opaquelocktoken" scheme is defined in RFC2518. Existing servers 
> use it and are unlikely to stop using it (unless there's a replacement 
> that provides exactly the same sematics). If RFC2518bis is going to 
> "obsolete" RFC2518, I think it needs to keep the scheme declaration. 
> On the other hand, if it doesn't keep it, I'll probably submit that as 
> a separate spec.
>

Can you elaborate on the work and confusion?   Here's the whole set of 
text that would be removed:

     The 'opaquelocktoken' URI scheme extends the UUID mechanism slightly
       while still guaranteeing the lock token to be unique across all
    resources for all time.  With the 'opaquelocktoken' scheme, the 
server MAY
    reuse a UUID with extension characters added.  If the server does 
this then
       the algorithm generating the extensions MUST guarantee that the 
same
    extension will never be used twice with the associated UUID.

    OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The
    UUID production is the string representation of a UUID. Note
       that white space (LWS) is not allowed between
    elements of this production.

Removing that text doesn't stop server implementors from using 
"opaquelocktoken" or make them non-compliant if they continue to use 
it.  I still recommend removing it now that we have the "urn:uuid:" 
namespace to recommend instead.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2005 09:40:15 +0200

Lisa Dusseault wrote:
>       the algorithm generating the extensions MUST guarantee that the same

I thought we were working on obsoleting RFC2518. RFC2223 defines what 
this means:

---
Obsoletes

       To be used to refer to an earlier document that is replaced by
       this document.  This document contains either revised information,
       or else all of the same information plus some new information,
       however extensive or brief that new information is; i.e., this
       document can be used alone, without reference to the older
       document.
---

As far as I understand this means that there's a chance that the URI 
scheme "opaquelocktoken" will not be considered a registered URI scheme 
anymore if we remove it. I don't think it's worth that just to save 
something like 15 lines of text in the spec.

So before removing it, I'd prefer that someone gets a statement from 
IANA/IETF what this means for the registration status.

Regarding your question: people will be confused when opaquelocktoken 
isn't registered anymore. Additional work (ie, writing a separate RFC) 
will be required to fix this.

I'd also like to point out that opaquelocktoken has semantics that go 
beyond urn:uuid, so there are many cases where an implementor can't 
simply switch schemes.

So, again:

+1 on recommending urn:uuid
+1 on using it examples
+1 on simplifying the opaquelocktoken definition to rely on RFC4122 but
-1 on removing the scheme declaration

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 24 Oct 2005 07:40:21 -0400

Perhaps we could just mention opaquelocktoken in a "deprecated" section.
We can indicate there that "opaquelocktoken" is a registered IANA scheme
defined in 2518 (to remove any concerns about its loss of registration)
but that it has been deprecated in favor of urn:uuid.

This gets opaquelocktoken out of the main body of the text (I'm in favor
of anything we can do do simplify the main body of 2518bis), without
creating any confusion about the registration of the opaquelocktoken 
scheme.

Cheers,
Geoff

same

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 24 Oct 2005 09:36:06 -0700

I had assumed that removing opaquelocktoken from RFC2518bis would leave 
it registered because it would remain registered in RFC2518.  The BCP 
on registering schemes 
(ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) doesn't say much on 
obsoleting schemes in STD track documents.    The registration page 
doesn't show any info about obsoleted or historic schemes 
(http://www.iana.org/assignments/uri-schemes).  However, it does show 
several schemes (fax, modem) that were defined in an obsoleted RFC 
(2806) and not redefined in the new RFC (3966).

Thus I conclude that leaving mention of opaquelocktoken out of 
RFC2518bis would not lose its registration.  Does that change any 
opinions?

Lisa

On Oct 24, 2005, at 4:40 AM, Geoffrey M Clemm wrote:

>  > > )

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2005 18:54:43 +0200

Lisa Dusseault wrote:
> it registered because it would remain registered in RFC2518. The BCP on 
> registering schemes (ftp://ftp.rfc-editor.org/in-notes/bcp/bcp35.txt) 
> doesn't say much on obsoleting schemes in STD track documents. The 
> registration page doesn't show any info about obsoleted or historic 
> schemes (http://www.iana.org/assignments/uri-schemes). However, it does 
> show several schemes (fax, modem) that were defined in an obsoleted RFC 
> RFC2518bis would not lose its registration. Does that change any opinions?

Not yet. It may mean that I'm wrong, but it can also mean that IANA just 
forgot (did anybody tell them). Thus, those who want to take it out 
should please make sure that this doesn't have the effect of 
unregistering the scheme, for instance by asking the AD.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Oct 2005 20:40:37 -0700

> unregistering the scheme, for instance by asking the AD.

Taking it out would not remove the registration or in any way stop it from
being used. We can get AD to confirm if you would like but I'm fairly
confident on this.

(As a side note, if you put text like "it MUST NOT be used" then it would
limit it use but still not remove the registration from IANA. I don't think
anyone is suggesting adding text like this that would limit its use)

Cullen

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Oct 2005 09:06:10 +0200

> anyone is suggesting adding text like this that would limit its use)

1) I'm still not convinced. An implementer who sees a "opaquelocktoken" 
would then first go to IANA, and find out it's defined in RFC2518. The 
RFC Index will then point out that RFC2518 has been obsoleted by RFCxxxx 
(that's what we're going to do, right?). If that RFC doesn't mention the 
scheme anymore I think this will be confusing.

2) Why is the spec better in any way if the definition is removed? 
What's the advantage here?

3) To whose who think the scheme itself isn't needed anymore: this is 
simply incorrect (see 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172#c1>):

> The postfix notation of the "opaquelocktoken" scheme allows more freedom in
> generating URIs than "urn:uuid". For instance, a server that internally uses a
> simple string-typed (or numeric) lock identifiers can generate "opaquelocktoken"
> URIs by simply appending the internal identifier to a single, fixed UUID. In
> absence of that feature, it would need an additional lookup table to map
> internals IDs to UUIDs.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Oct 2005 21:13:10 +0200

Ok,

here's a procedural question.

I have made a proposal to resolve these issues, and in the conference 
call we have sort-of agreed to that plan (for instance, keep 
opaquelocktoken, but move it to an appendix).

The new draft posted by Lisa *also* does this, but it doesn't use the 
text I proposed. In particular, it still refers to outdated documents.

If the working group wants people to propose ready-for-spec text, then I 
think that text should either be used, or those you don't like it should 
at least state what was wrong with it.

For the record, I proposed:

    Example:

which is IMHO much better then the text we now got:

Appendix D.  The opaquelocktoken scheme and URIs

    The 'opaquelocktoken' URI scheme was defined in RFC2518 (and
    registered by IANA) in order to create syntactically correct and
    easy-to-generate URIs out of UUIDs, intended to be used as lock
    tokens and to be unique across all resources for all time.  This
    scheme has been obsoleted by [9], but is re-defined here for clarity.

    A server MAY generate one ore more UUIDs to use with the
    'opaquelocktoken' scheme as lock tokens.  A server MAY reuse a UUID
    with extension characters added.  If the server does this then the
    algorithm generating the extensions MUST guarantee that the same
    extension will never be used twice with the associated UUID.

In particular:

- no, opaquelocktoken has *not* been obsoleted; it still does more that 
urn:uuid does

- What is "A server MAY generate one ore more UUIDs to use with the 
'opaquelocktoken' scheme as lock tokens." supposed to mean???

- "If the server does this then the algorithm generating the extensions 
MUST guarantee that the same extension will never be used twice with the 
associated UUID." - that's by definition of the lock token uniqueness; 
I'm not sure why it's repeated here.

- "OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; ..." -- 
just refer to the normative definition in RFC4122

- "Extension = path"... -- RFC2396 is obsoleted. Really :-)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Oct 2005 21:42:57 +0200

Hi.

More changes that I think do not represent WG consensus:

1: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html#rfc.section.9.5.3.p.4>:

--
The Not production is particularly useful with the "<DAV:no-lock>" state 
token. The clause "Not <DAV:no-lock>" MUST evaluate to true. Thus, any 
"OR" statement containing the clause "Not <DAV:no-lock>" MUST also 
evaluate to true.
--

This now says MUST instead of "must". I'm not sure why RFC2119 
terminology is invoked here. URIs in the DAV: namespace by definition 
never represent a lock token, because they can only be assigned by the 
IETF or this WG. So the statement applies to *all* URIs that use the 
DAV: URI scheme, "DAV:no-lock" is just one example.

If you really feel that this needs to be stated somewhere, please don't 
make it sound as if "DAV:no-lock" is different from -- for instance -- 
"DAV:lock".

2: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest-from-07.diff.html#diff-30>:

Why was the registration for "opaquelocktoken" removed from the IANA 
considerations? Thinking of it, why was the definition for the "DAV" URI 
scheme removed as well?????

Please undo.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 28 Oct 2005 14:51:54 -0700

> 1: <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- 
> latest.html#rfc.section.9.5.3.p.4>:
>
> --
> The Not production is particularly useful with the "<DAV:no-lock>"  
> state token. The clause "Not <DAV:no-lock>" MUST evaluate to true.  
> Thus, any "OR" statement containing the clause "Not <DAV:no-lock>"  
> MUST also evaluate to true.
> --

This sounds right to me.

> terminology is invoked here. URIs in the DAV: namespace by  
> definition never represent a lock token, because they can only be  
> assigned by the IETF or this WG. So the statement applies to *all*  
> URIs that use the DAV: URI scheme, "DAV:no-lock" is just one example.
>
> If you really feel that this needs to be stated somewhere, please  
> don't make it sound as if "DAV:no-lock" is different from -- for  
> instance -- "DAV:lock".

I know there was an issue with organizations adding things to the  
DAV: namespace without using the IETF process. However, this section  
doesn't seem like the right place to address this issue.

> 2: <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- 
> latest-from-07.diff.html#diff-30>:
>
> Why was the registration for "opaquelocktoken" removed from the  
> IANA considerations? Thinking of it, why was the definition for the  
> "DAV" URI scheme removed as well?????
>

Based on Ted Hardie's email of today, it sounds like these will  
continue to be registered, whether in the IANA considerations section  
or no. That said, it would be useful to have a brief sentence to the  
effect of, "the URI registrations for opaquelocktoken and DAV URI  
schemes made in RFC 2518 should still be considered active."

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Oct 2005 15:01:08 -0700

On Oct 28, 2005, at 2:51 PM, Jim Whitehead wrote:

> URI registrations for opaquelocktoken and DAV URI schemes made in RFC 
> 2518 should still be considered active."
>

While looking at the IANA considerations section, this text caught my 
eye:

    This document defines two namespaces, the namespace of property
    names, and the namespace of WebDAV-specific XML elements used within
    property values.

I don't count two namespace, just one (DAV:).  any objections if I fix 
this sentence?

Lisa

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 28 Oct 2005 15:07:46 -0700

> If the working group wants people to propose ready-for-spec text,  
> then I think that text should either be used, or those you don't  
> like it should at least state what was wrong with it.

I don't think the editor should have to defend every minor text  
change. In particular, I think some of Lisa's additions are good (and  
she caught one error in the ABNF that you missed). However, you did  
catch a few minor errors, and one case of overspecification. Gee,  
it's almost like when multiple people collaborate on a document, the  
final result is of higher quality :-)

>      opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76-0017

I like this text, but I think Lisa does have some valuable  
contributions.

Lisa's note about LWS is necessary, since otherwise you could have  
any amount of LWS between "opaquelocktoken:" and UUID and [path].

I also generally like Lisa's new introduction sentence, since it  
provides a modicum of context for the appendix.

I'd tweak the introduction sentence slightly:

The 'opaquelocktoken' URI scheme can be used by servers to create  
syntactically correct and easy-to-generate URIs out of UUIDs,  
intended to be used as lock tokens, meeting the requirements for  
uniqueness across all resources for all time.

>    extension will never be used twice with the associated UUID.

This is implicit in the ABNF definition for opaquelocktoken, and  
doesn't need to be stated.

> UUID

For this section, I recommend:

OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
    ; UUID: see [RFC4122], Section 3.
    ; path: see [RFC3986], Section 3.3.
Note that white space (LWS) is not allowed between elements of this  
production.

> - no, opaquelocktoken has *not* been obsoleted; it still does more  
> that urn:uuid does
>

I agree.

>
> - "If the server does this then the algorithm generating the  
> extensions MUST guarantee that the same extension will never be  
> used twice with the associated UUID." - that's by definition of the  
> lock token uniqueness; I'm not sure why it's repeated here.

I agree.

>
> - "OpaqueLockToken-URI = "opaquelocktoken:" UUID  
> [Extension]  ; ..." -- just refer to the normative definition in  
> RFC4122

I agree.

> - "Extension = path"... -- RFC2396 is obsoleted. Really :-)

I agree.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 09:43:20 +0200

Jim Whitehead wrote:
>> never represent a lock token, because they can only be  assigned by 
>> the IETF or this WG. So the statement applies to *all*  URIs that use 
>> the DAV: URI scheme, "DAV:no-lock" is just one example.
>>
> I know there was an issue with organizations adding things to the  DAV: 
> namespace without using the IETF process. However, this section  doesn't 
> seem like the right place to address this issue.

OK, but hat doesn't change the argument. No URI in the DAV: scheme ever 
identifies a valid lock token, by definition. Saying "MUST" and only 
stating "DAV:no-lock" *will* cause implementors to add special code for 
this one string.

>> considerations? Thinking of it, why was the definition for the  "DAV" 
>> URI scheme removed as well?????
>>
> 

Jim, does that mean that we leave out all stuff that doesn't need 
changes? People would still be able to look it up in RFC2518, after all. 
Me confused.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 09:47:39 +0200

Lisa Dusseault wrote:
> While looking at the IANA considerations section, this text caught my eye:
> 

Yes.

This section defines namespaces (spaces of names), not XML namespaces.

in fact, we have even more spaces of names in use:

- in property values
- in precondition/postcondition names
- in resource types
- in report names (RFC3253)
- in ACEs (RFC3744)

This probably means that we shouldn't list them all, but simply try to 
make a generaln statement how WebDAV uses XML-based identifiers in 
different contexts, and that usage of identifiers in the "DAV:" 
namespace is controlled by the IETF.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Oct 2005 09:58:31 +0200

Jim Whitehead wrote:
>> If the working group wants people to propose ready-for-spec text, then 
>> I think that text should either be used, or those you don't like it 
>> should at least state what was wrong with it.
> 
> 
> I don't think the editor should have to defend every minor text change. 
> In particular, I think some of Lisa's additions are good (and she caught 
> one error in the ABNF that you missed). However, you did catch a few 

Don't think so.

> minor errors, and one case of overspecification. Gee, it's almost like 
> when multiple people collaborate on a document, the final result is of 
> higher quality :-)

Yes, it is. However, I think we would be even more productive if text 
that is proposed actually gets discussed, instead of being ignored. 
Unless we want people to stop making proposals, if it starts to look 
like a waste of time.

> I like this text, but I think Lisa does have some valuable contributions.
> 
> Lisa's note about LWS is necessary, since otherwise you could have any 
> amount of LWS between "opaquelocktoken:" and UUID and [path].

Really? I'm no ABNF expert, but that seems to be incorrect. If it's 
true, we need similar text for the TimeType production in the Timeout 
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>) header.

> syntactically correct and easy-to-generate URIs out of UUIDs, intended 
> to be used as lock tokens, meeting the requirements for uniqueness 
> across all resources for all time. 
> 
> 
> This is implicit in the ABNF definition for opaquelocktoken, and doesn't 
> need to be stated. 

That's true; but it gives the raison d'être for this URI scheme. Once 
I'm being a bit more verbose :-)

> Note that white space (LWS) is not allowed between elements of this 

See above.

 > ...

Best regards, and thanks fore reviewing both proposals.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 29 Oct 2005 08:02:13 -0700

Combining that with the text already in that section I propose:

    WebDAV uses XML-based identifiers with XML namespaces.
    The use of XML namespaces means that unique WebDAV property names
    and XML elements can be quickly defined by any WebDAV user or
    application, without requiring IANA action.
     The property names and XML elements in this specification
     are all in the "DAV:" namespace.  Creation of identifiers
     in the "DAV:" namespace is controlled by the IETF.

On Oct 29, 2005, at 12:47 AM, Julian Reschke wrote:

>>> URI registrations for opaquelocktoken and DAV URI schemes made in 
>>> RFC 2518 should still be considered active."
>>>
>> I don't count two namespace, just one (DAV:).  any objections if I 
>> fix this sentence?
>
> Yes.
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Oct 2005 12:38:52 +0100

>     in the "DAV:" namespace is controlled by the IETF.

Could you please post the complete section? I'm not sure where this text 
is supposed to be added, or whether it replaces something that is 
already there.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2005 11:29:58 -0800

> is supposed to be added, or whether it replaces something that is

Julian, in the above paragraph, if we replaced '"DAV:" namespace' with
something like '"DAV:" namespace hierarchy' would that be correct? I don't
know how to say this by do you have some text that you think would correctly
say the essence of what the above paragraph is trying to get at?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 19:24:43 +0100

> say the essence of what the above paragraph is trying to get at?

Not really. XML namespaces do not have hierarchy. I'd really see the 
full paragraph, compare with RFC2518, and the make suggestions.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Oct 2005 11:01:24 -0800

Ok, I will take this as we have consensus that the next version of the draft
will contain the text as Lisa proposed and at that point we will look at it
and decide if we need to make changes.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 21:32:40 +0100

> and decide if we need to make changes.

Ahem. I'd actually like to see the proposed text in context, and then 
comment on it.

Lisa, could you please post the full paragraph for review?

Thanks,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 31 Oct 2005 13:18:21 -0800

That was the full paragraph.  Here's the entire section of proposed 
text:

IANA Considerations

   The URI registrations for opaquelocktoken and DAV URI schemes made in
     RFC 2518 should still be considered active.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Oct 2005 22:52:10 +0100

Lisa Dusseault wrote:
> That was the full paragraph.  Here's the entire section of proposed text:

Sorry, I should have said "the full section".

>     RFC 2518 should still be considered active.

Let's see what we have in RFC2518:

--
18. IANA Considerations

This document defines two namespaces, the namespace of property names, 
and the namespace of WebDAV-specific XML elements used within property 
values. URIs are used for both names, for several reasons. Assignment of 
a URI does not require a request to a central naming authority, and 
hence allow WebDAV property names and XML elements to be quickly defined 
by any WebDAV user or application. URIs also provide a unique address 
space, ensuring that the distributed users of WebDAV will not have 
collisions among the property names and XML elements they create.

This specification defines a distinguished set of property names and XML 
elements that are understood by all WebDAV applications. The property 
names and XML elements in this specification are all derived from the 
base URI DAV: by adding a suffix to this URI, for example, 
DAV:creationdate for the "creationdate" property.

This specification also defines a URI scheme for the encoding of lock 
tokens, the opaquelocktoken URI scheme described in Section 6.4.

To ensure correct interoperation based on this specification, IANA must 
reserve the URI namespaces starting with "DAV:" and with 
"opaquelocktoken:" for use by this specification, its revisions, and 
related WebDAV specifications.
--

This certainly can be simplified, but we need to be careful here. Going 

 >    WebDAV uses XML-based identifiers with XML namespaces.

Well, it uses identifiers consisting of namespace names and local names 
(as defined per XML-Infoset).

 >    application, without requiring IANA action.

That's true, but I think the IANA section should be clear about what 
IANA needs to do with/for this spec, so I'd re-arrange the text to say 
what IANA needs to do first.

 >     RFC 2518 should still be considered active.

Sorry? That would mean that these two namespaces are still defined as 
per RFC2518. Is this really intended????

Here's a proposal for rewriting the section, based on the original text 
and ideas from the current proposal:

--

XX. IANA Considerations

XX.1. URI schemes

This specification defines two URI schemes:

1) the "opaquelocktoken" URI scheme for the encoding of lock tokens, 
defined in Appendix XYZ, and

2) the "DAV" URI scheme, which historically was used in RFC2518 to 
disambiguate WebDAV property and XML element names and which continues 
to be used for that purpose in this specification and others extending 
WebDAV. Creation of identifiers in the "DAV:" namespace is controlled by 
the IETF.

To ensure correct interoperation based on this specification, IANA must 
reserve the URI namespaces starting with "DAV:" and with 
"opaquelocktoken:" for use by this specification, its revisions, and 
related WebDAV specifications.

XX.2. Other namespaces

This document also defines multiple namespaces, including the namespace 
of property names, the namespace of WebDAV-specific XML elements used 
within property values and the namespace of pre-/postcondition names. 
Namespaced XML element names (pairs of "namespace name" and "local name" 
as per [XML-Infoset]) are used for all of them, for several reasons. Due 
to the fact that XML namespace names syntactically use URIs, assignment 
of names does not require a request to a central naming authority, and 
hence allow identifiers to be quickly defined by any WebDAV user or 
application.  Therefore, no actions on behalf of IANA are required to 
manage these namespaces.

--

Feedback appreciated,

Julian