>... add in a Listserv-Listserv communication
>language of information. (No, I don't have a design)  This could include
>such things as "Here is a list of public lists I have", "Here is a list
>of the dates/versions of my control files", "Here is my postmaster", etc.
>The knowing where each list has been shown as a desirable feature by
>many people.  I think if was Jose Maria that asked we each keep PEERS NAMES
>up to date with list names.  NETMONTH just published a list.  If we had
>a Listserv-Listserv communication, each Listserv could have the entire list
>of lists, acurate within a few days.  (Maybe less, if some of the
>communication was delta format).  This would allow the potential for any
>user to use any Listserv to subscribe themselves to a list.
> ...
>
>Harry
Well, I don't want to just unthinkingly invent more work for Eric, but some
of this kind of thing seems like a great idea.  Sure, it would create extra
network traffic, but it would help to eliminate users sending LIST commands
to every listserv they know about to try to find a list.  Sure, it would
drop some extra work on listservs everywhere, but perhaps it would not be
too much.  Perhaps some statistics on invalid subscription requests at some
backbone and non-backbone listservs would make it clear.
 
Keeping PEERS NAMES up-to-date automatically would be extremely difficult, and
the benefits might not be worth the cost.  But it would be nice to just send
a message to your local listserv to subscribe to some list XXX-L without
having to first track down its location.  Naturally, I would then receive mail
informing me of the particular node at which I had been added.
 
One warning: I think once this gets started, there might be a temptation to
try to do too much with it.  PEERS NAMES needn't contain information about
filelists.  There comes a point where you have to think, "The user has to do
some things for himself."  But I think the distributed SUBSCRIBE command would
be a good thing.
 
---Glenn