🚀 go-pugleaf

Aydin Edguer writes
> peterd@cc.mcgill.ca (Peter Deutsch) writes:
> >I understood this to mean that he was advocating control over
> >who would be qualified to set up a gopher server.  .  .
  .  .
> Perhaps you should go back and re-read what you said and what he  
said.
> 
> You stated "Certainly, McGill has the right to limit my ability to  
use their
> facilities". .  .  

They do, and I would argue that this is not the same as
censorship as I was discussing it. I should have the right to 
say anything I like, but that doesn't mean I can compell
others to pay for my soapbox. Now, if I was denied access to 
the net, that would be censorship. If I am merely denied access to
their machines and have to pay a commercial provider for a code,
that's economics.

> .  .  . You then accuse someone [Joel Cooper] of advocating  
censorship
> when they ask you to make the service distributed so that each domain  
may
> use its own rules to control dissemination of information from within  
its
> domain [not from other domains].

I'm sorry, that is _not_ what he wrote. I'll include the appropriate
portion of his letter again, and this time remove my intervening 
comments:

%> .  .  .  Also I have heard some concern expressed by individuals at  
%> several academic institutions about "just anyone" being able to set  
up their own 
%> Gopher server and start serving up whatever. My own thinking on this  
matter at  
%> this point is that we should approach this in somewhat the same way  
as DNS--not  
%> everyone gets to set up their own domain nameserver, these things  
tend to be  
%> done cooperatively both within and between institutions, and there  
are  
%> individuals who are ultimately responsible for their function.
%> 
%> There needs to be a mechanism of "registration" (as there now  
informally is with  
%> "Gopher Central").  This will make people like librarians,  
maintainers of  
%> existing CWISes, university administrators, maybe even network  
administrators, a  
%> lot more comfortable.

See? He writes that not everyone should be able to offer Gopher
servers. Anlagous to DNS, there should be controls on who can set
up such a server and a registration mechanism ("a la Gopher Central") 
to ensure compliance. The objective is to make librarians, 
administrators, etc "more comfortable".

That is controlling who can publish. Now, we haven't heard back from 
Joel and this may not actually be what he is advocating, but _my_ 
reading of the above paragraph is that he is NOT arguing for a 
distributed service (anyone that uses Gopher gets this whether you
want it or not, since this is the very nature of the Gopher
architecture).

What was called for was control over who gets into the Gopher
service tree, and prevention of those who would operate outside of
the Gopher service tree. Unless there is a mechanism for offering and 
locating alternatives (and I proposed one) then this is to me a form of
censorship on the free flow of information.

> The point is that _you_ want to impose a central authority.  If you  
impose
> such a central authority then you open yourself up to worries about  
either
> censorship or unintentional violation of some other domain's  
policies.

I'm sorry, but I find your comments a little surreal. Yes, I am
proposing a central resource discovery service, but there is just no 
way that this somehow implies that I'm the one who wants centralized
control. READ IT ALL AGAIN!

First, just because there is a yellow pages phone book doesn't mean
that there is censorship of information in the phone system. Such
a resource discovery service is a secondary service that tells people 
where information can be found if they don't already know. Any user 
_always_ has the option of bypassing the Yellow Pages and going 
directly to the primary source, provided you know where it is.

In addition, _anyone_ else that wants to can sit down and write
_another_ resource discovery service. This is a purely secondary 
service. I'm NOT controlling what gets published, and I'm on record as 
saying that I would object to any central  authority having 
responsibility for deciding what would get carried in such a directory.

> By distributing the authority, you make it possible to have private  
services
> that are only visible within a single domain and public services that  
are
> visible everywhere within the same paradigm.  One would not have to  
keep track
> of multiple listings [which is the problem I thought you are trying  
to solve]
> just to offer private and public services.

Again, you appear to be confusing the distributed nature of the
Gopher service (which I heartily endorse, BTW) and the centralized
nature of a Yellow Pages directory service. The distributed authority
to offer information is in no way threatened by having the name
of those services that want it also appear in a secondary directory.
The problem I want to solve is that, short of scanning the entire
Gopher tree, there is currently no mechanism for locating specific
servers. I would address that with a generalized directory.


I don't know how it is happening, but you and I are 
both reading the same words and see the exact opposite contents. 

_I_ see Joel's proposal as being to limit who would be allowed to offer 
a server. I object to this. _You_ see his proposal as advocating
a distributed information service, and are all for it. I just
can't see that in what was quoted above.

You see _my_  proposal to gather descriptions  of service as somehow
imposing control on those services or what they can offer. I see
it as a way of addressing the resource discovery problem and bypassing
proposed limitations on who should be allowed to offer such services
to those that have been officially "registered".

