W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: URI scheme uniqueness

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 5 Aug 2003 11:17:33 -0400
To: w3c-dist-auth@w3.org
Message-ID: <OF694794BE.EE6485D7-ON85256D79.00526CB9-85256D79.00540165@us.ibm.com>
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 


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 
> > 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 
> > implementation practice).
> >
> > The section under discussion describes how lock tokens are generated.
> > Servers generate lock tokens as URIs for formatting reasons -- so that 
> > know what characters can appear and how they can be marshalled in XML. 
> 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 
> ...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 
> http:
> > scheme, the DAV: scheme, the opaquelocktoken: scheme, or something 
> > entirely.
> >
> > It doesn't really matter for interoperability whether the lock token 
> > really unique, or whether it uses an IETF-registered scheme.  Since 
> lock
> > token is never parsed by foreign software (software other than  the
> software
> > which generated the token) it is not an interoperability issue, 
> 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 
> this URI parser may actually do scheme-dependant parsing. For instance, 
> would be perfectly legal for a client to reject a lock token on the 
> 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 
> 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 
> 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 
> > implementation work.  But in practice it doesn't have to be 
> ...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 
> If a client talks to two different servers and they both use the lock 
> "DAV:1234", this can clearly be a problem. *Please* do not make 
> about what clients do or don't. From what you're saying right now it 
> that you're trying to reverse history by removing a required feature 
> 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 
> > server issues the same lock token. My server should probably not reuse 
> > locktoken "DAV:1234" for another lock in the future although after
> > sufficient time passes it would be a harmless mistake.  That said, it 
> 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 
> > all time. ...across resources and servers...".
> >
> > The syntax issue (which you mention as a reason to register schemas) 
> > 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 
> reject them if they aren't valid URIs (for instance, rejecting string 
> contain non-ASCII characters).
> > The issue under discussion is whether we should additionally require 
> > 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 
> > 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 
> 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 
> > 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 
> because making up ad-hoc URI schemes seems to be almost the norm, not 
> exception.
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 5 August 2003 11:18:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC