>I'm  sorry, but  I don't  agree. LISTSERV  *already* will  not run  on a
>majority of BITNET sites, so that argument doesn't mean much.
 
There are over  200 LISTSERVs on the  network, about 5 of which  run on a
system which has  SFS. None of the  systems on which I  presently have an
account is SFS  capable, for example. And  I have a lot of  accounts on a
lot of systems.
 
>Yes, you would still need an authorization list for files, but you would
>NOT need a FILELIST per se.
 
Sorry but  you are not  making sense. In  your previous posting  you said
that  the interface  to  the  user should  remain  constant. For  non-SFS
systems I do need a filelist,  therefore the filelist must also exist for
SFS systems. And  by the way, the  filelist is *not* the  place where the
information "file A B from filelist C is fileid X Y Z" is stored.
 
>Also, I am  not sure what security considerations you  are referring to,
>re: aliasing fileids.
 
I am,  and I  am not  very keen  on the  idea of  describing them  in any
further detail.
 
>but if it  is possible to move away from  that kind of application-level
>simulation I  think the possibility  should receive a much  more serious
>treatment than what it's received here.
 
Could you please elaborate on this?
 
>And even if SFS  proves NOT to be a reasonable  alternative, I think the
>FILELIST support needs to be tightened  up. A maintainer should not have
>to hand-edit FILELISTs to add, remove, or rename files.
 
Absolutely. This  is all planned for  version 2 of LISTSERV.  But this is
another issue entirely.
 
  Eric