RE: URI scheme uniqueness

> -----Original Message-----
> From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] 
> Sent: Monday, August 04, 2003 2:23 PM
> To: Lisa Dusseault; 'Julian Reschke'; w3c-dist-auth@w3.org
> Subject: RE: URI scheme uniqueness
> 
> 
> At 2:04 PM -0700 8/4/03, Lisa Dusseault wrote:
> >I don't object to this being an issue, and I'm happy to see
> >suggestions for new wording.  However, I think we're missing 
> >something here.  You've already pointed out that using an 
> >IETF-registered schema doesn't guarantee uniqueness which is true, 
> >but the wording below suggests that you can't have uniqueness 
> >without having IETF registration. Rather, IETF registration and 
> >uniqueness are completely independent qualities.
> 
> I agree that they are independent, but we shouldn't lose 
> sight of the idea that registration tells you whether a 
> scheme will or will not give you 
> uniqueness.  The
> double issues for non-registered schemes is that you can get 
> overlap (the same human-friendly scheme names occur to lots 
> of people) and those using the scheme may have different 
> ideas about the syntax as things evolve. Both can really 
> damage interoperability.  I encourage folks to 
> register schemes,
> and we are now working again on the procedures for non-IETF 
> trees, which would allow people to do a lightweight registration.

In this case interoperability shouldn't be affected. I haven't seen a case
where problems have been caused in real life, and I haven't heard a scenario
for problems caused (although a poorly chosen schema could compound poor
implementation practice).  

The section under discussion describes how lock tokens are generated.
Servers generate lock tokens as URIs for formatting reasons -- so that we
know what characters can appear and how they can be marshalled in XML.  We
could just as easily have required lock tokens to be opaque strings
containing only alphanumeric characters, because clients get no semantics
out of these tokens.  But, because these are URIs there must be a URI
scheme.  That scheme may or may not be IETF-registered.  It may be the http:
scheme, the DAV: scheme, the opaquelocktoken: scheme, or something else
entirely. 

It doesn't really matter for interoperability whether the lock token is
really unique, or whether it uses an IETF-registered scheme.  Since the lock
token is never parsed by foreign software (software other than the software
which generated the token) it is not an interoperability issue, period.
(the only interoperability issue is what characters can appear, which seems
uncontroversial since we've defined it as a URI).

The uniqueness issue does matter to the server implementor to make their
implementation work.  But in practice it doesn't have to be universally
unique in order to work, it just has to be unique to that server.  So if my
server issues a locktoken 'DAV:1234', it doesn't matter to either successful
interoperability or to the successful functioning of my server if another
server issues the same lock token. My server should probably not reuse the
locktoken "DAV:1234" for another lock in the future although after
sufficient time passes it would be a harmless mistake.  That said, it does
little harm for the WebDAV spec to be more strict in its requirements, which
it is -- it says "Lock token URIs MUST be unique across all resources for
all time. ...across resources and servers...".  

The syntax issue (which you mention as a reason to register schemas) is
completely irrelevant as lock tokens are unparsable by any other agent -
they are opaque strings in the format of URIs.  The issuing server may even
treat them as unparsable lookup strings.

The issue under discussion is whether we should additionally require the
scheme in the lock token to be registered.  Currently the spec says
"resources are free to return any URI scheme so long as it meets the
uniqueness requirements".  An additional requirement for registration
doesn't help interoperability problems in this particular case as I could
register a schema that did not meet the uniqueness requirements (or I could
use an existing schema like http: in a way that does not meet the uniqueness
requirements).  If it is an IETF policy to require registration regardless
of the interoperability considerations then it's trivial to add that
requirement.

Lisa

Received on Monday, 4 August 2003 18:56:37 UTC