RE: URI scheme uniqueness

> 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.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 11 August 2003 16:14:41 UTC