Mail, Telnet, Chat, MUD (BD14)

Auszüge aus H.Hrachovec RFCs, MOOs, LMSs: Assorted Educational Devices

• Informatische Festlegungen entstehen aus konventionellen Bedürfnissen, die sie aufnehmen und weiterführen.
• Zum Beispiel: eLearning
• Zwischen der Maschinen- und der Verwaltungstechnik liegen Übertragungsregeln.
• Internetprotokolle implementieren bestimmte kommunikative Muster: Briefverkehr, Befehlsvermittlung, Plaudern, interaktive Spiele.

Zwei Taufakte

eMail

Origins are auratic places or events. This holds true both for high and low culture. The socalled "birth of an idea" is just as likely to be a distinguished event as the rise of a pop star. The same thing does not seem to hold for engineering, yet it is difficult to avoid a shiver of awe and recognition when reading the opening sentence of John Postel's "Request for Comments" #821. We are dealing with the foundational document of what was to become electronic mail. The document is dated August 1982 and it starts off with the following remark:

"The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently."

The sentence seems inconspicuous at first glance. Given the common concept of "mail" the protocol is supposed to ensure its implementation in a networked environment. But there is more beneath the surface of this plain, no-nonsense statement. Notice the implicit discrepancy of cultures. There have been countless attempts to "transfer mail reliably and efficiently" within the framework of traditional services. John Postel refers back to precedents as he introduces a new development.

This is the treshhold at which mail enters the realm of telecommunication. One might call it an act of baptism. We are to be given the outlines of the "Simple Mail Transfer Protocol". "Mail" is no homonym like "Paris" in "Paris, Texas". The working of the term is closer to "New England" which indicates the transference of a certain set of social and cognitive attitudes into a largely unknown environment.

There is no paper involved in this kind of "mail", to pick just the most obvious difference. Sociohistorical projections and questions of technological design are inextricably interwoven at the very beginning of this new area as engineers apply their common sense understanding of mail to a context lacking the appropriate precedents.

eLearning

A rich literature on adapting the classroom to the challenge of computer-assisted teaching has emerged and coping with the various social implications of what started out as engineering rules turns out to be an important issue. The situation is paradigmatic for an assessment of how the IT-market is determining common sense in rich Western countries. Big companies charge universities considerable sums for e-learning platforms that are supposed to boost pedagogical performance and save expenditure for teaching staff.

Consider this variant of Postel's dictum:

"The objective of e-learning platforms is to teach students reliably and efficiently."

Ausschnitte aus: Arthur Mettinger, Charlotte Zwieauer: Neue Medien in der Lehre an der Universität Wien" - das Strategieprojekt 2004 - 2006. In: eLearning an der Universität Wien, Münster 2006.

Mettinger et al.: eLearning an der Universität Wien

Mettinger et al.: eLearning an der Universität Wien

Mettinger et al.: eLearning an der Universität Wien

Ausschnitt aus einer Kritik der Bildungsexperten

K.P. Liessmann: Die Bildungsexperten

Die beiden Textpassagen zeigen auf den ersten Blick in ganz verschiedene Richtungen, nämlich die effiziente Umsetzung der Bolognareform und eine Besinnung auf kulturelle Werte des Abendlandes.

Das Vokabular der Besinnung auf die Humboldt-Werte ist allerdings bemerkenswert

• zentrale Ergebnisse
• einige Jahrtausende
• zu bündeln, zu systematisieren, zu vermittlen
• Grundlagen zu schaffen

Die Auffälligkeit der Bildungsvertreter alter Schule liegt darin: Sie sprechen von immensen Zeiträumen, die sie im Griff zu haben scheinen. Das leistete die humanistische Kultur, die zunehmends verloren geht. Die Mittel der Gegensteuerung sind allerdings, nach dem obigen Sprachgebrauch, Fundierung, Zentralisierung und Systematisierung. Diese Kategorien gelten auch für Datenbanken.

Prozesskommuniktion

SMTP defines the rules that two relays of data-exchange have to obey in order to be considered "transferring mail". The interesting question then becomes: what features of the historical mail system are taken up by Postel's model and how they are implemented in the digital realm? Its pretty straightforward.

