RE: URI scheme uniqueness

Julian is correct here.  I support adding the clarification to 2518bis
that he suggests, i.e. the lock token schema MUST be an IETF-registered 
schema.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 08/05/2003 03:09:37 AM:

> 
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Tuesday, August 05, 2003 12:57 AM
> > To: hardie@qualcomm.com; 'Julian Reschke'; w3c-dist-auth@w3.org
> > Subject: RE: URI scheme uniqueness
> >
> > ...
> >
> > 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
> 
> I absolutely disagree with this statement. URIs were chosen as this was
> simply the best way to come up with a robust identifier syntax.
> 
> > could just as easily have required lock tokens to be opaque strings
> > containing only alphanumeric characters, because clients get no 
semantics
> 
> ...in which case you would have reached the uniqueness criteria exactly
> how...?
> 
> > 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.
> 
> Not true. The spec says that the lock token is a URI. A user agent is
> absolutely allowed to run a lock token through a URI parser. In 
particular,
> this URI parser may actually do scheme-dependant parsing. For instance, 
it
> would be perfectly legal for a client to reject a lock token on the 
basis
> that it doesn't comply to the syntactical rules for the scheme used, for
> instance:
> 
> "opaquelocktoken:foobar" or "http:foobar"
> 
> > (the only interoperability issue is what characters can appear, which
> seems
> > uncontroversial since we've defined it as a URI).
> 
> Well, uniqueness as well. As RFC2518 guarantess uniqueess...:
> 
> "Lock token URIs MUST be unique across all resources for all time. This
> uniqueness constraint allows lock tokens to be submitted across 
resources
> and servers without fear of confusion."
> 
> a client may store all lock tokens in a map, independantly of where they
> came from. In particular, the spec allows it to *keep* these tokens and 
to
> raise an error if a token is issued a second time (this may not be very
> useful, but the issue is that the spec *allows* that behaviour).
> 
> > The uniqueness issue does matter to the server implementor to make 
their
> > implementation work.  But in practice it doesn't have to be 
universally
> 
> ...and to the client.
> 
> > 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
> 
> No, no, no. The spec says that clients can rely on lock tokens to be 
unique.
> If a client talks to two different servers and they both use the lock 
token
> "DAV:1234", this can clearly be a problem. *Please* do not make 
assumptions
> about what clients do or don't. From what you're saying right now it 
seems
> that you're trying to reverse history by removing a required feature 
from
> the protocol, and I really really would like to understand *why* you're
> doing that.
> 
> > 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
> 
> Are you saying that breaking a MUST-level requirement of the protocol is
> harmless?
> 
> > 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.
> 
> Yes. But the spec clearly says that both servers and clients can rely on
> them being URIs, therefore are allowed to run them through a URI parser 
and
> reject them if they aren't valid URIs (for instance, rejecting string 
that
> contain non-ASCII characters).
> 
> > 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
> 
> ...my point being that you can't have *guaranteed* uniqueness unless you
> register the scheme.
> 
> > 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
> 
> It does help interop issues if they are a result of
> 
> - people using the same non-registered URI scheme with conflicting 
tokens,
> and/or
> - clients rejecting lock tokens because they don't parse as valid URI.
> 
> > 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.
> 
> Yes. Please. The discussion has shown that it doesn't seem to be 
obvious,
> because making up ad-hoc URI schemes seems to be almost the norm, not 
the
> exception.
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>