- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 06 Feb 2005 16:33:54 +0100
- To: bugzilla@soe.ucsc.edu
- CC: w3c-dist-auth@w3.org
OK,
for "draft-reschke-webdav-locking", I'm tracking this as
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.D_delegate_UUID_definition>
and rewrote the section like this:
Appendix D. 'opaquelocktoken' URI Scheme
The opaquelocktoken URI scheme is designed to be unique across all
resources for all time. Due to this uniqueness quality, a client may
submit an opaque lock token in an If header on a resource other than
the one that returned it.
All resources MUST recognize the opaquelocktoken scheme and, at
minimum, recognize that the lock token does not refer to an
outstanding lock on the resource.
In order to guarantee uniqueness across all resources for all time
the opaquelocktoken requires the use of the Universal Unique
Identifier (UUID) mechanism, as described in Section 4 of
[draft-mealling-uuid-urn].
OpaqueLockToken-URI = "opaquelocktoken:" UUID [path]
; UUID: see [draft-mealling-uuid-urn], Section 3.
; path: see [RFC3986], Section 3.3.
This change gets rid of 2 pages of spec text that this WG can't do as
good as the URN UUID authors anyway; and also replaces an ISO spec
reference with a reference to an IETF standards track document.
I propose the same resolution in RFC2518bis. Feedback appreciated,
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 6 February 2005 15:34:53 UTC