Date: Fri, 15 Oct 1993 13:29:49 -0700 (PDT)
From: "Rob Raisch, The Internet Company" <raisch@internet.com>
Subject: Re: The URN: wrapper and URLs...
To: Michael Mealling <ccoprmm@oit.gatech.edu>
In-Reply-To: <199310152028.AA19707@oit.oit.gatech.edu>
Message-Id: <Pine.3.03.9310151349.C12629-c100000@hmmm.internet.com>
On Fri, 15 Oct 1993, Michael Mealling wrote:
> Personally the biggest gain I think we stand to get from URL: is that
> we can come up with new schemes without having to notify everyone's
> software that this is a URL and not a URN. A good example is this:
But, Michael, we need to inform everyone's software how to retrieve the
URL from the URN, no?
Both the URL and the URN are fundamentally mechanisms to retrieve
resources from the network. In the first case, the resource is data, and
in the second, the resource is a list of URLs.
What's the difference between
ftp:some opaque string which is interpreted by the software
(In this case, I as programmer know that I need to
use 'ftp' to get the property, so I send it to the
FTP RETRIEVAL ENGINE for further processing.)
and
URL:some opaque string which is interpreted by the software
(In this case, I as programmer know that I need to
use 'URL' to get the property, so I send it to the
URL RETRIEVAL ENGINE for further processing.)
and
URN:some opaque string which is interpreted by the software
(In this case, I as programmer know that I need to
use 'URN' to get the property, so I send it to the
URN RETRIEVAL ENGINE for further processing.)
????
Frankly, I don't see the difference. You are adding URL: to the
beginning, which adds an unnecessary extra step to the process of
retrieving the property.
And in fact, you are always adding, at least, one extra step to all
processing since you need to strip the unnecessary descriptor. And
in the usual case, consider:
URN:mechanism://namespace/ref becomes
mechanism://namespace/ref becomes
URL:mechanism://location/resource becomes
mechanism://location/resource becomes
{data}
or
mechanism://namespace/reference becomes
mechanism://location/resource becomes
{data}
In the first example, we know it's a URN because it tells us so.
In the second example, we know it's a URN because that information is
already implicit in its retrieval mechanism.
Or, which is the more efficient and generalized design?
----------------------------------------------
Pseudo-code (case 1):
if( selector[ up to the ':'] == "URN") {
getUrlFromUrn;
goto do_Url;
}
else if( selector[ up to the ':'] == "URL") {
do_Url:
getDocumentFromUrl;
}
else croak;
-------------------------------------------
Pseudo-code (case 2):
do_it_again:
switch( selector[ up to the ':']) {
case 'ftp':
use ftp to retrieve the product, and exit.
case 'registrar': /** a URN to URL mapping service **/
use registrar to retrieve the best url selector
to use and goto do_it_again.
default:
croak;
}
-------------------------------------------
</rr> (Trying desperately to see the value....)