W3C home > Mailing lists > Public > uri@w3.org > February 2005

Uniqueness and speculation

From: by way of Martin Duerst <david.durand@ingenta.com>
Date: Wed, 16 Feb 2005 07:24:44 +0900
Message-Id: <6.0.0.20.2.20050216072429.08ba05d0@localhost>
To: uri@w3.org




 From a more or less outside perspective, I see Stuart's comments as pretty 
on-target. Failure of uniqueness is a real problem that we've already seen. 
Land-grabbing is not a common behavior, and might best be tackled by 
reserving discretion to the IANA _just in case_ it does become a problem. I 
argue below that there are good reasons that it's not likely to become a 
problem, as support to Michael's contention that it might not be a problem.

Name speculation has been a problem only for one class of name (domain 
name) which is really a primary interface to end-users on the internet, in 
the form of an identifier that labels an individual or organization's 
public presence for internet services (including publication on the web, 
email, etc). Also, once you obtain such an identifier, there is no barrier 
to adoption for it -- as fast as you can put up a server, a new domain name 
is live.

While many other technical identifiers are in use, and must be registered 
(for instance mail headers), none of those is an identifier for an 
organization. Product branding isn't really such an issue for protocol 
elements. In fact, there's never been speculation in these identifiers, and 
there are several reasons to think that the lack of speculation in mail 
headers is a pretty good indication of the prospects for URI token speculation.

Can I imagine a microsoft: or apple: URI token created as a  way to gateway 
to proprietary servers? yes. But creating such a token isn't attractive:

1. It is no good unless it's widely implemented. Reserving a URI token has 
no effect on the world, whereas registration of a domain name enlists a 
public network of millions of servers to make the new name public.

2. Most end users don't even notice the URI token, and so user behavior 
doesn't make it an obvious target.

I think several of the policy ideas Stu has presented could work to 
safeguard against the unlikely prospect of a land grab. I do think that it 
would be easier to pick a policy if we could agree that uniqueness is the 
point of a registry, and move onto the separate question of how to make a 
registry work well.

Here are two other policy ideas that might help (apologies if these repeat, 
I'm trying to stay up to date, but I may have missed/forgotten something):

1. Provisional registrations must be unique and are subject to 
administrative adjudication by IANA which will normally execute 
registration automatically. Basically, we IANA reserves the right to review 
any registration, but normal procedure will be to accept registrations, 
unless IANA determines that a technical review is required. Basically we 
adopt a procedure for optional review that gives leeway to intervene at the 
moment that there is a need to control a problem in the registry.

In short say: "IANA doesn't intend to do reviews unless there's a problem. 
We get to decide what's a problem if anything, and then will review and act 
accordingly."

2. All provisional registrations must be renewed every 6 months. Failure to 
renew within 12 months will cause the token to be available to competing 
registrations. Any individual may register no more than 1 URI token without 
special review, no organization may register more than 5 without special 
review, all such reviews at IANA convenience. Actually, since these tokens 
are about interoperability, there's an argument to be made that any token 
worth registering should have several organizations capable of registering 
it, and thus that these limits could be absolute. On the other hand groups 
like the W3C may have legitimate cause to register many URI tokens.

   -- David

David G. Durand
Director, Electronic Publishing Services
Ingenta Inc.
111R Chestnut St.
Providence, RI  02903 USA

T: +1 401-331-2014 x111
T: +1 401-935-5317 Mobile
E: david.durand@ingenta.com
Received on Tuesday, 15 February 2005 22:24:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:09 UTC