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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 23 Oct 2005 14:22:44 +0200
Message-ID: <435B8094.1040903@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Lisa Dusseault <lisa@osafoundation.org>, WebDav WG <w3c-dist-auth@w3.org>
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:

    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]

  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="ejw@example.com", 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="ejw@example.com", 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="ejw@example.com", 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="ejw@example.com", 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="ejw@example.com", 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="ejw@example.com", 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>
 
Received on Sunday, 23 October 2005 12:23:17 GMT

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