Re: BIND spec: Potential URI comparison issue

The reason to allow any URI scheme is to allow a reasonable implementation
on existing repositories that already have a UUID scheme built-in
to that repository (and are not amenable to extension with a different
UUID scheme just to satisfy the WebDAV BIND specification).

Cheers,
Geoff

Ted wrote on 09/20/2004 08:14:25 PM:

> 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