>Anyone writing e-mail or list software who doesn't know what the IETF is
>and what it does is incredibly naive. I was aware that IETF was working
>on an RFC dealing with mailing lists,
This RFC is not about mailing lists, it is about defining "mailbox names
for common roles, services and functions." Things like ABUSE, HOSTMASTER,
WEBMASTER and so forth. Only one of the sections is about mailing lists,
and then only about the -REQUEST address. Since mailing lists are not
mentioned in the abstract, I don't see how you can reasonably claim that
mailing list developers should have been aware of this RFC. You have to
happen to be interested in philosophical discussions about the naming for
the address of the NNTP manager to read this RFC and discover section 6.
The reason we are having this discussion is that the WG screwed up. It is
not the IETF's goal or desire to have this sort of thing happen! A RFC
must represent a "rough consensus" in the community, and this can hardly
be the case if the community is totally unaware of the RFC because its
abstract mentions only unrelated issues, and the community was never made
aware of the RFC through the many existing tools at the WG's disposal.
>Lastly, how many complaints have we seen about Microsoft or AOL or
>[insert favorite target here] not conforming to this or that
>well-established RFC standard?
The key here is "well-established." I think RFC822 is a big pile of
manure, but it's been around for 16 years and we all have to follow it
because it defines the protocols that just about everyone implements. We
follow RFC822 not because the IETF says so, but because it is such a
widely implemented and well-established industry standard.
RFC2142 has at best minority implementation. Most lists work differently,
and have worked differently for over 10 years, which in itself
constitutes a strong objection to the change. The IETF does not attempt
to change existing de facto practice without a VERY GOOD reason, and here
the reason is at best tenuous! The problem RFC2142 is trying to solve is
that you cannot know whether to send your commands to LISTSERV@,
Majordomo@ or ListProc@ if all you know is the name of the list, so you
should write to -request instead. Well, all right, but you won't know
what command syntax to use unless you know which software is sitting at
the -request, so this hardly solves anything. Also, in practice you don't
have this problem to begin with. You can't write to -request without
knowing the hostname, and typically you would get the hostname either
from a message inviting people to subscribe or from a list search engine,
in either case you will have subscription instructions.
I think the WG were just wondering what other well-known mailboxes they
could add to the RFC, and they came up with -REQUEST. I don't think they
realized the potential impact of what they were doing. Anyway, LISTSERV
introduced the -SERVER mailbox many years ago to address this problem,
but it was not implemented in other major list managers because there is
simply no demand from the users. RFC2142 #6 is a solution in search of a
problem, and it is a bad solution because it breaks the well-established
-REQUEST tradition. A good solution would introduce a new mailbox name,
such as -SERVER, to avoid alienating existing users. -SERVER would be a
particularly good choice because just about every LISTSERV site already
supports it, but it could be anything else and L-Soft would probably
implement it as long as it were a NEW mailbox and did not break anything.
Eric
