The idea of  a 'storeheader' command seems  good to me; anyway,  the main point
for the  include proposal is that  is would allow a  *separate* maintenance for
the  descriptive  part, which  could  then  be treated  as  a  normal file  and
stored  with  a  single  operation  at   all  the  peer  servers  by  a  single
coordinator. I.e, I find useful to be  able to separate the parameter part from
the  description  part. Perhaps  both  options  could be  implemented;  another
strategy  would be  to allow  only selected  filetypes for  included files  and
have specific commands for those includings: for example,
 
% DESCRIPTION could mean  'include here the description file  (supposed to have
              a fileid of "listname DESCRIPT")', and
 
% PARAMETER   could mean 'include "listname PARMS"' or suchlike.
 
The interpretation process definition could  state that the DESCRIPT file would
not  contain  keywords  and  the  PARMS  file  would  contain  preferably  only
keywords,  probably with  some rule  allowing 'blank'  or 'override'  keywords.
 
This rises another  important point: maintaining a large number  of lists would
be much  easier if  some part  of the headers  could be  commoned --  note that
in  this  case one  cannot  use  the 'fixed  fileid'  rule.  I'm thinking,  for
example, in the 60+ ARPA redistribution  lists: we could define unique DESCRIPT
files for each list, create a  special ARPA FILELIST for them, correctly linked
(and not  necessaryly limited  to the redistribution  backbone), create  also a
ARPA HEADER  or ARPA PARMS  common file, and have  each list defined  simply by
a  title,  possibly  a  'reply-to'  keyword, the  local  main  postmaster,  two
includes and the local subscribers.
 
A  final point:  it's often  necessary  to have  the 'main'  postmaster as  the
first owner, to  be able to set  Errors-To= Owner. Is it  possible to duplicate
owners?
 
Jose Maria