- From: <bugzilla@soe.ucsc.edu>
- Date: Wed, 30 Nov 2005 10:07:59 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172
ejw@cs.ucsc.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|julian.reschke@greenbytes.de|lisa@osafoundation.org
------- Additional Comments From ejw@cs.ucsc.edu 2005-11-30 10:07 -------
Teleconference consensus is to use the following text for Appendix C:
C. The opaquelocktoken scheme and URIs
The 'opaquelocktoken' URI scheme was defined in I RFC2518[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.
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.
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
; UUID is defined in Section 3 of [RFC4122]. Note that linear white
; space (LWS) is not allowed between elements of this production.
Extension = path ; path is defined in Section 3.3 of [RFC3986]
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Wednesday, 30 November 2005 18:08:04 UTC