SMTP defines a user mail request addressed towards a receiver. The SMTP-user is a digital process which literally initiates a dialogue with the SMTP-receiver. Certain sequences of ASCII code, i.e. "MAIL", "RCPT", "DATA" or "O.K." are exchanged between the participants in an orderly fashion. Here is the general idea as outlines by the RFC:

"The SMTP design is based on the following model of communication: as the result of a user mail request, the sender-SMTP establishes a two-way transmission channel to a receiver SMTP. The receiver-SMTP may be either the ultimate destination or an intermediate. SMTP commands are generated by the sender-SMTP and sent to the receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in response to the commands."

This sounds like a perfectly reasonable way to automatize mail exchange. The familiar vocabulary is in place and technical details are relegated to the appendix. But there is much more going on behind this deceptive facade. Postel's initial move in adapting mail for an internet environment is simple and bold: his "users" are digital processes, conforming to the rules previously obeyed by humans. I am not complaining about technoid reification here, the case is more complex than that. Postel's prescriptions organize the digital realm according to the traditional paradigm — but there is one important twist.

This is digital mail delivery: given certain constraints a client process transmits data to a server process. But what about the user of the mail system? Postel's design imprints our notions of mail exchange upon digital procedures, bracketing the entire context of human use of the protocol. In adapting the concept of mail for application within an inhomogeneous computer network he does not touch upon socio-cultural considerations such as which persons are supposed to send a mail to which recipients. Many people would hold that it is all right to skip the socio-dynamics of message control in favor of establishing an immensely efficient framework for data exchange — and this is where we hit upon a characteristic feature of Western attitudes towards technological innovation.

Computer programs lack intentions. Conceptualizing them as "users" deprives one of the descriptive means to impute them bad faith by spamrning a mailbox. Such activities fall outside the range of SMTP, which is, however, not completely innocent. It is precisely because this protocol embodies the decision not to take care of possible abuse that we are currently confronted with massive spam and security problems.

It would have been comparatively easy to include some authentification clauses into SMTP, it just did not occur to the author and the reason has become obvious: The human users actually employing the programs implementing SMTP did not enter the picture of inter-process communication. This is a typical situation and — to repeat — I do not want to turn it into an argument against technological advances. The aim is rather to show the social embedding of selected internet protocols and to discuss some consequences of the feedback between models from computer science and their originals, i.e. SMTP and mail.

Beispiel SMTP Austausch

Beispiel SMTP Unfug

Telnet

We have to distinguish two types of "users", digital processes and humans. Keeping an eye on this distinction one can describe the communication pattern implemented by SMTP as an asymmetric and asynchronous message exchange. E-mail is a one-way transaction, allowing for a certain time-lag, subject to the contingencies of data delivery and the recipient's behavior. This is in marked contrast to another kind of protocol of which "telnet" is an early and easy example.

