RE: URI scheme uniqueness

I agree with Julian.  I have seen no reason to weaken the current 
requirement that lock tokens be globablly unique.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 08/11/2003 04:14:07 PM:

> 
> > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > Sent: Monday, August 11, 2003 10:06 PM
> > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org
> > Subject: RE: URI scheme uniqueness
> >
> > ...
> >
> > > If you are an implementor considering using a non-IETF registered 
URI
> > > scheme _for_any_purpose_,
> > > don't lose sight of what using a registered URI scheme gives you.
> > > Non-registered
> > > schemes risk overlap and risk misunderstandings of syntax
> > > developing over time.
> >
> > I agree with this so the next version of RFC2518bis will recommend
> > using a registered scheme unless I start hearing more disagreement.
> 
> Sounds good so far.
> 
> > > I suspect that this presumes something about the way clients
> > > should behave; to wit, if they get a lock token DAV:1234
> > > issued by server dav.example.com, they will not get whacked
> > > out when they get a lock token DAV:1234 issued by server
> > > dav.example.net (obviously, for some other resource).  I
> > > believe that this would be good engineering, obviously, but I
> > > think maintaining a stricter requirement is useful.
> >
> > I think that although we have the uniqueness requirement already
> > (it can't be made stricter very easily) clients simply can't assume
> > that lock tokens really are globally unique.
> 
> Wait a minute. The spec says that they MUST be globally unique. It even
> defines a URI scheme that is supposed to guarantee that uniqueness. And 
now
> you want to tell clients that they can't rely on that???
> 
> > Should we add some client advice to RFC2518bis, saying that in
> > practice clients cannot assume that lock tokens will be unique
> > across servers and should not be used as unique lookups in client
> > code? It provides little advantage to the client to assume
> > uniqueness, and it could be an easy source of bugs.  This falls
> > under the IETF principle of being generous in what you accept
> > (non-unique tokens) but strict in what you generate (unique only).
> 
> Absolutely no. Either clients can rely on uniquess, or they can't. 
RFC2518
> guarantees this, and I don't see an interoperability problem caused by 
this.
> Removing the guarantee potentially breaks existing clients with no 
visible
> benefit.

Received on Monday, 11 August 2003 16:50:10 UTC