RE: URI scheme uniqueness

> 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

Received on Tuesday, 5 August 2003 03:10:13 UTC