Actually list headers are used for two different purposes:
 
* Defining the list configuration parameters (keywords), and
* Describing the  main subjects,  intended audience,  etc. This  description is
  normally  made  using normal  text,  as  opposed  to the  parameter  section.
 
If a  list header  has to be  informative for  the end user,  so that  he could
reasonably decide if  he wants to subscribe  or not based only  on its contents
(and not  just subscribe to  give a try),  it's desirable that  the descriptive
part be  long and  well documented; this  has, however,  several disadvantages:
 
* List  headers tend  to  be very  long,  slowing the  REView  command and  the
  reception of  the headers for  lists with  many peers (it  took 1 day  for me
  to review IBMPC-L).
 
* The  user gets  bored  with many  identical descriptions  of  the same  list.
 
On  the other  side, the  parameter  part is  essential  in that  it *must*  be
coordinated  in order  to avoid  loops, have  mail distributed  to the  correct
peers, etc, but the description part is  not so important and can be maintained
without having  to lock  all the  lists; futhermore,  editing lists  with large
headers is more complicated than with simple, non descriptive lists.
 
I'll  like to  have an  INCLUDE feature  for list  headers. Let's  take IBMPC-L
as an example. My proposal is to allow some kind of specification as
 
* Info-IBMPC Digest
* (list keywords here)
*
*%INCLUDE IBMPC-L MEMO
*
 
where IBMPC-L MEMO  is supposed to have  no keywords (i.e., any  keyword it may
contain will be ignored). Using FILELISTs,  one could define a IBMPC-L FILELIST
which  would include  IBMPC-L  MEMO;  this memo  could  be directly  maintained
(owned) by  the digest editor  (Billy Brackenridge  in this case),  by defining
all  the  FILELIST  as  peers,  but  the list  headers  could  continue  to  be
maintained (much more easily) by the bitnet redistributors.
 
The  REView command  would continue  to work  as currently  does (by  including
the description  file in a user  transparent way), perhaps with  the difference
that forwarded  reviews could  omit it;  the REView  command could  be enhanced
to  allow a  (NOEXPLAIN  or suchlike  option  to get  only  the parameter  part
(and possibly the list of subscribers also). Even a DESCRIBE or EXPLAIN command
could be implemented to send only the description part if we could agree on a
convenient naming convention.
 
Jose Maria