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

[Bug 172] Whether to obsolete 'opaquelocktoken', keep it, or remove it

From: <bugzilla@soe.ucsc.edu>
Date: Wed, 30 Nov 2005 10:07:59 -0800
Message-Id: <200511301807.jAUI7xEu015992@ietf.cse.ucsc.edu>
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 GMT

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