W3C home > Mailing lists > Public > uri@w3.org > June 2001

The possibilities for identifier resolution

From: Tim Kindberg <timothy@hpl.hp.com>
Date: Sat, 16 Jun 2001 12:02:56 -0700
Message-Id: <>
To: "Roy T. Fielding" <fielding@eBuilt.com>, Dan Connolly <connolly@w3.org>
Cc: uri@w3.org
At 05:56 PM 6/15/01 -0700, Roy T. Fielding wrote:
>So, regarding the issue at hand, there are only three possibilities:
>    1) the mechanism of contacting the naming authority is defined by
>       the URL scheme, as is the case for http (HTTP via TCP) and https;

You speak of contacting a naming authority when what is needed is to 
contact a binding authority (one that knows bindings from the identifier to 
(addresses of) resources) -- and that's not necessarily the same, even 
though it is the same in http. Naming authorities mint and (usually) bind 
names; others can bind those names, too.

>    2) the mechanism is encoded as part of the authority component, just
>       as the TCP port number is defined in many schemes; or,

Do you have an example of such a mechanism in mind? I don't see how it 
could encode more than a name or address where such a mechanism is 
implemented and a protocol for talking to it -- in which case we're back at 

>   3) the protocol elements that use URI are modified to allow references
>       to be composed of multiple URI, as in
>         ssl://example.com(http://example.com/foo)

-- where, incidentally, the first URI needs to be of type (1) -- otherwise 
we're moving the problem rather than solving it.

The bottom line seems to be that impure names (containing the address of 
their resolver) are always going to be convenient in several respects but 
equally will always have the problems that we know well. Pure names (not 
containing or strictly implying the address of a resolver) are always, by 
definition, going to be matter for domain-specific applications and 
services to resolve. 'The naming system' can at best define standard 
protocols for minting names and for presenting them for resolution by those 
apps and services (implicit in your example 3). It doesn't seem to have 
another role to play in an open world like the Internet.


Tim Kindberg

internet & mobile systems lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126

voice +1 650 857 5609
fax +1 650 857 2358
Received on Saturday, 16 June 2001 14:44:27 UTC

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