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

[Bug 186] New: opaquelocktoken appendix

From: <bugzilla@soe.ucsc.edu>
Date: Sun, 20 Nov 2005 12:50:29 -0800
Message-Id: <200511202050.jAKKoT4C003459@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org


           Summary: opaquelocktoken appendix
           Product: WebDAV-RFC2518-bis
           Version: -08
          Platform: Other
               URL: http://http://greenbytes.de/tech/webdav/draft-ietf-
        OS/Version: other
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Other
        AssignedTo: joe-bugzilla@cursive.net
        ReportedBy: julian.reschke@greenbytes.de
         QAContact: w3c-dist-auth@w3.org


"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

No, it has not been obsoleted.

"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

Correct, but the first sentence doesn't say anything meaninful.

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

Please make this a figure, and make sure that ABNF comments are properly formatted.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Sunday, 20 November 2005 20:50:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC