Re: URI: Name or Network Location?

On Jan 28, 2004, at 14:08, ext Hammond, Tony (ELSLON) wrote:

>
>> But as a first step (or even only step) the approach you've adopted
>> is IMO the way to go, and leaves the door open to adding functionality
>> in the future.
>
> We adhere to the "less is more" school for reasons of scalability,
> discoverability, etc., as previously argued.

Er. Well, then just use UUIDs. After all, if less is more...

> There really is more to URI as
> a naming architecture than HTTP alone. ;)

Never said there wasn't. But excluding the use of web protocols
to obtain authoritative information about resources substantially
limits the utility of those URIs.

>
> Note also that we are registering namespaces under INFO - not minting
> identifiers. It is the /users/ of INFO URIs that get to mint the
> identifiers. We do not control the identifiers so cannot - nor want to 
> -
> provide any resolution system.

I understand that. An earlier suggestion made some time ago when
first commenting on the info: URI scheme was to use DNS to delegate
all resolution responsibility via the use of subdomains. E.g.

1. Define a root domain (which you already have: info-uri.info).

2. For each registered namespace, designate a subdomain. E.g.

    pii.info-uri.info

    thus, resulting in URIs such as

    http://pii.info-uri.info/S0888-7543(02)96852-7

3. Owners of a given subdomain can have full freedom
    to provide resolution of their URIs, or can opt for
    no resolution whatsoever of their URIs. I.e.

    (a) for those that choose not to provide for any resolution,
        the subdomain simply maps to the root domain server, and any
        requests get the standard, user-friendly boilerplate
        response provided by the root INFO server, telling them all
        about the INFO org, and why they didn't GET anything useful
        by clicking on that URI, etc.

        E.g.  pii.info-uri.info -> www.info-uri.info -> ###.###.###.###

    (b) for those that choose to provide for resolution, or who
        want their own personal boilerplate response, the sub
        domain maps to whatever server they specify and they have
        full responsibility (and full *freedom*) to resolve
        their URIs as they see fit.

    In any case, registrants are only allowed to mint URIs grounded
    in their own particular subdomain, and they can structure and
    manage them however they like, conformant to the syntactic
    constraints imposed on http: URIs.

Thus, those who wan't no more functionality than simple naming
have it just as easy as for info: URIs. They register with the
INFO org, get a namespace prefix (http://XXX.info-uri.info/)
and mint URIs to their heart's content -- knowing that if anyone
ever tries to resolve those URIs, they'll get a nice friendly
default response from the INFO org's main server.

But those who *do* want to make authoritative information about
the resources named available to web clients can easily do so,
by simply setting up a web server and the DNS accordingly. And
if those in the first group, who at first don't care about
resolution, later decide "Hey, that would probably be useful",
then they can do so *SIMPLY* by setting up the server and changing
the DNS -- with *NO* impact on usage to date.

I am convinced that if you considered the http: URI approach
fairly, you'd find that (a) it demands no more effort/overhead
than info: URIs, (b) offers the potential for significantly
greater utility, (c) provides for delegation of rights and
responsibilities of registrants very effectively. In short,
you could serve INFO registrants far better using http: URIs
than info: URIs.

For the sake of those who will encounter and/or use URIs
managed within the context of the INFO organization, I strongly
encourage you to give the http: URI approach very serious
consideration. I know it's hard to change horses mid-stream,
but...

Regards,

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 29 January 2004 05:36:17 UTC