RE: URI scheme uniqueness

> As you say above, the two are independent; you can have IETF 
> schemes which are not unique and non-IETF schemes which are.
Great, I think we all agree on that...
 

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

> A presumption (possibly unwarranted) on my part was that 
> anyone choosing an unregistered URI scheme for lock tokens is 
> doing so to reuse scheme they are already using for some 
> other purpose.  Hence the motivation to make the general plug 
> above to register schemes whenever they can.

I hadn't made that presumption but it's a fair consideration.  

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

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

 Lisa

Received on Monday, 11 August 2003 16:05:30 UTC