In order to support the network-wide  list registration feature (which will be
introduced in release  1.5n), a new list header keyword  is being defined. Its
syntax is:
 
      List-ID= netname
 
Where 'netname' is the network-wide identification of the list. Syntactically,
it can contain up to 32 characters from the following set:
 
      A-Z 0-9 .;:-_#&?/+%$!|
 
Any other character is invalid (ie "just  because it works now doesn't mean it
will  always").   In  particular,   lowercase  characters   are  automatically
translated to uppercase when the keyword is processed.
 
The purpose  of this  keyword, whose value  defaults to the  list name,  is to
establish  a network-wide  identification  for peered  lists,  and to  provide
synonym names for other lists. Let's consider the following problem:
 
1. IBMPC-L@X is peered with IBMPC-L@Y and MD45@Z
 
2. I-IBMPC@A is peered with IBMPC-L@B and I-IBMPC@C
 
3. IBMPC-L@M is a non-peered list.
 
We have two  peered lists, 1 and 2,  but which one is IBMPC-L?  Who would know
that MD45@Z is an IBMPC-L redistribution?
 
The 'network-wide  id' is the  name by  which your list  will be known  to the
other LISTSERVs. It MUST verify the following condition:
 
--> If two lists  have the same List-ID,  and these two lists  are peered ones
--> (ie they have a 'Peers=' keyword in their list header), then the two lists
--> are  peered  together.  Non-peered  lists  do  not  HAVE  to  verify  this
--> condition,  although it  is recommended  that  list-IDs be  unique in  the
--> network.
 
In our  above case,  the owners  of lists  1 and 2  would have  to come  to an
agreement and select  two different ids (eg INFO-IBMPC  and IBMPC-DIGEST). The
owner of list  3 ought to use  a different id (possibly just  keeping the list
name), or he might use IBMPC-DIGEST as well, although this is not recommended.
 
Concretely, you  need to introduce a  List-ID keyword in one  of the following
cases:
 
- Non-peered list: if  you don't like the listname, you  may provide a List-ID
  as a synonym. This will be accepted on most LISTSERV commands, but you still
  have to send mail to the listname address (for obvious reasons).
 
- Peered lists:
 
  * If all the peers do not have  the same listname, you MUST define a List-ID
    keyword which must be the same for all the peers.
 
  * If all the peers have the same listname, you may or may not wish to define
    a List-ID as a synonym. If you do, it MUST be specified on ALL the peers.
 
In any case, the List-ID is the only name by which your list is known to other
servers.  That   is,  if  the  owner   of  IBMPC-L@M  defines  a   List-ID  of
"IBMPC-FREAKS", then:
 
- Commands sent to his server will work with both IBMPC-L and IBMPC-FREAKS.
 
- Commands sent to other servers will work ONLY with IBMPC-FREAKS.
 
I  therefore recommend  not to  define List-IDs  for non-peered  lists without
reason.
 
The change should be made NOW, to avoid getting into (transient) problems when
1.5n is  released. 1.5m  will just  ignore the  List-ID specification,  so you
won't have any problem with this.
 
  Eric