Re: BIND spec: Potential URI comparison issue

At 1:38 AM +0200 9/21/04, Julian Reschke wrote:
>Ted Hardie wrote:
>>...
>>opaquelocktoken is defined in 2518, at least if I am reading the URI scheme
>>registrations at IANA correctly.   Are you planning to update 2518?  If so,
>
>No.
>
>>do you plan to change the generation reference from the UUID reference
>>(ISO 11578) to something else?  As it stands now, I would expect
>>implementations to treat to tokens as equivalent if the UUID would
>>be equivalent.
>
>Well, the BIND spec allows *any* URI scheme. We can't expect 
>recipients of DAV:resource-id properties to be aware of special 
>comparison rules for specific URI schemes. So the simplest way to 
>achieve interoperability is to specify one specific comparison that 
>can be implemented by everybody without any knowledge of the various 
>levels of URI equivalence (see RFC2396bis).

>Note that this is the same problem as in XML Namespaces and in Atom, 
>thus the same solution.

I'm not sure I see why this a feature.  Having a single, 
well-specified mechanism
that allows you to create identifiers that have a high probability of 
being unique
across space and time seems like goodness for this use.  Why would 
you want to allow
*any* URI scheme here?  mailto: julian.reschke+mylock@gmx.de? 
gopher://gopher.umd.edu/my_lock?

For both the xml namespace 1.0 and 1.1 recommendations, going down that
path has meant dealing with the difference between two references being
identical and "resolving to the same thing".  The spin-cycle on that argument
could wring out the garments of every parliament ever sat.

Again, what's the feature here?
			regards,
					Ted Hardie

Received on Tuesday, 21 September 2004 00:15:06 UTC