Date: Sun, 17 Oct 1993 11:45:06 -0400 (EDT)
From: Kevin Gamiel <kgamiel@vinca.cnidr.org>
Subject: Re: The URN: wrapper and URLs...
To: Kevin Altis <kevin@scic.intel.com>
In-Reply-To: <9310170635.AA13263@rs042.scic.intel.com>
Message-Id: <Pine.3.05.9310171105.A10689-c100000@vinca.cnidr.org>
> I don't see how prefixing with URL: makes automatic marking particularly
> easier. Any application scanning through text looking for URLs or URNs is
> going to have to make a lot of assumptions about where the URL actually
> starts and ends without a wrapper like < and >. In your example
We hope to have these wrappers...
> "URL:http://jhm.ccs.neu.edu:7043/" the scanning algorithm still needs to
> parse the text through the "://" before it knows it has the beginning of an
> URL, otherwise some text fragment like "valid forms are URL:http, URL:ftp,
> etc." might foul up the parser; I'm sure we can come up with nastier
> examples. It seems just as reasonable that the parser should know about
> specific URL forms "http:, gopher:, ftp:..." rather than just "URL:". The
I don't find this reasonable at all. I want to send a robot off to fetch
every URL it can find in every text file on the net, regardless of the
protocol field indicated by "http:, gopher:, ...", and hand the list off
to a server whose job it is to fetch all those items and see if they have
what I'm looking for. I shouldn't have to know _every_ protocol supported.
Ok, bad example, but you get the point.
I can't believe the traffic that prefixes are causing. One of the
strongest arguments for "consensus" on URLs in Amsterdam was the fact that
URLs needed to be easily human distinguishable "...from the back of an
envelope". The very people who argued this have abandoned the argument a
level higher.
Besides, its very simple. If there were no working URL code, would anyone
object to having the URL: prefix? Heck no.
(insert cheesy, practical example of having to rewrite code here...)
WAIS works fine as is, but because of evolving standards (Z39.50 v2), we
(WAIS, Inc and CNIDR) are having to rewrite from the ground up. If you
think having to strip the first 4 bytes from a URL to become compliant is bad,
try having to add 3 full BER encoded APDUs, not to mention attribute
sets, element sets, and other assorted horrors!
Kevin
----------------------------------------------------------------------
Kevin Gamiel - KEVIN.GAMIEL@CNIDR.ORG
MCNC CNIDR - 919-248-1911
Clearinghouse for Networked Information Discovery and Retrieval
Proud charter member of
Tar Heel Information Services - "Nothing but net!"
-----------------------------------------------------------------------