Message-Id: <9310172110.AA04388@mocha.bunyip.com>
To: Kevin Altis <kevin@scic.intel.com>
Subject: Re: The URN: wrapper and URLs...
In-Reply-To: Your message of Sun, 17 Oct 1993 10:48:31 -0800.
<9310171752.AA12558@rs042.scic.intel.com>
Date: Sun, 17 Oct 1993 17:10:21 -0400
From: John Curran <jcurran@nic.near.net>
--------
] From: Kevin Altis <kevin@scic.intel.com>
] Subject: Re: The URN: wrapper and URLs...
] Date: Sun, 17 Oct 1993 10:48:31 -0800
]
] At 11:45 AM 10/17/93 -0400, Kevin Gamiel wrote:
]
] Your server will then have to know about _every_ protocol supported in
] order to fetch the items for the robot and again the URL: prefix doesn't
] help. You don't have to know every protocol, but the code doing the work
] does or has to be able to pass it on to some other code that does. Right
] now on the Web, the client software actually knows about more protocols
] than any of the common servers.
] ...
] Our current URLs are "easily human distinguishable" or as easy as it gets
] without brackets. I'm arguing against the URL: prefix because I don't think
] it buys us anything except possibly some sense of balance with UR* labels
] to come, but that's what we're debating. I don't think putting URL: in
] front of existing URLs makes them any easier to spot. Right now, it appears
] the extra URL: prefix is just that, an EXTRA PREFIX.
It's quite simple:
If the world is URL's and URN's, then the prefix is _useless_.
(distingish between URNs and URLs on presence of "urn")
If the world is URL's and URN's and some future URx's to be defined,
then I either have to know the list of valid URx's or the list of URL's.
I don't have a list of URL's in my client, those are passed off to data
server for stream retrieval.
There's definitely a code requirement in the client (in my case) for
URN usage, since they must be passed along with user-specified criteria
to the URN-resolution-service. (I know some folks working on such...)
My original intent was to pass any other "higher-level" URx's off to
these services as well, with the hope that they'd handle it and give
me back the same "stuff" as they would for a URN.
Now, I really can't see anyway of determining whether "ur?:" is a new
access scheme for data, and should go to the URL-stream service or whether
it's some nice fuzzy meta-information such as a uniform_resource_citation.
Is someone advocating that no schemes will ever be defined beginning with
"ur*"?
/John