emv@msen.com (Ed Vielmetti) (06/17/91)
do you ever get the feeling that all this NREN stuff is going to
build us a network that's extraordinarily fast but impossible to use?
mitch kapor, in his "building the open road: policies for the national
public network" [*], compares the existing mess in the current state of
the art at cataloging and describing the services available on the
net today as "like a giant library with no card catalog".
who is going to provide the moral equivalent of the rand-mcnally road
atlas, the texaco road maps, the aaa trip-tiks? what we have now is
much more like the old Lincoln Highway, with painted markings on trees
and oral tradition that helps you get through the rough spots on the
road.
efforts by existing commercial internet providers have been mediocre
at best. none appear to be much interested in mapping out the network
beyond the immediate needs of their customers. if you consider that
one of the roles of a commercial internet provider is to provide
access to software archives, and then you take a look at the state of
the software archives on uunet.uu.net and uu.psi.com, you see enormous
duplication, strange and hard to understand organizations of files, no
aids in finding materials beyond a cryptic "ls-lR" file, and dozens if
not hundreds of files which are stale and out of date compared with
the One True Version maintained by the author of the documents. [&]
Visiting these places is like reading magazines at a dentist's office,
you know that what you're reading was new once a few weeks or months
ago.
efforts by nsf-funded network information centers have been similarly
muddled and half-useful. if you read the Merit proposal to NSFnet
closely, you saw plans for GRASP (Grand interface to SPIRES) which was
going to be the ideal delivery mechanism for information about the
NSFnet to users of the net. Promises promises. What you do have from
nis.nsf.net is a stale collection of out of date maps [%], a bunch of
traffic measurement aggregate numbers [#], and some newsletters[=]. the work
at nnsc.nsf.net isn't all that much better. part of the problem is
reliance on volunteered information -- the general approach to network
information gathering appears to be not much more than send out a
survey, wait, tabulate the responses. very little of this work is
what you would call "pro-active", that's why chapter 3 (archives)
lists just 26 of the over 1000 anonymous FTP sites and mail-based
archive servers available on the net. [?] (Think of it as a road atlas
that shows less than 1 road in 40 and you'll get the right idea.)
that's not to say that there aren't skilled people out there, it's
just that they're generally not supplied with resources adequate to
the task they're facing. you aren't seeing organizations like ANS,
which seems to be flush with cash and hiring skilled people left and
right, hiring anyone with the archivist skills of a (say) Keith
Peterson. you aren't seeing innovative applications like "archie", a
union list catalog of FTP sites around the globe, funded as part and
parcel of NSF infrastructure; it's being done in Canada, with no
guarantee to continued existence if it starts to swamp their already
soggy USA-Canada slow link or if they need the machine back. [+] you
don't see nic.ddn.mil hosting the arpanet "list of lists" anymore,
they didn't like the contents so it's gone. [@] the internet library
guides are run as best they can by individuals, and they're in the
form of long ascii lists of instructions on how to connect rather than
an interactive front-end that would make the connections for you --
not that the technology isn't there, just that no one has a mission
and the resources to provide them. [!]
so what do we end up with? a very fast net (in spots) with a "savage
user interface" [*]. multi-megabit file transfers, you can get
anything you want in seconds, but no way to find it. regional
networks spending large amounts of federal dollars on bandwidth but
very little on ways to use it effectively. a vast, largely uncharted
network, with isolated pockets of understanding here and there, and no
one yet who has appeared with any of the proper incentives and
resources to map it out.
--
Edward Vielmetti, MSEN Inc. moderator, comp.archives emv@msen.com
references for further study:
[*] eff.org:/npn/. discussion in comp.org.eff.talk.
[@] ftp.nisc.sri.com:/netinfo/interest-groups.
see also dartcms1.dartmouth.edu:siglists
and vm1.nodak.edu:listarch:new-list.*
discussion in bit.listserv.new-list.
[!] vaxb.acs.unt.edu:[.library], also
nic.cerf.net:/cerfnet/cerfnet_info/internet-catalogs*
discussion in comp.misc and bit.listserv.pacs-l.
[+] see discussion in comp.archives.admin. archie information can be
found in quiche.cs.mcgill.ca:/archie/doc/
[%] in nis.nsf.net:maps. note that several are as old as 1988.
no readily apparent newsgroup for discussion.
[#] in nis.nsf.net:stats.
no readily apparent newsgroup for discussion.
[=] in nis.nsf.net:linklttr. no convenient way to search through them
short of downloading the whole set.
[&] for instance, see
uunet.uu.net:/sitelists/ (empty)
uunet.uu.net:/citi-macip/ (CITI has withdrawn this code)
uu.psi.com:/pub/named.ca (out of date named cache file still shows
nic.ddn.mil as root nameserver)
discussion in comp.archives.admin
[?] nnsc.nsf.net:/resource-guide/chapter.3/.
note that many entries have not been updated since 1989.
discussion in comp.archives.admin.J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) (06/17/91)
in the medium term, this may be helped a bit by the massive effort in the ietf directory group... in the longer term, shared file systems with clever chaching and replication, and shared window systems, and good navigation tools will be needed too... shared filesystem technology will obviate the need for (ftp foo.bar; ls; cd dirX)* type activity, but will lead to semi-efficient find -print shared window systems could lead to very fast combined help desk/bboard functionality ... instead of day lonmg exchanges like... mail fred "where'sA"; repl bloggs "in docs/goo.tar.Z" on fiasco.obscureUniversity.ac.uk repl fred "what do i do with .tar.Z files? by (pure) cooincidence, we have just been talking about rationalising ftp (re-)distribution here via AFS...as one example of order out of chaos the greatest hope is that the library/information service people who are used to terra-reference searchspaces will go on increasing their involvement the way they have started (e.g. our UCL/London librarians just ran a video conference last week over part of the internet to talk to some MIT and other librarians)... jon
clw@MERIT.EDU (06/17/91)
The Directory Group at MERIT, Chris Weider and Mark Knopper, are starting to address some of these issues. I do think that Directory Services are a good medium term answer, and we're starting to put everything which fits the X.500 philosophy into X.500.... Chris
jqj@DUFF.UOREGON.EDU (06/17/91)
I think online directory services are only one aspect of the problem that EMV raised. I'm not convinced that a global shared file system will help too much (a shared file system uniting AFS/unix with Novell, Appleshare, and typical IBM mainframe file systems is still several years away, and you still need to know how to navigate through that gigantic file system!), except by improving/regularizing the user interface. I'm also not convinced that we should expect the CNI or library folks to rescue us (unless you believe that the research-library card catalog model is the right one for dynamic network information). From my perspective, EMV's important point is that there is no equivalent of a AAA (or any other national Automobile Association) to provide travel information services, personalized maps, triptics, towing services, motel certifications, etc. for normal people (rather than hackers like us). Perhaps what we need is a users' group that is tied to international networking rather than to a particular computer vendor or even to a particular internet or particular protocol stack. "American Networking Association" anyone? Where should I turn for advice about where I might take my family for its next network vacation? Come to think of it, in addition to a AAA analog, perhaps we need an AA analog too. "Networkers Anonymous" to help those poor souls who have become adicted to cyberspace. [p.s. please note the lack of :-). I'm more serious than it appears.] JQ Johnson Director of Network Services Internet: jqj@oregon.uoregon.edu University of Oregon voice: (503) 346-1746 250E Computing Center BITNET: jqj@oregon Eugene, OR 97403-1212 fax: (503) 346-4397
emv@msen.com (Ed Vielmetti) (06/18/91)
In article <9106171612.AA01441@mazatzal.merit.edu> clw@MERIT.EDU writes:
The Directory Group at MERIT, Chris Weider and Mark Knopper, are starting
to address some of these issues. I do think that Directory Services are
a good medium term answer, and we're starting to put everything which
fits the X.500 philosophy into X.500....
All due respects, Chris, but X.500 doesn't address many of these
issues at all, and the ones it does sort of fit into can be more
easily addressed with other tools.
X.500 Directory services assume a neat, structured, hierarchical name
space and a clear line of authority running from the root all the way
to the leaves. Indeed, most X.500 services in place on the internet
today that work well enough to be useful run off of centrally
organized, centrally verified, and bureaucractically administered
information -- the campus phone book. For what this is, it's great --
i'm happy that I can finger user@host.edu at any number of sites and
get something back. But that is of little relevance to the archives
problem.
X.500 services are hard to run -- the technology is big, bulky,
osified. So the people who are most interested in running it are the
"computer center" folks. If you look for the innovative, interesting,
and desirable applications that you'd want to find on the net, you'll
see that many of them are being done out in the field in departmental
computing environments or increasingly in small focused private
commercial or non-commercial efforts. There's not a terribly good
reason for these two groups to communicate, and so most X.500 projects
have much more structure than substance.
X.500 services are directory oriented. The data in them is relatively
small, of known value, and highly structured. Information about
archive sources is just about completely counter to these basic
principles. The amount of information about any particular service
which you'd like to have on hand can be quite considerable; perhaps at
minimum access instructions, but more likely some text describing the
service, who its intended audience is, sample output, etc. In
addition it would be valuable to keep information on user reactions to
the system close to the official provided directory notice; these
reviews (a la the michelin guide) are often more valuable than the
official propaganda put out by the designer. To search this mass of
information, you'll want something much more expressive than the
relatively pitiful X.500 directory access tools -- full text
searching, at the very minimum, with a way to sensibly deal both with
structured data and with more fuzzy matches on "similar" items.
X.500 is a holy grail, there's a lot of money which seems to be being
thrown at it these days in the hope to make it useful. Good luck, I
wish you well. But please, don't try to cram all the world's data
into it, because it doesn't all fit. It's a shame that equivalent
amounts of effort aren't being spent on developing other protocols
more suited to the task. I'm thinking in particular of the Z39.50
implementation in WAIS [*] which holds a lot of potential for
providing a reasonable structure for searching and sifting through
databases which have rich textual information. Perhaps it's just as
well that federal subsidy hasn't intruded here and clouded people's
judgments on the applicability of a particular technology to a
certain task.
--
Edward Vielmetti, MSEN Inc. moderator, comp.archives emv@msen.com
"often those with the power to appoint will be on one side of a
controversial issue and find it convenient to use their opponent's
momentary stridency as a pretext to squelch them"
[*] think.com:/public/wais/,
also quake.think.com:/pub/wais/droms@SOL.BUCKNELL.EDU (Ralph E. Droms) (06/18/91)
jqj@duff.uoregon.edu (JQ Johnson) writes:
From my perspective, EMV's important point is that there is no equivalent
of a AAA (or any other national Automobile Association) to provide travel
information services, personalized maps, triptics, towing services, motel
certifications, etc. for normal people (rather than hackers like us).
Perhaps what we need is a users' group that is tied to international
networking rather than to a particular computer vendor or even to a
particular internet or particular protocol stack. "American Networking
Association" anyone?
Might I also suggest a 'Consumers Reports' for the Internet, with
unbiased evaluations of protocol implementations, hardware components,
etc.? There is a lot of experience and expertise pass around by
word-of-mouth; we could use a more formal delivery system for those
non-networking folks who don`t attend IETF meetings or subscribe to
TCP-IP.
How does all of this tie into the 'The Internet Society'?
- Ralph Droms Computer Science Department
droms@bucknell.edu 323 Dana Engineering
Bucknell University
(717) 524-1145 Lewisburg, PA 17837worley@compass.com (Dale Worley) (06/18/91)
In article <EMV.91Jun18000345@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
X.500 services are directory oriented. The data in them is relatively
small, of known value, and highly structured. Information about
archive sources is just about completely counter to these basic
principles.
X.500 is a holy grail, there's a lot of money which seems to be being
thrown at it these days in the hope to make it useful.
What can be done to produce good catalogs? As Ed notes, archive
information is likely to be bulky, chaotic, and of unknown (probably
small) value. Given how much money is needed to get a directory
system for information without these problems running, it will
probably take much more to get a good system for archive information
working.
Perhaps the analogy to road maps can be a guide -- Roads have been
around for thousands of years, but road maps have only been available
for fifty(?) years. What happened? One thing is that it is now
possible to make a map and then sell thousands (hundreds of
thousands?) of copies, thus making each copy reasonably inexpensive.
Until the development of the automobile this was not possible, there
were too few potential users. (Or even necessary, since a horse cart
is slow enough that stopping to ask directions in each town isn't a
burden.)
One possibility is to make a service that charges you for use. A good
archive information system should see enough use that each query can
be quite inexpensive. And the authorization and billing should be
easy enough to automate!
Dale Worley Compass, Inc. worley@compass.com
--
Perhaps this excerpt from the pamphlet, "So You've Decided to
Steal Cable" (as featured in a recent episode of _The_Simpsons_)
will help:
Myth: Cable piracy is wrong.
Fact: Cable companies are big faceless corporations,
which makes it okay. scs@iti.org (Steve Simmons) (06/19/91)
worley@compass.com (Dale Worley) writes: >What can be done to produce good catalogs? As Ed notes, archive >information is likely to be bulky, chaotic, and of unknown (probably >small) value. Given how much money is needed to get a directory >system for information without these problems running, it will >probably take much more to get a good system for archive information >working. Arguing with an analogy is silly, but I'm gonna do it . . . :-) In the middle ages, maps were often critical trade secrets. A chart of waters was worth significantly more than its weight in gold, as it revealed both what places existed and how to get there and back safely. The Portugese managed to keep the "safe route" to Japan secret for an incredibly long time. Trivially yours, Steve -- "If we don't provide support to our users someone is bound to confuse us with Microsoft." -- Charles "Chip" Yamasaki
carroll@ssc-vax (Jeff Carroll) (06/19/91)
In article <9106171742.AA26647@phloem.uoregon.edu> jqj@DUFF.UOREGON.EDU writes: >From my perspective, EMV's important point is that there is no equivalent >of a AAA (or any other national Automobile Association) to provide travel >information services, personalized maps, triptics, towing services, motel >certifications, etc. for normal people (rather than hackers like us). >Perhaps what we need is a users' group that is tied to international >networking rather than to a particular computer vendor or even to a >particular internet or particular protocol stack. "American Networking >Association" anyone? Yup. Even with distributed file systems there's no way of knowing _a_priori_ which volumes to mount, or to attempt to mount. There's something of a start being made toward this type of service in the form of servers which provide information on other servers. An example which comes to mind is "archie", a server (running at a location that I haven't yet committed to memory) which serves as a pointer to other archive sites for various types of code and documentation. Before netland becomes tractable to the general public, it will have to emulate the functionality of a fairly complete videotex system. Another problem which will eventually have to be addressed (once the issue of commercial use of the Internet is put to bed) is protocols for handling commercial transactions (how to pay your dues to the Network Association, or make a contribution to FTPers Anonymous). -- Jeff Carroll carroll@ssc-vax.boeing.com "...and of their daughters it is written, 'Cursed be he who lies with any manner of animal.'" - Talmud
jason@hpcndjdz.CND.HP.COM (Jason Zions) (06/19/91)
>Efforts by existing commercial internet providers have been mediocre >at best. None appear to be much interested in mapping out the network >beyond the immediate needs of their customers. If you consider that >one of the roles of a commercial internet provider is to provide >access to software archives, and then you take a look at the state of >the software archives on uunet.uu.net and uu.psi.com, Ah, but many people do *not* consider provision of software archives to be a role for a commercial Internet provider. If I want a reliable transport medium to get bits from *here* to *there*, I pay a commercial Internet provider. If I want access to software archives, I find someone in the business (paid or _gratis_) of providing such a service. I believe it would be a mistake for the government to be expected to provide anything in the area of software archives or the like, except for giving away software they possess which was written at taxpayer expense and is therefore in the public domain. If the keepers of NREN are given the task of maintaining software archives, they're likely to start looking at what's in the archives and choosing what they will and will not make available. Do you really think the government would keep something like the Code Breaker's Workbench in any archive it maintained? Would it even store references to archives not under government control where such software might be maintained? NREN should be just that - a data highway. If you want the equivalent of a AAA TripTik, go to the equivalent of AAA and buy it; likewise for Rand-McNally maps and such. A more-apt metaphor, by the way, would be something like a Guide to Roadside America or some other sightseeing or travelling guide. Researching raw data and deciding what to put in those guides is what you pay for when you buy one, and those activities require (a) good judgement and (b) some restraint from censorship, neither of which is a known strength of the US Government. -- This is not an official statement of The Hewlett-Packard Company. No warranty is expressed or implied. The information included herein is not to be construed as a committment on HP's part. The devil made me do it. This won't save me from the lawyers' wrath, but it can't hurt. Jason Zions The Hewlett-Packard Company Colorado Networks Division 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 USA jason@cnd.hp.com (303) 229-3800
ajw@manta.mel.dit.CSIRO.AU (Andrew Waugh) (06/19/91)
In article <EMV.91Jun18000345@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: > X.500 Directory services assume a neat, structured, hierarchical name > space and a clear line of authority running from the root all the way > to the leaves. While this is certainly true, it is important to understand why this is so. X.500 is intended to support a distributed directory service. It is assumed that there will be thousands, if not millions, of repositories of data (DSAs). These will co-operate to provide the illusion of a single large directory. The problem with this model is how you return a negative answer in a timely fashion. Say you ask your local DSA for a piece of information. If the local DSA holds the information you want, it will return it. But what if it doesn't hold the information? Well, the DSA could ask another DSA, but what if this second DSA also doesn't hold the information? How many DSAs do you contact before you return the answer "No, that piece of information does not exist"? All of them? X.500 solves this problem by structuring the stored data hierarchically and using this heirarchy as the basis for distributing the data amongst DSAs. Using a straightforward navigation algorithm, a query for information can always progress towards the DSA which should hold the information. If the information does not exist that DSA can authoritatively answer "No such information exists." You don't have to visit all - or even a large proportion - of the DSAs in the world. It is important to realise that this is a generic problem with highly distributed databases. The X.500 designers chose to solve it by structuring the data. This means that X.500 is suitable for storing data which can be represented hierarchically and is less suitable for storing data which cannot. Exactly what data will be suitable for storing in X.500 is currently an open question - there is simply not sufficient experience. The proposed archive database which started this thread will have exactly the same problem. The solution chosen will, if different to that X.500 uses, will have problems as well. There is no such thing as a perfect networking solution! >X.500 services are hard to run -- the technology is big, bulky, >osified. So the people who are most interested in running it are the >"computer center" folks. If you look for the innovative, interesting, >and desirable applications that you'd want to find on the net, you'll >see that many of them are being done out in the field in departmental >computing environments or increasingly in small focused private >commercial or non-commercial efforts. There's not a terribly good >reason for these two groups to communicate, and so most X.500 projects >have much more structure than substance. > >X.500 services are directory oriented. The data in them is relatively >small, of known value, and highly structured. Information about >archive sources is just about completely counter to these basic >principles. The amount of information about any particular service >which you'd like to have on hand can be quite considerable; perhaps at >minimum access instructions, but more likely some text describing the >service, who its intended audience is, sample output, etc. In >addition it would be valuable to keep information on user reactions to >the system close to the official provided directory notice; these >reviews (a la the michelin guide) are often more valuable than the >official propaganda put out by the designer. To search this mass of >information, you'll want something much more expressive than the >relatively pitiful X.500 directory access tools -- full text >searching, at the very minimum, with a way to sensibly deal both with >structured data and with more fuzzy matches on "similar" items. > >X.500 is a holy grail, there's a lot of money which seems to be being >thrown at it these days in the hope to make it useful. Good luck, I >wish you well. But please, don't try to cram all the world's data >into it, because it doesn't all fit. It's a shame that equivalent >amounts of effort aren't being spent on developing other protocols >more suited to the task. I'm thinking in particular of the Z39.50 >implementation in WAIS [*] which holds a lot of potential for >providing a reasonable structure for searching and sifting through >databases which have rich textual information. Perhaps it's just as >well that federal subsidy hasn't intruded here and clouded people's >judgments on the applicability of a particular technology to a >certain task. As for the rest of the posting, all I can say is that it must be great to know so much about the costs and benefits of using X.500. From my perspective, it is obvious that X.500 will not solve all the world's problems (nothing ever does :-) but it is way too early to be so dogmatic. When we have had 1) The necessary expericence of implementing X.500, running X.500 databases and storing different types of data in such a database; and 2) experience in alternative highly distributed databases. (X.500 might prove to be extremely poor for storing certain types of data - but the alternatives might be even worse.) then we can be dogmatic. andrew waugh
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/19/91)
Instead of complaining about how inappropriate X.500 is for all but the simplest problems, why don't we identify the problems we're really trying to solve? I think that the Internet People Problem---make a *usable* database of people on the Internet---embodies most, if not all, of the technical and political difficulties that an archive service has to overcome. You want to find that vocrpt package? I want to find Don Shearson Jr. You want to find a SLIP-over-the-phone package? I want to find a SLIP-over-the-phone expert. You want to know where you got this collection of poems? I want to know where I got this phone number. You want to see what everyone thinks of vocrpt now that you've found it? DISCO wants to get references for Shearson from anyone who's willing to admit he's worked with him. One advantage of starting from the Internet People Problem is that it has a lot more prior art than the archive problem, from telephone directories on up. Once we've solved it we can see how well the same mechanisms handle data retrieval. ---Dan
randall@Virginia.EDU (Randall Atkinson) (06/19/91)
I for one would like to see any NREN proposal include the keeping of a "archive library catalog" that contains pointers to software archives kept at various sites across the Internet. It needn't keep pointers to all of the tiny anonymous ftp sites, but an index by item that included information on whether it were located on one or more of the major archive sites (Simtel20, UUNET, WUarchive, prep, ucbvax, grape, ncsa, etc.). It would be *nice* if something like Simtel20 were made available and kept orderly as part of the NREN, but it isn't essential because there are enough kind sites already that the net could get by. The catalog pointing to where to look for things is already becoming a problem. When I was at GE, people generally used *me* or a couple of other people as the catalog and that wasn't fun. I know that the same practice exists at a lot of sites -- someone who has been around a little while becomes the catalog of "the usual places to look." Just a few partly-baked thoughts... Randall Atkinson randall@Virginia.EDU
lars@spectrum.CMC.COM (Lars Poulsen) (06/20/91)
In article <EMV.91Jun18000345@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: > X.500 services are directory oriented. The data in them is relatively > small, of known value, and highly structured. Information about > archive sources is just about completely counter to these basic > principles. In article <WORLEY.91Jun18094957@sn1987a.compass.com> WOrley@compass.com (Dale Worley) writes: >What can be done to produce good catalogs? As Ed notes, archive >information is likely to be bulky, chaotic, and of unknown (probably >small) value. Given how much money is needed to get a directory >system for information without these problems running, it will >probably take much more to get a good system for archive information >working. Actually, we know quite well what it takes to raise the signal-to-noise ratio. Administration and moderation. One possible option would be for the Internet Society to sponsor an archive registration facility. Maybe each of the IETF task forces can identify valuable programs that need to be archived, with mirrored servers on each continent, available for NFS mounting as well as anonymous FTP. It should be worth $50 for each site to have access to good easily accessible archives instead of having to keep disk space for everything in our own space. (I know; not every "hobby site" can afford $50, but there are many commercial sites, including my own, that would be happy to help feed such a beaST; I'm sure many academic sites would be able to help, too). -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
perry@MCL.UNISYS.COM (Dennis Perry) (06/21/91)
I disagree with you argument, Jason, about the government not being an organization that should provide archives. Yes, they might select what is in the archive, but I would hope that any commercial provider would also "select" what they archive. Different archivers would potentially select different overlapping sets. The Library of Congress is an archive, along with the National Archives. Both contain docuements which are unique to the archive and which are duplicated by other libraries or archives. Why should software be any different? dennis
jason@CND.HP.COM (Jason Zions) (06/22/91)
The Library of Congress and the National Archives are very special organizations. The LofC is not selective in what it keeps in its collection; every publisher is required to submit two copies (if memory serves) to the LofC to be issued a valid ISBN number, which is close to mandatory in the publishing business. Were a software archive to be founded under government auspices subject to a charter which required it to keep a copy of everything submitted, I'd be less leary; however, such a charter is unlikely and perhaps undesired. Finally, I agree that other archivers would spring up providing those bits the government refused to provide; those archives, however, would not have the special financial (i.e. taxpayer or cross-subsidized from transport fees) support that a government archive would have, and could not compete with such an archive on a fair basis. Jason
perry@MCL.UNISYS.COM (Dennis Perry) (06/22/91)
Jason, although I agree the Library of Congress and National Archives are very special organizations, having used them extensively in the 6 years I have been in Washington, they are selective in what they keep, even if parts must be submitted to receive a number. For example, the LoC does not keep old catalogs (no number?) in general, but they do keep old Sears catalogues (historical interest?) Another government archive that comes to mind is DTIC. The government has tried to privatize DTIC, but industry showed no interest because of the cost of maintaining a lot of information that was not commercially of interest. I think the government has the same problem with Landsat pictures. I suspect that what this illustrates is that commercial archives will select material based on the probabiliy of making money, not on the intrensic value of the material. Thus we get the issue of maintaining historical archives (old RFCs) vs current or standard RFC only. Or in the case of software, that which sells will be available and that which doesn't won't be. This is good from a commercial point of view, but may be bad from other points of view, for what sells today, may not sell tomorrow and will be purged from the archive. I think there is room for both commercial and government archives. In fact, there exist today commercial ventures which sell that which is freely available from the government. Why do people pay for what is free? Probably because of the value added featrues such as accessability, packaging, convenience, advertizing (i.e. knowing it is available), etc. dennis