There has been some interesting mail about this draft on the BITNET LISTSERV
meta-list [log in to unmask] - some readers of the Unix LISTSERV mailing
list may want to subscribe to the LSTSRV-L mailing list to follow the
discussion.  (The subscribe command is the same, but remember that you use
SIGNOFF rather than unsubscribe when dealing with BITNET LISTSERV).
 
I've made some files accessible via LISTSERV or FTP from cs.columbia.edu for
anyone interested - you can get them as /listserv/archives/<filename>.Z or via
[log in to unmask], using "get listserv <filename>".  The files
available are
 
mailservers-00.draft            the actual draft RFC
mailserver-mail                 the messages on LSTSRV-L
rfc1327                         RFC for RFC822<->X.400(88)<->X.400(84) mappings
rfc987                          obsolete RFC822<->X.400(84) mappings
rfc1026                         corrections to RFC987
 
There is also another BITNET LISTSERV meta-list: [log in to unmask],
but it seems to mostly have discussion of mail forgery at the moment.
 
I haven't looked too closely at the Internet Draft by Houttuin/Cargille, but
it would certainly apply to the Unix LISTSERV implementation .  I don't have
anything against using X.400 for the definition, as long as all the terms are
explained in such a way that someone knowing only RFC822 can understand it,
but a brief look at the draft wasn't very encouraging.
 
The first sentence of the Requirements section (the meat of the proposal) is
particularly opaque to anyone unfamiliar with X.400:
 
 4. Requirements
 
    MBSs shall follow the requirements defined in X.411 and
    X.420 as a minimum. This document describes additional
    requirements in terms of P1, P3, and P2.
 
There is no description of the requirements specified in X.411 and X.420, or
what their implications for RFC-822 based systems are, and P1, P2 and P3 are
never defined, although I get the idea that they represent various parts of
the X.400 message - perhaps envelope, header, and body?
 
What's more, the specification is in terms of the older X.400(84) standard,
while the latest RFC for RFC-822 <-> X.400 mapping uses the newer X.400(88)
standard as a baseline.  If we have to write RFCs using X.400 terminology,
let's at least be consistent.
 
Finally, although the draft talks a lot about what kinds of things one should
do with headers, there is no attempt to talk about what kinds of commands
these mail-based-servers should support.  The commands I'm talking about here
are the ones which go in the body of a message, which is just about the only
part of a message you can *really* trust not to get mangled after your message
has gone through Compuserve, UUCP, BITNET (and who know, even X.400!).
 
You don't want to overspecify this part, since the subscription request
commands which a LISTSERV might support aren't relevant to a mail-based archie
server, but there is a lot of overlap in the commands which the different
mail-based servers, and annoying little differences (is the command to set the
return address PATH, MAILPATH, or ADDRESS?).  And please don't say "just put
the return address in the Reply-To: header (or P2.ReplyTo field)" since there
are many many people out there who use mail systems which mangle even that
field (or which can't generate it at all).
 
At the very least, there should be some words to the effect that body lines
which look like headers (first word ends in a ":") should be ignored (there
are some horrible mail systems which generate these atrocities and the poor
user has no way to disable them), that all commands should be case
insensitive, that the command HELP on a line by itself should send a message
explaining how to use the service, etc. etc.
 
It would be interesting (as an appendix, perhaps) to list the implementations
of mail-based servers which are available, with some indication how far they
are from implementing the standard.  There are a number of ones with very
similar functionality, ranging from BITNET to Unix LISTSERV, to the Internet
and various other NIC's automated file servers, the mail<->ftp gateway
programs, and even programs like archie.  It would be useful to compare the
command sets of these programs and look for common functionality.
 
In any case, assessing the various implementations of mail-based servers which
are already out there will be important for evaluating the practicality of the
Requirements for Mail Based Servers RFC.
 
@alex
--
inet: [log in to unmask]
Member of the League for Programming Freedom -- write to [log in to unmask]