We are currently talking at complete cross-purposes. I don't know why
but I do think you misunderstand my position.


> By distributing the authority, you permit easy creation of services  
within
> domains which don't care, or restrictions on the creation of services  
within
> domains which do care.
> 
> By distributing the authority, you end worries about delays in  
creation or
> deletion because the maintainer is out of town.

Sorry, but at NO TIME did I ever argue for central control on who
gets to offer servers. That was the _other_ guy. The only 
element of centralization in _my_ proposal was that I believe that
a Yellow Pages model of resource discovery could work in presenting a 
Resource Information Service. I further believe that our experience
with archie demonstrates this to be true in at least some instances.

Of course, if you don't like my service you will be free to not use it 
and in no way will that impact on the service providers' ability to 
offer you information or your ability to access those services. Really, 
I promise... :-)


> By distributing the authority, there will be fewer _unexected_ spikes  
in
> network traffic for network administrators to puzzle over or get  
upset about.
> 
> This is the ideal.  Each domain can be as open or closed as they wish  
in
> what services they provide, but are fully open in what services they  
receive.

I almost skipped over this since I find myself repeating the same
thing over and over but you really do seem to have a basic
misunderstanding of my proposal, and perhaps how archie itself works. 

The current archie merely mirrors the information available at any
particular site into a central repository or database. Users of archie 
can come to our machine and expend our cycles searching for information 
in this database. They don't need to know a priori where this 
information came from, greatly easing the "Resource Discovery Problem" 
from their point of view.

What I am proposing is to do something similar, but track instead
service providers themselves. We plan to gather the hostname, address,
service type and a brief description (where available) of any service
that wants to be tracked. Preferably and hopefully this information
will be updated periodically to ensure the continued accuracy of the 
database.

Users will be able to come to our server and ask, for example, for the 
hostname and IP address of all archie anonymous FTP servers, or all 
FTP archives with a particular string in their descriptions, etc.

Thus, it is conceivable that someone in the McGill Faculty of
Music could come along and set up a server that specializes in
information about classical music. If they provide us with a pointer
to their server and a brief description of its purpose, Internet users 
would then be able to come to us and then find the server without ever 
seeing the actual announcement that was posted to, say, alt.gopher when 
the server came up.

So, were does this imply control? Well, if we are right and this is
a useful thing to do, then if we started denying people entry
into our directory it might be seen as censorship or control, provided
there were no alternative ways to discovery a service.

But on the contrary, there are any number of other ways to discover
such services. If someone wants to put a pointer to it from another
server, it could be found by brute force searching. Alternatively,
I would hope that one day there are any number of such directories 
offered by commercial firms, just as there are any number 
of commercial directories put out on paper now. In no way does their 
existance imply control over the actual services themselves.


> I understand your worries and concerns, but I feel they are just as  
well
> answered by a distributed service, as an "open" central service. .  .

Sorry, but I don't think you do. The problem we are addressing is the
so-called Resource Discovery Problem. That is, how does a user locate
classes of service providers and specific instances of information,
then access and manage this information in an Internet environment
of potentially millions of machines? It is not enough to say
"it is in Gopher" where there will conceivably be thousands of Gopher
servers within a couple of years, scattered throughout the net.
You will need directory services to help find the specific services
where you should start your search in this environment.

Our approach is to use an actively maintained central 
directory and at least when dealing with a database on the order
of 1000 sites and 150 Meg of data (eg. the present archie) it works 
just fine.

I am NOT proposing to take all information in Gopher and collapse it
onto a single machine. I am talking about serving _pointers_ to
the servers by storing, and allowing users to search on, a brief
description of the service.

Now, I don't claim that this will work for all problem spaces, 
but while we are still talking about a list of several thousand service 
providers (ie for the next couple of years) I believe that this will 
work. Meanwhile, those advocating distributed systems
haven't yet demonstrated that such a system can be deployed and 
maintained on the current Internet. I don't fault a distributed 
architecture as a means of delivering information, but I still have not 
seen a distributed service deployed that to me adequately addresses
the basic problem of resource _discovery_.

It may be that we are only building a stop-gap service
until the "real thing" comes along. That's fine by me. In the meantime,
while people are working on your version of a distributed, usable and
accurate directory service, I'll be providing some basic servicebility.

> .  . . And a
> distributed system helps to answer many of the concerns of  
administrators
> who want to keep track of how their equipment is being used.

No one is being forced to provide Internet resources to the world.
If you want to join a controlled information delivery service
that charges a fee and has a secret handshake, that's your business. 
I just don't want anyone to suggest that they might be able to control 
who gets to join the alternative services that will come into 
existance. That was all I was trying to say.



				- peterd