- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 27 Oct 2005 09:06:10 +0200
- To: Cullen Jennings <fluffy@cisco.com>
- CC: Lisa Dusseault <lisa@osafoundation.org>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>
Cullen Jennings wrote: > Taking it out would not remove the registration or in any way stop it from > being used. We can get AD to confirm if you would like but I'm fairly > confident on this. > > (As a side note, if you put text like "it MUST NOT be used" then it would > limit it use but still not remove the registration from IANA. I don't think > anyone is suggesting adding text like this that would limit its use) > > Cullen 1) I'm still not convinced. An implementer who sees a "opaquelocktoken" would then first go to IANA, and find out it's defined in RFC2518. The RFC Index will then point out that RFC2518 has been obsoleted by RFCxxxx (that's what we're going to do, right?). If that RFC doesn't mention the scheme anymore I think this will be confusing. 2) Why is the spec better in any way if the definition is removed? What's the advantage here? 3) To whose who think the scheme itself isn't needed anymore: this is simply incorrect (see <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=172#c1>): > The postfix notation of the "opaquelocktoken" scheme allows more freedom in > generating URIs than "urn:uuid". For instance, a server that internally uses a > simple string-typed (or numeric) lock identifiers can generate "opaquelocktoken" > URIs by simply appending the internal identifier to a single, fixed UUID. In > absence of that feature, it would need an additional lookup table to map > internals IDs to UUIDs. Best regards, Julian
Received on Thursday, 27 October 2005 07:06:35 UTC