John Postel (together with J. Reynolds) is, again, the author of the RFC in question (RFC #854, dated May 1983). And his introduction is, as before, a beautiful setting of the stage:

"The purpose of the TELNET protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communication facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other."

Telnet is bi-directional and synchronous. The protocol, like SMTP, is designed to link two IT-entities within the conceptual framework of employment in use:

"The 'user' host is the host to which the physical terminal is normally attached, and the 'server' host is the host which is normally providing some service."

This type of exchange is basically meant to interact with distant computers regardless of the hardware specifics of either the local or remote system. ASCII code is transmitted back and forth, but not to be dispatched to a human user mailbox. Telnet provides facilities to list information and run programs on computers available in the network. There is no obvious predecessor to this digital transaction, hence the lack of a suggestive name. And it is not by coincidence that this protocol — and in particular conforming applications — are much less familiar than SMTP.

Telnet is an expert's tool. In general, there is no need for an ordinary user to interact with remote machines. Starting and monitoring processes is part of system administration. This is where the synchronous nature of the protocol comes in handy. Its workings are modeled along the pattern of the physical employment of some machines, for example microwave ovens. A user interacts with such items in real time. She transmits commands that are (in most cases) to be directly executed, making her a participant in a live event, which simultaneously includes human input, digital sequences and their mutual feedback.

Obviously, this is more demanding — and interesting — than e-mail. It is a very simple instance of tele-presence in the following sense: A person is afforded global, on-line access to digital resources in real time. This protocol close-circuits the human user and her digital opposite. It does not only copy text from one place to another but, additionally, enables one to personally execute programs in faraway locations, since text strings can be interpreted as command sequences on the host machines. SMTP and telnet represent quite different modalities of internet space, clearly involving distinct temporal patterns and diverging, attitudes. The point can be made more forcefully by looking at another synchronous protocol.

Internet Relay Chat

This protocol, dating from May 1993, provides the standard for chatting, or, as it is officially called, for the "Internet Relay Chat". The general description is characteristically concise:

"IRC is a teleconferencing system, which (through the use of the client-server model) is well-suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions."

The traditional prototype invoked is of a one-to-many telephone conversation, establishing a shared information space in real time. IRC is meant to be a two-way communication platform for humans rather than an human-computer-interface and it provides one of the most remarkable cases of a concept being morphed into dramatically new forms in the course of digital implementation. The case is different from the mail system and its re-invention within the bounds of digital networks, since tele-conferencing is an established pre-Internet practice.

No extra disembodiment is involved here, it is, just a matter of different transport layers transmitting the human voice. The surprising impact of IRC is only indirectly linked to digitization. The crucial move is the transposition of voice into writing. This is not even mentioned in the protocol specifications, even though it completely upsets many customary rules of group interaction. It is an impressive example of cultural change via the experimental redeployment of a given practice within a new technological framework.

Group conversation can only succeed if people take turns in talking. There are social and visual cues governing the necessary procedures. Now, if one substitutes "conversation" by "writing", sticking to the rest of the parameters, surprising changes ensue. Participants in global, real-time group writing can very well be active simultaneously. Rather than their voices drowning each other, their sentences appear in linear order on the terminal. Furthermore, no bodily cues are available, not even vocal modulations indicating the beginning and the end of an utterance. At the moment of typing a contribution a group member cannot know what's next to appear on her screen.

No wonder that chat strikes first time users as a chaotic event. "Teleconferencing" just does not capture the phenomenon. The IRC protocol outlines a globally comprehensive electronic board for people to exchange messages in writing simultaneously and with a minimum of access restrictions.

MUDS

Chats, while providing instant global tele-presence, are transitory events, like conversations. A "chat room" comes into existence by fiat, all that is needed is for a user to define its name and it ceases to exist with the last participant "leaving" the chat room. There was, therefore, an early interest in a more stable environment, enabling people to "come back to a given place" and actually customize it by adding some design. One way to do this is to build a server program that does not only switch messages on the network, but in addition administers a database containing extra information and in particular keeping records of participants as well as storing the descriptions of separate accessible "chat room".

Such programs were the technical underpinnings of what was to be called textbased, inter-active virtual worlds. These worlds, in turn, are the underpinning of "virtual communities". Such communities are, indeed, an issue of utmost importance for the understanding of how real life concerns are projected into a telecommunicative network. One basic principle quickly emerged: in order to achieve the desired persistence, you have to draw on common cultural pre-dispositions. It's not sufficient to invite people into the columns of a database. You have to address their imagination.

The contents of those databases were, consequently, elaborate descriptions of "rooms" to change between and to "meet friends". The prevalent cultural pattern among the early participants in this enterprise were fantasy- and role playing games as well as adolescent combat simulations, so most of the resulting "MUD" (Multi User Dungeon) servers offered a rather quixotic brand of "virtual community".

One should not be deceived by the fringe character of those early explorations. As global, digital tele-communication expanded, MUDS where among the first attempts to test and transform given social institutions within the framework of emerging social IT-structures. Among the basic terms that were re-defined in those virtual environments where "talk", "move", "look", "take" and "exit", to name but a few. A considerable amount of popular hype about "virtual space" might profitably be exchanged for a few remarks on the translation between socially shared real life imagination and talk of servers joined to databases.

"Muds Object Oriented" (MOOs) are a refinement of MUDs that introduce the present standard of software development, i.e. object oriented design, into the language used to manipulate the data core. Some such cores are explicitly designed for educational purposes and one of them, whimsically called "enCore" served as a teaching tool in several of my classes since 1999, well before the craze of learning platforms hit the continent.

The Living Internet: MUDs Mudconnect | MUDs and MOOs Online Teaching Tools

---