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

RE: URI scheme uniqueness

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 4 Aug 2003 23:37:45 +0200
To: "Lisa Dusseault" <lisa@xythos.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEBOIBAA.julian.reschke@gmx.de>

this really isn't a counter-example. Just as *I* could define a "private"
URI scheme called "greenbytes", everybody else could. Unless you are *the*
naming authority for the URI schema (for which you'll need the IETF
registration), you simply can't *rely* on nobody else using the same scheme
name and scheme-dependant part.

Yes, it's unlikely. But writing protocols is about making things 100%
robust, not 99.99%.

Besides, I really don't see the point in *not* using IETF-registered URI
schemes. There are lots that are *guaranteed* to give you the required
uniqueness, one of which is the "opaquelocktoken" scheme RFC2518 defines
*for this very purpose*.

Can you give a single reason why it would be preferrable for a server
implementor *not* to use one of the available schemes?


(P.S.: I already suggested a new wording)

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Lisa Dusseault
  Sent: Monday, August 04, 2003 11:04 PM
  To: 'Julian Reschke'; w3c-dist-auth@w3.org
  Subject: RE: URI scheme uniqueness

  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.

  As a counter-example, consider if you invented the schema "greenbytes:",
in which you might find a URI like
"greenbytes:www.greenbytes.com:1234-5678-9012:3365008, where the first part
is the schema name, the second part is a domain name, the third part is a
network card ID, and the fourth part is a non-reusable sequence number.
This schema has the quality of allowing globally unique URIs to be selected
without being IETF registered.

    -----Original Message-----
    From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
On Behalf Of Julian Reschke
    Sent: Monday, August 04, 2003 1:55 PM
    To: w3c-dist-auth@w3.org
    Subject: RE: URI scheme uniqueness


    I think I've collected enough evidence (people that indeed thought that
they can achieve global uniqueness without using an IETF-registered scheme)
that this should at least be added to the RFC2518 issues list :-)


    <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

      -----Original Message-----
      From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Elias Sinderson
      Sent: Monday, August 04, 2003 7:47 PM
      To: w3c-dist-auth@w3.org
      Subject: Re: URI scheme uniqueness

<Elias Sinderson> Perhaps something along the lines of the following would
be acceptable?

"...are free to use any URI scheme so long as it meets the stated uniqueness
requirements. One way to accomplish this is to use IETF-registered URI
    <Julian Reschke> That's plain and simply wrong. The only way is to use
an URI scheme that
*both* is IETF-registered and meets the uniqueness criterium.<Elias
Sinderson> Goodness, you are correct, mea culpa - I see your point now.

<Elias Sinderson> This language seems specific enough to be unambiguous
while flexible enough to allow for other mechanisms to ensure uniqueness.
The drawback of not [...]
    <Julian Reschke> See, this kind of proves that the spec needs to be
enhanced. You and others seem to read it as a license to come up with
"private" URI schemes, which is plainly wrong and breaks the uniqueness
requirements. Therefore the text
should be clarified.<Elias Sinderson> Yes, I agree, the current text allows
for a looser interpretation than is desired - consider me in favor of
modifying the current wording.

Received on Monday, 4 August 2003 17:38:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:29 UTC