>... 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