Greg,
 
I have just obtained a copy of the Houttuin/Cargille Internet draft about
requirements  for mail-based  servers. I  am extremely  concerned by  the
language used in this requirement and by  the impact it could have on our
user community, if  approved. I am sorry  to bother you with this  - I am
afraid  I   don't  know  the   procedure  to  appeal   proposed  Internet
requirements, and  the heading of the  draft did not give  any clue about
this. I thought it would be better to bring this to your and the LSTSRV-L
membership's attention rather than run the risk of starting another flame
war on the main IETF list.
 
The paper states, right on from the abstract, that it applies not only to
all possible e-mail based servers in the Internet, but also to all e-mail
networks connected  to the Internet.  This, in practice, means  about any
network  which  is not  totally  closed  from  the "outside  world",  and
includes of course  BITNET. This language is  either inappropriate, given
that I do not  have knowledge of any formal contact  between the IETF and
representatives from all  these networks regarding this  topic (Frode and
Jim, please correct me if I  am wrong), or outright scandalous, if indeed
my first impression is right and the  group in question did not intend to
check  with  the  networks  in  question  whether  this  new  requirement
addresses their  needs or not.  I suspect someone  will say that  this is
just what  the RFC  process is about  and that they  were indeed  given a
chance to participate, but this is just like the Vogon captain in Douglas
Adams' series,  and surely  the Internet  would not want  to act  in this
fashion.
 
My second  concern is that  the whole  document is described  using X.400
terminology,  which  I and  most  Internet  (or  BITNET) people  are  not
familiar with. I  did my best to understand the  document using the table
at the bottom, but failed. This makes it pretty difficult for me to judge
whether the requirements are acceptable or not. One particularly annoying
problem is the  statement that mail based servers must  comply with X.411
and X.420 in addition to the new  rules set forth by the standard. I have
no idea what X.411  and X.420 are about and do not  have the time, energy
or patience to  read these standards. I  am very surprised to  see that a
requirement which  applies (among others) to  RFC822-only systems demands
that the reader purchase and read X.400 material.
 
My third  concern is that many  of the requirements I  did understand are
totally arbitrary,  immature or  otherwise based  on the  assumption that
X.400(88) is some sort of holy document which mortals should not question
and which must  be standardized in its  RFC822 mapping as well  - this in
spite of the fact that BITNET  and other real networks have had real-life
experience  with  mail-based servers  for  years,  whereas X.400(88),  if
indeed  it does  possess  a large  user  base,  has at  most  4 years  of
practical experience.
 
An example of arbitrary requirement is the following:
 
>     - Command servers shall not send an output message if
>       the input message contains an P2.inReplyTo or
>       P2.crossReferences field. Instead, the input message
>       is forwarded to the MBS administrator.
 
End users generally find it more  convenient to use the REPLY function of
their user  agent than composing a  new message - this  should be obvious
enough. I  know a number of  users who permanently keep  one message from
their closest  LISTSERV in their  mailbox, just  so that they  can easily
send more commands  by replying to the  old message. I see  no reason why
this  should  be  taken  away   from  them.  Ignoring  messages  with  an
'In-Reply-To:' field does  not even prevent loops,  since delivery errors
do not normally have that field  in the header. Only user agents generate
this field, as far as I know.
 
An example of an immature requirement is the following:
 
>     - Repliers shall not send output messages to addresses
>       which are likely to be MBSs, such as addresses with
>       the following values in the Surname attribute:
>
>            echo
>
>            autoanswer
>
>            listserv
>
>            netserv
 
LISTSERV is such a complex server that it falls in most of the categories
of servers  described in the document,  if one ignores the  fact that the
various definitions do  not always match the exact  behaviour of LISTSERV
to the last comma (the classification is actually another immature aspect
of the draft).  LISTSERV is, among others, a  replier. LISTSERV routinely
receives requests from peer servers (usually via NJE, but this can happen
via e-mail as well), and, depending on the request, may generate a reply.
The requests are received in the exact same format as end-users requests,
although the  servers usually  ask for  internal information  rather than
trying  to subscribe  to  lists.  We are  not  talking  about a  separate
server-to-server communication  medium, but just about  different command
verbs. And, in  fact, some of the  command verbs are used  by servers and
users alike.
 
Furthermore LISTSERV and NETSERV have had,  from as far as I can remember
(1984), the ability  to detect and handle "dumb repliers"  and avoid what
is known  in BITNET lore  as "message wars".  It is disappointing  to see
that  these  usernames have  been  included  in  a proposed  standard  as
potential troublemakers  without contacting their authors  to discuss the
issue.
 
I could  continue, but  I think I  have made my  point. This  document is
attempting  to define  a standard  that  would cause  popular mail  based
servers with a user base of  several hundred thousands to be in violation
of not  one, but a  large number  of points in  the document, to  such an
extent that not only the code but  the very service they have provided to
their users  would have to be  trashed and replaced by  something totally
new and,  I am afraid, not  necessarily more user friendly.  This was not
done after an  open discussion, but "in  the back" of the  authors of the
servers in question  (LISTSERV, NETSERV, TRICKLE, VMSSERV  and probably a
lot  of others  are potentially  affected) -  and without  consulting the
formal  representatives  of all  the  networks  the proposal  planned  to
affect.
 
I have no time to participate in drafting a better version, nor do I have
any desire to  cooperate with the kind  of people who came up  with it. I
only want to formally register my opposition to this standard, insofar as
it is to apply to the RFC822 world, and thank you in advance for pointing
me in the right direction.
 
  Eric