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