Last update: 15 October 1994 by
Jacob Palme

E-mail: jpalme@dsv.su.se.
Definitions: The word "discussion group" or only "group" is used below to refer
to services for exchanging messages in a group of people, irrespective of
whether this service is provided by Usenet Newsgroups or by e-mail mailing
lists.
Users perceive personal e-mail, distribution lists and Usenet News as very
similar services. They want these three services to behave in similar ways and
they want to be able to use the same or similar commands in all three
environments.
These user requirements of course reflect directly on the user interface of
client software, not on the protocol. But the e-mail (RFC822 as extended by
other RFC-s) and Usenet News (RFC 1036) protocols can be designed to make it
easier or more difficult to make client software which satisfies the user
requirements below.
In particular, users have the following requirements (all users do not
necessarily have all these requirements):
- It should be possible to provide neat, easy-to-use user interfaces to
users. Such interfaces should hide technical complexity to ordinary users.
Example: Users should not have to format syntactically correct commands as
text in messages they have to send to mailing list servers. These commands
should be standardized, so that they can be hidden from non-technical users by
good user interfaces.
- Users who have other languages than English as their native tongue, should
not, unless they so prefer, be forced to use English-language user interfaces.
Example: Standards for heading fields and network commands allow the user
interface to translate these to the language of the user.
- Many users have learnt to use Gopher and WWW clients as general-purpose
client software to access many different servers. Such users should be able to
use this client software also for performing administration of their
participation in discussion groups.
- Users should be able to read new messages sorted by discussion group, and
be able to read personal messages, sent to them individually, separately from
messages coming from mailing lists.
- Similar format for viewing messages in all three environments (personal
e-mail, mailing lists, newsgroups). This especially applies to message headers.
- The same heading field should have the same or similar meaning in all
three environments.
Examples: Usenet News should not use "Supersedes:" when e-mail uses
"Obsoletes:" (RFC 1327) and Usenet News should not use "Expiry Date:" (RFC
1036) when e-mail uses "Expires:" (RFC 1327).
- Information given on to whom (individuals, lists and newsgroups) a message
was sent should be consistent in all three environments.
Example: Information about which groups a message was sent to should
preferably not be labelled "Newsgroups:" in one environment and "To:" in
another environment.
- Information on where to send replies shoud be consistent in all three
environments.
Examples: "Reply-to:" could indicate where personal replies (only to the
author) should be sent in all three environments, and "Followup-To:" could
indicate where group replies are to be sent in all three environments.
- The same name should preferably be shown to the users, when referring to a
discussion group, whether the group appears as a Usenet Newsgroup or as a
mailing list or both. If this is not technically possible, at least the names
should be easily related to each other in a way which is understandable to the
users.
- Conversations (chains/trees of messages referring to each other) should be
handled in ways which makes it easy for users to scan such chains, and to
withdraw from a conversation without unsubscribing from the whole group.
- It should be possible to let a person who is not a member of a discussion
group participate in a particular conversation going on within that
group.
- Users should be able to easily send the same message, at the same time, to
one or more newsgroups, one or more distribution lists and one or more
individual recipients.
- Recipients should not be forced to see the same message more than once
even though the message was sent to more than one newsgroup or distribution
list.
- Users who have e-mail but no other Internet access should be able to
participate in discussion groups with similar commands, independent of whether
the group is a newsgroup or a distribution list.
- All Usenet Newsgroups should be available as mailing lists for those users
who only have e-mail connectivity. (??) Is there a reverse requirement that all
mailing lists should be available also as some kind of Newsgroup?
- Users of existing services should be able to continue using as far as
possible the services in the way they have become accustomed to.
Conclusion: The service should interwork well with existing protocols for
e-mail (both Internet and X.400 e-mail) and for Usenet News.
- Users should be able to use similar commands in order to find newsgroups
and distribution lists, to subscribe to them and to unsubscribe to them.
- Moderated and un-moderated, closed or open discussion groups should as far
as possible be handled with similar commands for ordinary users. This includes
commands to submit contributions and to ask for membership in the group.
- Discussion groups should be either open to anyone, or open to specified
groups (such as employees of a particular company or members of a particular
society), or closed where all new members must be approved by the administrator
of the group.
- Users can be ordinary members of discussion groups or have special roles
such as moderators or administrators. Also moderators and administrators more
and more often are people without technical expertise in the computer area.
Thus, the user interface should be friendly not only for ordinary users but
also for users with special roles like moderators and administrators.
- Users should be able to access archives of old messages, if such exist,
with similar commands, irrespective of if the messages are stored in a Usenet
News server or in some kind of mailing list archive.
In order to satisfy these requirements, there should be standards for the
functions listed below. All the functions should be available through mail
servers, to support users who only have e-mail access, but the functions should
also be available through direct network connections so that users with full
Internet access can get direct responses to their commands from the server.
- Find information about available discussion groups.
- Subscribe to discussion groups.
- Ask the administrator of closed groups to let them to become members.
- Withdraw from discussion groups.
- Submit contributions.
- Submit contributions obsoleting their own previously submitted
contributions.
- Read contributions.
- Retrieve and find old contributions.
Facilities for moderators:
- Find submissions.
- Accept or reject submissions.
- Start new discussion groups.
- Announce new discussion groups to prospective members.
- Find requests for membership to discussion groups.
- Add and remove members from discussion groups.
- Cancel discussion groups.
- Appoint moderators and/or new administrators.
- Modify the attributes of discussion groups. Examples of such attributes
are whether the group is moderated, where and for how long archives are kept
etc.
See also: