Subject: [Bug 186] New: opaquelocktoken appendix

From: [email-masked]
Date: Sun, 20 Nov 2005 12:50:29 -0800

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

           Summary: opaquelocktoken appendix
           Product: WebDAV-RFC2518-bis
           Version: -08
          Platform: Other
               URL: http://http://greenbytes.de/tech/webdav/draft-ietf-
                    webdav-rfc2518bis-08.html#rfc.section.C
        OS/Version: other
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Other
        AssignedTo: [email-masked]
        ReportedBy: [email-masked]
         QAContact: [email-masked]

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-08.html#rfc.section.C>

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

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

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.