- From: <bugzilla@soe.ucsc.edu>
- Date: Sun, 20 Nov 2005 12:50:29 -0800
- To: w3c-dist-auth@w3.org
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: joe-bugzilla@cursive.net
ReportedBy: julian.reschke@greenbytes.de
QAContact: w3c-dist-auth@w3.org
<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.
Received on Sunday, 20 November 2005 20:50:32 UTC