Shiva Ayyadurai suing TechDirt over Stories Saying He Didn’t

Gathered together in one place, for easy access, an agglomeration of writings and images relevant to the Rapeutation phenomenon.

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 3:25 am

Huffington Post Doubles Down, Has MIT Professor Spread Blatant Falsehoods About Creation Of Email
from the really-now? dept
by Mike Masnick
Wed, Sep 3rd 2014



We already covered the bizarre situation in which one of the biggest names in PR has "teamed up" with the Huffington Post to write an entirely bogus "series" of stories on the "history of email" that is nothing more than a PR campaign for a liar. V.A. Shiva Ayyadurai claims to have invented email. He did not. We went into great detail on this on Tuesday, so you can check out the history there.

Despite my requests to both Huffington Post and Larry Weber (the PR guy who kicked off the "series"), neither has responded and explained if any money is changing hands here. That means either it is, and Huffington Post is violating FTC rules concerning "paid" posts, or Huffington Post just made it clear that it is willing to post pure bullshit without the slightest bit of fact checking. I'm still not sure which is worse.

Instead, it appears that they've gone forward and posted the latest in the series. Incredibly, they've convinced an MIT professor, Deborah Nightingale, to destroy her own credibility by writing a piece that is supposedly "debunking" the "myths" that everyone puts forth in proving that Ayyadurai is simply wrong in claiming to have invented email. Except the "myths" are not myths, and her debunking does not debunk anything. It just repeats the same false claims (using nearly identical language) as Ayyadurai and his friends in their original posts.

Consistency is the orderly treatment of a set of linked elements, and it is a necessary characteristic of polished, highly readable prose. Consistency is either "uniform" or "harmonious," depending on whether a set of linked elements is indivisible or divisible into subsets. From the perspective of text characteristics, we can speak of semantic, syntactic, stylistic, spatial, and mechanical consistency. To deal successfully with consistency problems, technical communicators should establish patterns that are logical, evident, functional, resource efficient, and stable. Because of its importance, the concept of consistency should be more fully recognized. Indeed, consistency should be a component of any comprehensive rhetoric of technical communication.

-- The Concept of Consistency in Writing and Editing, by David K. Farkas, Program in Scientific and Technical Communication, College of Engineering, University of Washington, Seattle

Nightingale cherry picks a few things, presents them in a misleading way, repeats the entirely bogus story about Dave Crocker claiming interoffice email was impossible (which is not at all what he actually said), and then just repeats (almost word for word) Ayyadurai's previously disproven claims. It's clear that the only way they think they can win this debate is to redefine what email is in such a narrow way to pretend that Ayyadurai's specific implementation was the "invention" of email. It's not. It's ridiculous.

Precising Definition: A careful effort to reduce the vagueness of a term by stipulating features not included in its lexical definition.


Here's their definition, according to Nightingale, though more or less repeated word for word by the other posts in the series.

"first full-scale electronic replication of the interoffice mail system consisting of the now-familiar components of email: Inbox, Outbox, Folders, Attachments, Memo, Address Book, Forwarding, Composing, etc.,"

Again, as noted in our post yesterday, nearly all of that was done previously by others (often many years earlier). But Ayyadurai, Weber and Nightingale are pretending that none of that was truly email because it didn't have every single component that Ayyadurai's app had. That's ridiculous. Email is an ever-evolving set of standards. You could just as easily make an equally ridiculous claim that "email" didn't really exist until it also had color highlighting. After all, the offline interoffice mail system had the ability to highlight with colored pens, and email didn't include color highlighting until years later. But, of course, that's ridiculous, because color highlighting doesn't make email.

Email was very much in place long before Ayyadurai's app. It included all the basic concepts of email, including an inbox, folders, to:, from:, subject, cc:, bcc:, etc. Ayyadurai may have written a wonderful new form of electronic messaging, but he didn't "invent" email.

The thing that's amazing here is that Ayyadurai is using one of the oldest trolling tricks in the book, in pretending that everything that he is actually doing is actually being done nefariously against him. Almost everything that he claims people are doing to him are things that he is actually doing himself:

He claims that the attacks are because Raytheon/BBN's entire "identity" is built off of its fake claim to have invented email.

First off, that's not true. Raytheon is a giant multi-billion defense contractor. It doesn't care about who invented email. BBN has a long and well-documented history of a whole bunch of innovations concerning the internet and networked computing. If it didn't invent email (and no one there really claims to have "invented" email anyway -- they say, rightly, that it was a group evolution by a bunch of folks, some at BBN and some elsewhere), its legacy as the core innovators of the internet would still be in place. Instead, the only one whose entire "identity" is built off a fake claim to have invented email is... Ayyadurai. Here's his Twitter page:


His entire Twitter stream is about him claiming to have invented email. Tweet after tweet after tweet are just about those claims.

He has an entire website called "the inventor of email." He's written a book about email, which claims on the front page that he's "the inventor of email":


Oh, and notice the "blurb" on the cover of the book? It's from Larry Weber. Gee...

He claims that others "fabricated a controversy" to deny him his rightful place in history.

The only fabricated controversy is by him. There is no controversy. He didn't invent email. But he sure trades off of the claim that big powerful interests are trying to silence him.

He claims that those of us debunking his bogus claim refused to look at the primary documents.

This is untrue. We went through the documents in detail and explained why they actually debunk Ayyadurai's own claims. Their "smoking gun" is a paper by David Crocker at RAND from December 1977, in which they falsely claim he said that an interoffice email system was impossible. Yet they never point you to the paper. go read it here. Go read the primary documentation and you'll see that not only did Ayyadurai and his friends/colleagues totally take Crocker out of context, they pulled two totally unrelated sentences from different parts of the report, excised from context, to pretend he said something he did not. Read the whole report and you'll actually see that not only were email systems quite common, lots of folks were developing all sorts of components of an electronic interoffice mail system. Crocker's paper is about one such version, but notes that many others are doing the same, and it includes screenshots of messages that clearly look like email today.

He claims that everyone is trying to rewrite history

He and his friends are the only ones doing so. The history is clear. There is no controversy other than the one that he's manufacturing.

What's bizarre is that the Huffington Post is a willing accomplice in perpetuating this myth -- and why the company won't comment on this, and the nature of its relationship with Weber and Ayyadurai. Again, either the Huffington Post is running a sponsored series without disclosing it (in violation of FTC rules) or it has been totally duped. I've heard from some folks suggesting that this is just the "blogging" side of Huffington Post, where there are no real editorial controls, but that doesn't explain HuffPost Live's multiple segments on this issue, including its bizarre interview with Ayyadurai. That is a journalistic endeavor (or purports to be) that appears to have been totally duped. The series still promises one more article, by Ayyadurai himself, and we expect more of the same rewriting of history, using the exact same phraseology. The question is whether or not Huffington Post will recognize that it's being used as part of an effort to drum up a faux controversy over something that is blatantly untrue.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 3:57 am

Part 1 of 3

Framework and Functions of the "MS" Personal Message System: A Report prepared for DEFENSE ADVANCED RESEARCH PROJECTS AGENCY by David H. Crocker December 1977



ARPA ORDER NO.: 189-1 7P10 Information Processing Techniques


December 1977 Framework and Functions of the "MS" Personal Message System


The research described in this report was sponsored by the Defense Advanced Research Projects Agency under Contract No. DAHCl5-73-C-0181.

Reports of The Rand Corporation do not necessarily reflect the opinions or policies of the sponsors of Rand research.

Published by The Rand Corporation

ARPA ORDER NO.: 189-1 7P10 Information Processing Techniques

R-2134-ARPA December 1977

Framework and Functions of the "MS" Personal Message System

David H. Crocker

A Report prepared for


Rand SANTA MONICA, CA. 90406



A coordinated set of programs for minicomputers in the Digital Equipment Corporation PDP-11 series is being developed by The Rand Corporation as part of its research for the Information Processing Techniques Office of the Defense Advanced Research Projects Agency (ARPA). This computer software will enable a user to perform such tasks as text manipulation, "reminder" functions, rule-directed "user agent" functions, and manipulation of electronic mail.

This report describes the design of one such program--the "MS" message system. Early electronic mail systems have existed on the larger computers. MS incorporates and expands upon many of the functions and concepts of such systems within an integrated package, using the Unix operating system, for users of PDP-11 minicomputers.

The report should be of interest to users and designers of computer-based communication network message systems. Familiarity with the Unix operating system, although not critical to an understanding of the text, would be helpful to most readers. This document is not intended to serve as a user's guide. As specific interfaces with human operators are constructed for MS, specific user's guides are being written.


One of the earliest and most popular applications of the ARPANET computer communications network has been the transfer of text messages between people using different computers. This "electronic mail" capability was originally grafted onto existing informal facilities; however, they quickly proved inadequate. A large network greatly expands the base of potential communicators; when coupled with the communication convenience of a message system, there results a considerable expansion to the list of features desired by users. Systems which have responded to these increased user needs have resided on medium- and large-scaled computers.

The Unix operating system, which runs on DEC PDP-11 minicomputer hardware, has not benefited from recent advances in network mail technology. This report describes some of the issues surrounding the design of such technology and specifies a system which transfers it to Unix. In the form specified, MS is intended to be an interim facility, having maximal utility for three to five years. In addition, the system is expected to provide a base for future generations of Unix message systems.

The MS environment consists of several pieces of software to compose, transmit, receive, review, and manipulate messages. Messages reside in file t'folders" and may contain any number of fields, or "components". The user can arbitrarily name, create, and modify these components. In particular, a draft message is provided for composing new mail and modification of old messages is allowed. The user is thereby given a relatively homogeneous and unrestricted environment for manipulating mail, although facilities for data-base management (filing and cataloging) and for personal tailoring of system behavior are relatively primitive.

The specifications in this report differ from the style of most system specifications; normally, either the way the system is to appear at its interface to human users, or else the range of primitive operations and "data objects" available is defined. Although they have more of the flavor of an interface description, the specifications here do not describe the precise way in which users formulate requests. That is, the functions, to be made available to human users, are described; however, the command language for invoking those functions is not. The reason for this idiosyncratic specification style is that several very different command interfaces are being constructed, and it is hoped that specification at this level will simplify the task of implementing them.

A number of features, normally reserved for user interfaces, are provided by the basic MS system; it is intended that these features will facilitate the design of interfaces to adequately respond to psychological aspects of using interactive computer systems and, in particular, that the appearance of the system will conform to typical users' cognitive models of a message-processing environment. This report includes discussion of these issues.


This system description has benefited from the support of a large number of people. Many of the ideas in this document have been freely incorporated from those instantiated in existing systems, mentioned in the Introduction, and from a continuing set of discussions about message systems, which has taken place among more than seventy researchers distributed around the country and using ARPA Network message systems. In particular, Robert Anderson, Carl Sunshine, Stockton Gaines, James Gillogly (all of Rand), Steven Zucker (formerly with Rand), Stephen Kent (a summer Consultant from MIT), David Farber (University of Delaware), John Vittal (Bolt Beranek & Newman), and Kenneth Pogran (MIT) have reviewed and enhanced the original system specifications. William Crosby is the system's primary implementor, with Steven Tepper implementing the network, address, and initial conmand-specification software; both have been diligent at finding inconsistencies in and omissions from the original specifications. Sally Wallace, Grace Carter, and Lynn Anderson of Rand, and Cathy Koerner, formerly with Rand, were tolerant subjects for informal experiments conducted to select function characteristics for the system.  


• Section
o Background
o Framework for Using Message Systems
o An Operational Model
o Scope of Specification and Implementation
o Overview of MS Design
o Message Folders
o Message Components
o Message Creation
o Text Transfer and Structured Text
o Specification of Addresses
o Transmission and Receipt of Messages
o Sequence Specification
o Profile and More Structured Text
• Appendix
o Sample MSG session
o Sample Shell session
o Sample MS session
o File and directory organization in Unix
o Relationship between data in MS
o Groups of messages (M) and components (C)
o Defaults for the Copy function
o Defaults for the Map function



Time-shared computers typically have a system which allows their users to pass informal messages among themselves. As long as a computer is not connected to other computers, its community of users remains relatively small and geographically local, and its message system tends to remain relatively simple and used only for terse, infrequent communications.

The advent of the ARPA computer communications network (ARPANET) (Roberts & Wessler, 1970; Crocker, Heafner, Metcalfe & Postel, 1972) has dramatically changed such usage patterns. Message systems, coupled with a large network, result in a substantial pool of potential users who can obtain rapid delivery of messages (relative to the U.S. Postal Service) and an asynchronous interaction style which allows composition, transmission, receipt, and perusal at the convenience of each participant. The telephone allows more rapid delivery of information and an interaction style which often leads to greater effective bandwidth, but it requires participants to schedule contacts. It is therefore not surprising that a computer-based message system can fill an important niche in human communication and has become extremely popular with its community of users, replacing a substantial portion of normal mail and telephone activity.

Initially, the network communication capability was simply grafted onto existing intra-machine message facilities; however, growth in use of the facilities has led to considerable expansion of the list of features desired by users (Uhlig, 1977). For an introduction to the context and economics of electronic mail, see Vezza (1975), Vezza and Broos (1976), and Panko (1976).

The first integrated ARPANET-based software to gain wide acceptance for this type of "automated office" application was the BANANARD system (Yonke, 1975) and its successor, MSG (Vittal, 1975), written at U.S.C.'s Information Sciences Institute (ISI) for the Tenex operating system (Bobrow, Burchfiel, Murphy & Tomlinson, 1971; Myer, Barnaby & Plummer, 1971) which runs on Digital Equipment Corporation (DEC) PDP-10 hardware. MSG provides basic capabilities for creating, sending, viewing, storing, answering, and forwarding messages; its database management and message-revision functions are rather primitive. See Fig. 1 for an annotated scenario of a typical session with MSG.

Over the past several years, other message-system development efforts have begun; all attempt to provide a quantum improvement to the level of capabilities offered in MSG. Among development efforts, Stanford Research Institute's Augmentation Research Center (Engelbart, 1972), IS1 (Tugender & Oestreicher, 1975), Bolt Beranek and Newman (Myer & Mooers, 1976), and MIT's Dynamic Modeling Systems project (Broos, Black & Vezza, 1975) have been most noteworthy in the ARPA community.


User first types the character after "<-"; MSG prints rest of word; may be repeated for qualifiers, such as "all messages". User's text is in boldface; comments are in the right column.

MSG -- version of 1 April 1976

The Unix time-sharing system (Ritchie & Thompson, 1974), which runs on DEC PDP-11 minicomputer hardware, has not benefited from these later developments and has had only an informally-developed system with capabilities at about the level of BANANARD. Rand has undertaken the design and development of a more complete and integrated message system, transferring proven message-system technology onto a minicomputer. This system, called MS (pronounced "mizzt'), was to provide capabilities at least equivalent to those of the MSG system and it has been designed to evolve to the level of state-of-the-art systems. The initial version of MS was to have a projected life-span of three to five years.

MS became operational at Rand at the end of 1976 and received limited distribution to other ARPA-project Unix machines by summer 1977. The system appears to provide a better framework for growth than was expected. It has been continually modified, as experience has uncovered deficiencies in the original design; no major problems have been encountered in effecting these changes.

Due to the evolutionary nature of MS, this document cannot be a definitive specification of all of the system's features. Therefore, a portion of the text is devoted to extensive explanation of the perspective with which design decisions are being made. Some of the perspective is the result of constructing MS after the ISI, BBN, MIT and SRI systems and reflects various of their characteristics. Since a message system is a complex environment, it is not possible to list those reflections accurately or completely. Attention also has been given to the importance of psychological and environmental factors in the use of interactive computer systems. While such social issues can be characterized globally, and the resulting basic design decisions can be discussed, it is not possible to explain all ways in which MS has been affected by these considerations.


As suggested by the sample MSG session in Fig. 1, messages on the ARPANET can be characterized as "memos". They are relatively structured and, since they must be represented in a single coding system (the ASCII character set), can have only one typeface, size, and color -- though it should be noted that the system or terminal used by the receiver of a message can (at least potentially) choose the face, size and color. At present, it is not possible to send drawings, facsimile, speech, or structured text. Such restrictions make ARPANET mail appropriate for most intra-organization and some interorganization communications. The ARPANET message environment is currently biased towards use as an informal communication mechanism but is being adapted for more formal activity. In normal offices, this combination represents a substantial portion of paper-based communication and can be expected to result in a considerable amount of computer-based mail-processing. Experience with ARPANET message activity by managers bears out this expectation. Even with somewhat restricted machinery, such as terminals which print at only thirty characters a second, it is not uncommon for a user to process twenty to fifty messages a day.

It appears that most users of computer message systems are extremely intolerant of idiosyncratic system behavior. They wish to use the system to communicate with other humans and do not want the computer--the communication medium--to intrude on that process. Curiously, this fact tends to apply even to those with a high degree of sophistication about computing.

This phenomenon also occurs with users of certain other tools, such as text editors. These systems augment rather basic human communication activities and require a kind of "intimate interaction," which can be characterized as sustained request/response sequences with most transactions involving conceptually simple actions by the computer and requiring between one-half and two seconds to complete. (Carbornell, Elkind & Nickerson, 1968). Much of this activity is characterized as requiring "routine cognitive skill" (Card, Moran & Newell, 1976).

Since the system is to be used for communication which is exemplified in older and heavily-exercised technology, it is assumed that users have an extensive conceptual model of the communication domain. It is further assumed that a system which performs in ways which deviate from that model will be viewed as "idiosyncratic" and impeding the efforts of the user. Problems occurring during this sort of interaction can be expected to be as irritating as having a pen which leaks or a typewriter with keys that jam. Therefore, a major design goal for MS is to provide an integrated set of necessary and sufficient functions which conform to the target user's cognitive model of a regular office-memo system. At this stage, no attempt is being made to emulate a full-scale inter-organization mail system.


The scope of the MS project has not permitted empirical verification of the majority of its assumptions about the presence and characteristics of users' conceptual models for message activity. The project has had to rely upon the intuitive appeal of its assumptions and the degree to which other systems seem to succeed or fail in terms of their conformance and deviation from that model. Work by Heafner (1976), Heafner and Miller (1976), and others suggests that the model does exist and can be characterized. Work by Brown and Klerer (1975), Kennedy (1975), Walther, (1973) and Carlisle (1974) suggests that the degree to which a system conforms to users' expectations and abilities will have a significant effect upon their use of that system.

Because the system processes structured "memos", the basic unit of manipulation is taken to be the "component1'. A hierarchy is formed by having memos (or "messages") consist of collections of particular components, and "folders" as collections of particular messages. Messages have some common components, such as "To" , "From", and "cc" , but individual messages may have additional components with unique names. In addition, common names vary between contexts, such as the difference between business and military terminology. MS attempts to give users complete control over the naming and accessing of components.

A message assumes an identity as soon as any of its text is created. Over the life of a message, various actions may be performed on it. Some of these actions occur more commonly at certain phases than at others; however, this generally does not mean that these actions are prohibited during other phases. For example, a message is often revised before it is sent and rarely revised afterwards; but some revisions may occur, as when recipients make notations in its margins or when one recipient is part of a message "coordination" process and charged with passing a revised version of the message onto others.  

Within an office environment, messages typically arrive at a person's "inbox", are viewed and perhaps acted upon, and are then filed into an appropriate folder which contains related messages. Later, the person may wish to take other actions relating to the material in the folder. All of this activity occurs on the person's desk. Several folders may be open at one time.

Two of the more common actions people take are responding to a message and forwarding a copy of it to others. In both cases, material in the original message determines portions of the new message. For responses, the title ("Subject") and the names of the originator and recipients are used; and for forwarded messages, only the name(s) of new recipient(s) must be added. Another common action is the creation of a new message for a third party.

When a comparison is made between the way these actions are normally performed in an office and the way they are performed using some existing computer-based message systems, several issues of operational styles surface:

1. Messages which are being created ("draft" messages) must be treated in fundamentally the same way as messages which have already been sent (and received);

2. A message may have "draft" status for an extended period of time, rather than being sent immediately after creation; and

3. Several draft messages may exist at one time.

The first point implies a more general issue: humans often do not make distinctions in the same ways as computers. For efficiency, a computer might handle a draft message differently than it handles "old" messages or that it might copy some kinds of text differently than other kinds. Humans, however, are generally not conscious of the conceptual distinctions which lead to these differences in handling. Imposing such distinctions upon users is another case in which the system will probably be classed as idiosyncratic and counterproductive.

The final way in which MS attempts to conform to users' expectations is in the vocabulary used to describe and invoke its processing. Concern for this level of detail has been questioned, on the theory that humans are quite good at learning new terms and, in fact, they are not consistent in their own use of vocabulary. That is, there probably does not exist a set of terms which is consistent among users and, even if there is, using that set rather than another will probably not greatly affect a user's performance with, or attitude towards, a message system.

In the belief that computer-oriented users and designers cannot be used as references for testing the presence and nature of such vocabulary in the potential user population, several informal experiments were conducted. Subjects were secretaries who had little or no experience using computers. In each case, relatively neutral language was used to explain a typical office situation which required use of a single word for referencing a particular object or action. The subject was then asked what word or symbol was most appropriate in that situation. In most cases, subjects immediately had a term they thought best and the terms were relatively consistent among subjects.

For example, a message being created is called a "draft"; the structured part of a memo is called the "headers"; and placing a message into a folder is called "filing". While such terms may seem trivially obvious, many message systems use terms which do not even approximate those offered by subjects. In fact, some systems use terms which have significantly different implications. For example, to "put" a message somewhere means that the original message changes location; however in some systems, the word is often used to cause an action which only places a copy of the message somewhere. It should be noted that, as Heafner (1976) has demonstrated, acquiring this sort of empirical data, in a methodologically valid manner, is relatively easy and inexpensive.

It is difficult to substantiate the claim that use of the most predictable vocabulary actually affects users' performance and attitudes. Except for that cited earlier, little research has been done to test the idea. It is noteworthy, however, that subjects in the informal experiment often reacted quite strongly when queried for certain vocabulary; their choices were so well-ingrained that they could not believe there was any question about their selection. Telling them of the terms used by some computer systems often evoked laughter. It seems to the author that such a reaction establishes a mental set which is quite likely to deter users from a system and cause them confusion when dealing with it. This is particularly critical during their initial use, since they will often already have enough difficulty becoming familiar with computer-related conventions and concepts that cannot be avoided.


This document, and the style of the resulting system implementation it specifies, is a bit unusual and deserves some explanation. Most system specifications address either the human interface or the internal design -- how the system appears to human users or what data structures and function primitives are to exist. The specification for MS is at neither level, although it has more of the flavor of an interface description. In particular, the document may be viewed as specifying the human interface, minus the command language. That is, the functions, to be made available to human users, are described; but the precise way in which users formulate requests to MS is not.

The reason for this idiosyncratic specification style is that several very different command interfaces are being constructed and it is hoped that specifying the system at this level will assist interface builders in realizing and accommodating some of the user issues described above. (The concern for proper vocabulary, therefore, is more representative of a lobbying effort than of a guarantee for what is to be provided in the command interfaces.) Experience to date suggests that the construction of interfaces is, in fact, simplified.

Three general-purpose interfaces have already been constructed. The first, described in Appendix B, is intended to be similar to the basic syntax of the Unix Shell (Thompson & Ritchie, 1975), which is the program that users employ to gain access to most of Unix's capabilities. (See Fig. 2 for a sample Shell session.) This choice was made because MS is intended for use on other Unices in other environments, and having a familiar command specification style was deemed more important than providing an especially "friendly" interface. Fig. 3 shows a sample session, using the Shell-syntax interface; and Appendix D contains an extended example of using this interface. The second interface constructed emulates the Unix "mail" command and is primarily intended for use by programs to send mail to users. The third interface emulates MSG, since MSG is a de facto standard on the ARPANET, with behaviors that are already familiar to many people.

In general, it is expected that users will be provided with a single command interface to the full message system, rather than be forced to deal with two or more different systems--for example, one program for creating and sending messages and another for reading and filing them. This should not preclude additional interfaces to subsets of the system, as would be appropriate if the user only wanted to send a message quickly. However, such programs should be strict subsets of the full system.

The level of the MS project effort has also had a major effect upon the system's design. To construct a fully-detailed and monolithic message processing environment requires a much larger effort than has been possible with MS. In addition, the fact that the system is intended for use in various organizational contexts and by users of differing expertise makes it almost impossible to build a system which responds to users' needs. Consequently, important segments of a full message environment have received little or no attention and decisions have been made with the expectation that other Unix capabilities will be used to augment MS. For example, MS has fairly primitive data-base management (i.e., filing and cataloging) facilities and message folders have been implemented in a way which allows them to be modified by programs, such as text editors, which access them directly, rather than through the message system.  

Fig. 2-Sample Shell Session

Fig. 3-Sample MS session


The original mail system on Unix was judged sufficiently primitive that compatibility with it was not attempted. For example, the structuring of folders that contain messages differs. Current Unix software which utilizes parts of the Unix mail facility therefore needs to be modified to use the new and improved product. Systems which merely create and then send messages need not be modified, since the mail-command emulator interface allows creation of mail in exactly the same way as is done by the old Unix mail system.

The MS message environment consists of several pieces of software to compose, transmit, receive, review, and manipulate messages and to tailor the message environment. In addition, there are file folders [*] which contain messages. Messages, in turn, contain any number of components. In accordance with the user issues discussed earlier, an effort has been made to make the system as homogeneous as possible. For example, messages which are being created by the user and messages which have been received are equally accessible. Most system functions have a number of options available. To allow users to indicate which option settings they typically wish to employ, a profile is planned for each user.

Users will normally deal directly only with the Shell-invocable software (see Fig. 2) and with the folders which contain messages. The process of Composing messages entails placement of text into the various components of a draft message. For example, names and addresses go into the "To" and "cc" components and the text of the message goes into the body. his ma^ be done repeatedly, allowing the user to employ a text editor to modify individual components. Transmission is an automatic process which packages the draft message to conform with ARPANET mail format standards (Pogran, Vittal, Crocker & Henderson, 1977) and delivers it into the mailboxes of all the indicated addressees. When receiving messages, the user may selectively -Show them at the computer terminal. Further manipulation of mail can involve Forwarding copies to additional recipients, Replying to its authors, Filing for later reference, Listing copies on a printer and/or Discarding (into the system's "wastebasket").  

The messages in a folder are like a stack of messages in a normal office file folder; they are ordered and may be referenced by their index number (i-e., position in the folder). Any number of messages may be in a folder. They contain some number of components, most of which may consist of arbitrary strings of text. In some situations, batches of messages may be referenced; special labels are allowed for specifying them. At any given moment, the system has a current folder and a current message which are under scrutiny. (The standard folder is the inbox). Having them keeps the user from being forced to specify a folder and message index for every function. Contrary to most other message systems, most MS functions can operate on any component of any message in any folder, without requiring the user to respecify the current message or folder. Some functions cause the index of the current message to be changed; these are indicated in the functions descriptions, in Section 111. When the user invokes MS, the current message is set to be just before the first recent message, so that the user may conveniently sequence through recently-arrived mail, or to the first message in the folder if there is no new mail.  

When a user issues a Shell command to start the message system, the standard action will typically be to Open a folder, where this folder will usually be the user's primary folder, the inbox. (See Fig. 3.1 This folder is structured like any other file which contains mail, except that new mail is placed there by the Unix mail delivery system. Current specifications call for mail to be delivered only to this folder; however, a later version may allow incoming mail to be diverted automatically to other folders, as might be appropriate to activities such as teleconferencing.

Modifications to processed messages (i-e., mail which has already been sent or received by the user) are allowed; however, in some cases, such modifications may cause the system to take note. Such exception-taking is intended only as a safety feature, as described below.  

The system maintains a draft message, in its own folder. A message with "draft" status has not yet been Sent and is subject to more modification than other messages and therefore is not subject to normal access checking by functions. Current specifications allow only one draft message at a time; however there appear to be no problems in eventually permitting an arbitrary number of them. When a message is sent, a unique message-id, a timestamp, and the name of the sender are affixed if necessary.

The user can arbitrarily name, create and modify components. 'l-To" , W-ee" , and "Subject" are common components, but others are possible. For example, MS has a simple reporting mechanism, which allows users to send comments and complaints to the MS support staff. It automatically fills out the destination addresses and then prompts the user for the report. It also creates a component called "MS-Version" which allows the support staff to know what version of the system the user had. Such a component will not occur elsewhere, and users are given equally unlimited creative license to formulate their own component names.

Note that no program need know the names of all possible components. To facilitate user specification and manipulation, command interfaces typically maintain a list of the common component names, and the basic system is familiar with the required "Sender", "Message-Id", "Timestamp", and "To" components, as well as "cc" , "fCC" (file carbon copy), and "Subject", for the draft. Contents of these are verified or created by the system. With the exception of the first three of these components, all components of all messages may be modified, as described above.

Finally, any component may be passed to a program for manipulation. Formatting and typographical-error detection are two system-known programs. Others may be added, such as comparison of two versions of a message.



Unix organizes stored data files in a hierarchical fashion. Indexes to files and other subordinate indexes are called directories. The primary directory usually may be thought of as a filing cabinet. In a typical case, the secondary directories may be thought of as the drawers in the cabinet, and they may contain data files. Other organizational styles are possible and may become quite complex, as demonstrated by example C in Fig. 4 The simplest organization is to have only one directory and keep all files in it. Whatever the case, the user begins each session with Unix "looking at" an initial directory. If this directory contains another directory, called mail, then various standard MS files or folders are placed there. Otherwise, these folders are placed directly into the initial directory. Currently, standard folders are inbox, draft, and msreport and backup folders for draft and msreport; msreport is used by the Report function and will not be necessary when MS allows multiple draft messages.

MS folders actually consist of two Unix files. One is a clear, readable text file, organized in a fashion conforming to the ARPANET standard syntax (Pogran, et al. 1977). The second is a parallel file containing structure, status, and history information. Simple strings of special characters are used to separate messages in the "cleartext" file. If a message's format is violated, recovery is then quite simple, and the structural information in the parallel file is generally redundant and easily reconstructed. The structural information allows the system to manipulate messages and components efficiently.

This approach is in accordance with the concern for integrating MS into the general Unix environment and for allowing the user to have unrestricted access to messages, through other Unix word-processing tools which are already familiar, such as text editors and Shell commands. Separating structural information from the data also makes it convenient to have multiple "perspectives" (or indexes) to the data. The parallel file is normally hidden from the user so that he must only deal consciously with "real" message files.

Most text-transferring functions preserve the text in its structured, processable form. The List, Scan, and Show functions are notable exceptions and do not move the information in a form compatible with further processing as a message, since they completely reorganize the text into a single string. The Copy and Map functions can also perform this alteration, under certain circumstances.

As more systems come to manipulate message files automatically, the environment will have to distinguish between activity by humans and activity by their software agents. An example of this problem occurs when another computer program checks the inbox for certain types of mail, but the human still wants to be notified of new mail. Simply checking the length of the inbox file, or when it was last read, will therefore not provide an accurate indication of when the human last looked at the file. MS provides a solution to part of the problem: a folder may be opened with a passive status, so that no ' permanent actions can be performed on the folder. This capability allows automata to peruse and copy the contents of a folder, without leaving a trace of their activity in it.

A. Simple directory, with no sub-directories

B. Directory with 1 level of sub-directories (like cabinet with drawers )

C. Complex directory structure, with several levels Fig. 4-Examples of file and directory


As mentioned in the Introduction, a list of common component names is generally maintained and is used for defaults with certain functions; but such defaulting is only for convenience. At all times, MS allows modification to this list by the user, either through the Profile or at the time of creating specific components.

One of the pieces of information the system keeps about known component names is whether they are used to specify addresses. Including such a component in a message causes the message to be sent to those listed in the component. The user is able to control whether the contents of that component are included in the copy of the message sent to:

1. All recipients of the message; or

2. Other recipients named in that list; or

3. Only the author(s) copy.

This curious feature is derived from the concept of the blind carbon copy; the decision to provide so general a facility is due to a discussion with Stephen Crocker of ISI, during which the variety of distribution conventions followed by different organizations became evident. Rather than impose a single style of distributing information about who receives a message, MS lets individual users decide. The Profile allows users to alter which components are candidates for containing addresses (to be interpreted by the mail-sending process) and to alter the inclusion settings described above. In the case of the third option, a recipient's copy will show only his/her name in the component.

A more general facility would consider components to have a "data-type", with various attributes. For example, the above case would be of data-type "address" with a "distribution" attribute.

The system also allows specification of component equivalences. That is, a component name may be equivalent to some "generic1' name, as in the case of "Action-to" being equivalent to "To1' . This facility is necessary due to the amount of variety found on the ARPANET, in the (justifiable) absence of complete naming standards. The author favors this variety, since it is the only significant control the sender can have on message appearance and the labels often have differential import, as with military versus business memo terminology.


Normally, the draft message always exists, and is in a standard message folder so that creating new message text, modifying it, and then sending it when ready can be done in a fairly natural and user-controllable manner. The Compose, Ned, @, Correct, and Format functions, in particular, are provided to facilitate the process, but the user may easily follow different creation paths with other tools.

As described earlier, three pieces of information (and possibly more, later) are not completely controllable by the user: message creator name, message transmission date, and message identification tag. The default is for the system to place the first two pieces of information into the From and Date components, respectively. If the user explicitly manipulates one, then its backup component (Sender or Timestamp) is created. Neither the backup nor message-tag components may be modified by the user.

While typing text into a component, users often need to be able to indicate places for other text to be inserted from files such as those containing documents. Although such an action is not handled by the basic system, it should be a feature in most interfaces. A more general capability would allow the user also to include text from other components and from the output of programs.


By definition, the core of a mail system is its ability to transfer text. When done between people or systems, this is message transmission. Individuals spend most of their message processing time transferring text within their own environment ("office" or "desk"). It is important, therefore, that this type of "local" text transferring be easy to perform. MS attempts to provide reasonable access to the functions that are most frequently useful for transferring text in messages which are on a "desk". There is little experience with unusual text transferring capabilities, such as "cut and paste" editing, which might be desired by users of a computer-based mail system; however, discussions and experience on the ARPANET have led to the conclusion that the range of desired functions is large and as soon as users can conceptualize a function, they want it very much.

A computer-based message system, like MS, must be able to transfer fundamentally different types of text "objects", such as components, document files, and user input. This makes it very difficult to characterize a conceptual space for a single, "generic" transfer function; however MS attempts the characterization with its Map function. The function represents another attempt to direct interface builders, so that appropriate consideration will be given to the psychological aspects of system behavior. This section analyzes the transfer domain and describes its parameters, as used by Map. Actual behaviors are described in Section 111, "Function Definitions."

The Map function represents an extreme attempt to provide the user with as integrated an environment as possible. It assumes that humans, in fact, are not aware of a distinction between transfers and , therefore do not want to be forced to make one. Experience with early versions of MS suggests that the Map function may be overly ambitious. The Add and Copy functions are provided to facilitate a subset of the transfer functions which are performed frequently. The File function also performs a transfer function; additionally it Discards the source version.

A distinction must be made between human behavior which uses the generic transfer function and the analysis which attempts to understand it; this is similar to the distinction between "performance" and "competence" which linguists make. The former appears to be common enough, normally, to be performed subconsciously, as indicated by the lack of "awareness" cited above; however, gaining an intellectual understanding of the process appears to be quite difficult.

Due to the difficulties in understanding the generic function, it may be useful to review the domain of activity. The MS message system interacts with a number of related entities. The basic computer entity, which can be manipulated, is a string of text, usually acquired from the user's terminal or from a data file which is not part of the message system. Within the message system, these strings of text are placed into various components of messages. A collection of these components may constitute a message and a collection of messages may constitute a folder. Messages and folders are said to be "structured" because they are made of discrete sub-wits. Fig. 5 shows the relationship between these entities.

Map is able to embody the several types of copying by using information about the source and destination to decide what kind of transfer to make. Because of the structural relationship between text entities, all text transferring may be viewed relative to components.

Four parameters of transferring are discernible:

1. Merging to a string: if more than one component provides source text, then whether to preserve their structural integrity, versus merging their contents into a single sequential string of text, e-g., a single component;

2. Merging to a message: if more than one message provides source text, then whether to preserve the exact structural relationships between the messages, versus mapping them into a single structure;

3. Naming: if the source is a component, then whether to preface the component's text with the component's name; and

4. Addition/Creation: whether the source is to be added to an existing structure, versus having it added to a . new one.

Fig. 5 -- Relationship between data in MS

The second alternative of the first parameter will cause transformation from internal message-system structure into clear text. The second alternative of the second parameter causes several messages to be merged into one. When the destination is merely sequential (clear) text, the third parameter determines whether the text will be "labelled" with the name of its originating component (e.g., "From", "Subject" or "To"). The fourth parameter primarily distinguishes between adding messages to a file and adding components to an existing message. Having text "added to an existing structure" can involve adding a message to an existing folder, adding components to an existing message, or adding text to the end of an existing component. In the first two cases, some new structure is also created, of course, but the focus is upon the act of adding.

If, at this point, it seems questionable that this degree of attention to such complexities is really necessary, it is worth remembering that if a person wishing to use one of these permutations does not find it available, s/he will curse the system designer for lack of foresight.

Some examples of the transfers which users are likely to want to perform, may help clarify the situation. Note that all text is transferred from a source and is appended to the end of destination(2) (components or folders), if they already exist:

1. The typical action of adding text, from a file or the terminal, to one or more components;

2. Merging the contents of existing components into a sequential string and then copying it into one or more components, as would be done when forwarding a message, by copying it into the body of a new message, or printing a message on a lineprinter;  

3. Copying the contents of existing components into components of the same name, in another message of the current folder; this is a kind of "forms" processing;

4. Copying one or more messages to the end of a folder, that is, filing mail for future reference.

5. Copying one or more messages to the end of a sequential string (either a component or a document file), the logical next step, after performing step 2, above;

6. Merging components of several messages into a single message and then converting to a sequential format, as a formalized combination of steps 2 and 5.



*Official names of MS functions begin with a capital letter and are underscored whenever used in this document; other official terminology is underscored when introduced. Names of message components are in quotation marks.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 3:58 am

Part 2 of 3


Experience with processing mail on the ARPANET has pointed up a number of issues pertaining to the specification of addresses. The network standard (Pogran et al., 1977) attempts to provide an adequate base for responding to the most noticeable of these. While some of them may seem trivial, they involve features and behaviors which commonly are not present in ARPANET message systems. In particular, it has been noticed that:

1. People's names are not the same as their addresses; several people may share the same inbox (address); one person may have several inboxes; and programs may wish to display a name without its associated address;

2. Mailing lists can get quite long and there needs to be a mechanism for using "named" lists;

3. To allow recipients to respond, a message often needs to carry all of its mailing list with it;

4. It is often useful to put standard lists into online files, rather than repeatedly to include their contents in messages;

5. It would be very useful to be able to send mail to folders other than a person's inbox, such as in the case of teleconferencing in which messages could automatically be grouped together, allowing the persons to peruse only conference messages.

In MS, address lists can contain the following kinds of information:

List: Mailbox at Host, Person [Mailbox at Host], at Host, Mailbox, > filename, < filename ...

Where :

List is the optional name of the mailing list;

Mailbox is an online reference name (usually the name of the recipient's signon directory;

at Host gives the name of the host computer on the ARPANET containing the Mailbox;  

Person is the person's name;

filename is the name of a file, within the user's access space;

> indicates that a copy of the message is to be placed in the named file; and

< indicates that the contents of the named file are to be used as an address list.

Naming the list allows a program to show only the name and not burden the user with seeing all of the names on the list. "Mailbox at Host" is the standard form of an address, and the recipient's name may , be added as indicated. Referencing a computer, without a mailbox, indicates that following Mailbox references are on that computer, unless otherwise indicated.  

To the extent possible during specification, addresses are checked for correctness, as soon as they are specified. For local mail, the verification is complete; however for network mail, only the name of the destination host computer can be checked. Mail which is local to the user's computer is sent through the local transmission mechanism, to avoid network transmission overhead.

It is often convenient to have a pseudonym for a person or group of people. For example, "rha" is easier to type than "anderson" and "ms-users" is easier to remember than is a list of twenty (or fifty) different people. MS provides a mechanism for using these aliases.

In MS, such aliases may be included in incoming and outgoing mail as if they were local names. When the system needs to use an address, an alias is simply replaced by a string of text and the resulting specification is treated exactly as if it was the original text. To utilize aliases on outgoing mail, MS first checks the aliases defined by users, in their Profile. If the alias is not there, MS then checks the Unix-wide alias files. If necessary, the list of known local users is then checked. This scheme allows maximal power for user-tailoring of names. For incoming mail, the search of the personal alias information is omitted. Also in outgoing mail having an alias from a personal list, the text that is shown in the message is of the text which replaces the alias. This is done so that, on other systems, legal addresses can be formed by programs that automatically generate addresses, such as is described for the Reply function in MS.

A message may contain several address lists, which can be viewed as defining different "communities". A person may be a member of more than one of these communities and may therefore appear on more than one mailing list. In order to allow independent manipulation of these lists, the person's name must be retained on each of them; however, MS will only deliver one copy of a particular message to the person. [*]


All mail--both local and network--is sent and received through a special "post office" (a program in the sender's and receiver's host computer) which delivers mail to the user's primary mailbox (inbox) and may update any associated file structure information.

A feature is provided which periodically checks for recently-arrived mail in the user's inbox. Recent mail is defined as not having been accessed by the human (because they have not yet invoked or utilized the message system, since the mail arrived). The Shell will automatically check for new mail when the user returns to command level (i.e., where the "%" is typed in Fig. Z), after a fixed interval ' since the last check. Contrary to some current implementations elsewhere on the ARPANET, this notification does not blindly recur until the user accesses the messages; one or two notices is enough. If the user's Profile allows, the notification also includes a Scan listing (see "Function Descriptions") of the new message(s).


Within a folder, messages can be referenced by their index number (which indicates their position in the file) and a collection of messages can be referenced at one time, by using commas and dashes as connectors. They have the obvious meaning, so that the specification "1,7-9,Zl-2,100>99" refers to messages one, seven, eight, nine, twenty-one, twenty-two, one hundred, and ninety-nine. The angle-bracket is like dash, except that it indicates that the sub-list is in descending order.

Also, name combinations can be used to reference a particular group of components and/or one or a batch of messages. The system will recognize a number of keywords as pre-defined sequences. Fig. 6 indicates the terms that are currently available. Current specifications allow additive combinations, so that "recent, 10-15, last" will include all recent messages, the tenth through fifteenth messages in the folder, as well as the last message in it. Redundant references are not removed, so that if message fifteen is also the last message, it will occur twice. Full Boolean specification capabilities are not provided but are intended for a future version of the system.


This specification provides only minimal capabilities for the tailoring of MS' performance. In general, the user is able to override (Profile-set) defaults for individual executions of functions. The entire topic of individually tailorable settings is an open research question, so no attempt has been made to define an overly-sophisticated facility.

At the time of this writing, no portion of the Profile has yet been implemented. As experience developing the existing system has emphatically shown, it is highly likely that the actual form of the Profile will differ, in significant ways, from the specification in this document. In addition, discussions are underway about general "user model" features to be employed by the variety of personal computing software being developed at Rand. It is intended that the MS Profile facility will be fully integrated into this more general user-tailoring system.

Fig. 6: Groups of messages (M) and components (C)

For the most part, the MS Profile facility uses the approach taken by the Hermes system, developed at BBN (Myer & Mooers, 1976), which has a relatively unorganized and large set of "switches" which can assume particular settings. A major difference is that the interface to the Profile is, itself, a series of messages, maintained in a separate folder. That is, the user alters Profile settings in exactly the same way as components of messages are altered. For the Profile "messages", a component name indicates the name of a Profile switch, and the contents of that component contain its setting. The user therefore does not need to learn any new concepts or interaction styles to be able to manipulate the Profile; and as a side benefit, the Profile settings can be shared with other users and other machines by the normal process of sending messages via the MS system. It also appears that a "message" may provide an excellent conceptual framework for coding structured information, when dealing with typical users.

Evidence from some research on memory behavior suggests that humans have short-term memory difficulty in processing "structured" information with which they are unfamiliar (e.g., Yntema & Meuser, 1960; 1962; Yntema, 1963; Yntema & Schulman, 1967). This type of information is organized into a hierarchy, or "outline" form. For example, a meal consists of several dishes. The category of dish (e.g., vegetable or entree) is one "level" in the structure while the actual dish for a particular meal (e.g., spinach or chicken) represents the "value1' for that category. This defines a two-level structure, which can be extended to three levels if different meals are distinguished (i.e., meal, dish category, actual dish).

At issue is not the general ability of a person to deal with structured information, which is well documented, but rather to correctly and facilely process such information in real-time, when that information is unfamiliar to the person. The task seems to require rapid and conscious manipulation of the full information structure. Such performance requirements are generally understood to involve a mechanism known as "short-term memory," which is usually unable to hold more than approximately seven items of information at any one time (Miller, 1956). To circumvent this limit, people "chunk" information into sub-units, thereby defining the type of "outline" form described above. When the information is familiar to a person, knowledge about its structure is already stored into the infinite-capacity "long-term memory," so that s/he tends to have little difficulty in accessing arbitrary information in the structure. However with unfamiliar information, excessive hierarchization appears to overload humans with the details of the structure itself. An example of the difficulty is the number of preceding conversational contexts people can easily remember when they are repeatedly interrupted. People often are unable to remember what was being discussed only one context before the current one.

For the purposes of defining Profile switches, a three-level structure, often described as consisting of objects, attributes, and their values--embodied in MS as messages, components, and their , contents--provides a reasonable compromise between the competing constraints. In addition, the concept of a message, with components, is already familiar to people and will become more familiar as they use message systems; so they should not need to learn any new concepts to manipulate a Profile which is organized as a set of messages. Furthermore, the message system can provide a familiar and uniform interface to the Profile information, although particular software may want to have specially-tailored interfaction with it. Since folders are regular Unix files, such software need not go through the message system to access Profile information.

The following is a list of the features which are being provided; the major groupings (in capital letters) are according to the "messages" the user manipulates and the subordinate labels are the component names for the switches. The most common options for a switch are "yes", "no", or "ask". For the last alternative, the system each time asks the user if the option is to be performed each time possible; a few of these types of switches can only be yes or no.


Whether to be notified of new mail; [yes/no].

Should notification include a Scan display; [yes/no].

Name to be used in the "From" component of messages created by the user; the exact text of this field is used as the signature.

These are intended to allow the user to tailor how the three functions create messages. In particular, what components to prompt for, what default fill-in text to place in components, whether to copy responses to other primary recipients, secondary recipients, and/or a personal file, and whether to provide feedback before sending a message. It is not yet clear how to have the user specify preferences. One thought is to use the RITA system (Anderson and Gillogly, 1976a; 1976b) developed at Rand, which is already intended for the construction of computer "agents" to act in the user's behalf.

Whether always to format the body component of the draft, by filling and possibly justifying lines within paragraphs, as if the "Format" function had been invoked; [yes/no/ask].


Indicates equivalences between components, such as To and Action-to; a series of lists are used to indicate the equivalences. The lists are separated by semicolons or periods. For example: "To", "Action-to", "For"; "cc" , "Secondary", "Info".

Names of components to be treated as address lists; and which address component lists are to be shown in messages to all recipients, members of the same list, or not shown at all. Each component name is followed by the keyword "everyone", "members", or "authors," to indicate whether the text of that list is to appear in copies of the message sent to everyone, only other members of the address list, or only author(s) and the individual recipients respectively.

Addressee aliases used during message creation. The name of a component contains the name to be typed by the user and the rest of the component contains the text that is to replace it. These aliases are only a typing convenience for individual users; the system-wide alias list, however, extends the number of "public" names.

Copy-display :
Show-display :
The same use as for Compose-, Reply-, and Forward-contents, except that this controls the display, rather than acquisition of text for the indicated function; may also be viewed as "filtering out" parts of messages.

Whether the system is to print out the expansion of personal aliases, at the time of their specification; [yes/no/ask].

Standard option settings to be used for individual commands. The name of a component is the name of the command and its contents are the standard settings. For example:

Scan: recent
List: -paginate -separate > listing-file
Format: -justify

mean that normally, the Scan function shows all recent messages; the List function paginates it output, starting each new message on a new page and places the listing in text file "listing-file"; and the the Format functional will normally right-justify text.


For a summary of functions, see Appendix A.

The following is not a description of what is actually typed by the user, as there are several different human interfaces which are being constructed. The descriptions which follow are of the functions which will be available to users and of the vocabulary to be used in the command interface which approximately conforms to the Shell's syntax--see Appendix D for a description of that interface. The vocabulary is also believed to be appropriate for other interfaces.

These notational conventions are used for the following specifications:

(component) = > a single message component;
(components) = > a sequence of message components;
(draft) = > the draft message;
(file) = > a file name;
(msg) = > a single message;
(msgs = > a sequence of messages;
( _) = > other parameters, explained within text of particular descriptions ;
[ ] = > optional information;
= > alternative specifications, one of which must be used.

Many functions change which message is the current one. In the following, descriptions indicate the rule for assigning the current message; no indication is made when the function does not affect the current message.

Except when a component is being modified through a text editor e Ned (Bilofsky, 1977) or Ed (Thompson & Ritchie, 1975)) text is always added to the -end of components. This is done in a line-oriented manner; that is, the last character of a component is always an end-of-line, even if the appended text does not end with one.

Add (components)

The user is successively prompted for text, which is then Copied from the user's terminal to the end of each named component, in the draft. "Components" defaults to "Body".

Annotate (components) (msgs) (editor)

Allows modifying text in messages, while explicitly marking the modifications to the original text. The integrity of the original messages is thereby retained. The indicated text "editor" is repeatedly called with the contents of the named components. The user may then make any changes described. When a component is returned to the system, it is automatically compared with the original form of the component and changes are surrounded with text marking them as annotations. The original versions of annotated components are saved in the draft backup folder. During implementation, various ways of marking changes are being tested. "Components" defaults to "Body" and "msgs" defaults to the current message. The last message in "msgs" becomes the current message, if it is not the draft.


Causes discarded messages to be expunged from the current folder, and discarded components to be expunged from the draft. For safety, command interfaces should require confirmation of this function, due to the impossibility of reversing its action. Note that no single function has been defined to perform a Cleanup and then automatically Quit, although most other message systems provide such a function. Cleanup is a sufficiently dangerous function that it should be completely isolated from other functions.

Also, it is planned that the remaining messages in the folder may be automatically sorted according to transmission date, author name or the like. More complete specification of this capability is deferred for the time being.

Compare (component) (msg) (component) (msg)

This is a generalization of the behavior described for the Annotate function. Text in the first component is compared with the text in the second component and differences are noted (in the first component). As with the Annotate function, the method for marking differences has not yet been determined.

Compose (components) (preserve)

Allows the user to enter text to the "To", "cc" , "Subject", and "Body" components in draft. That is, the user is assisted in composing a simple message. If the draft already contains text, then the user is asked if a) it should be discarded, or b) if Compose should add onto the end of the text. At the end of the sequence, the user has the option of sending the message or returning to command level. If the draft is sent, it may be "preserved". "Components" alters the sequence of components for which text is prompted and facilitates creation of additional components. The system complains if the draft is not empty at the time this function is invoked and queries the user about proceeding.

Copy (file) (component)
(msgs) (component) (name)
(msgs) (folder)

This function provides a subset of the capabilities offered by the Map function. In particular, it is intended to facilitate performing the most frequently-used text transferring functions, without requiring the user to deal with the full complexity of the Map function.  

The function's first alternative form allows copying the contents of a "clear text" file (one that is not a folder) to the end of a component of the draft message. The second option allows copying one or more existing messages onto the end of a component of the draft; "name" will cause the copied text to be prefaced with the name(s) of the source component(s); and the third option allows placing a copy of one or more messages, in the current folder, at the end of some other folder. In this last case, as with the third option of the Map function, the original messages are Marked as having been filed.

The Copy function is quite a bit more limited than the Map function. If the destination is a component, then it may only be in the draft. The source may be either an external file or else an entire message; selection of separate components is not allowed. The first alternative is like the Add function, except that the source of text is a file, rather than the user's terminal; and the third alternative is like the File function, except that the source messages are not Discarded. The last message in "msgs" becomes the current message, if it is not the draft.  

Fig. 7 indicates the defaults used for each of the three options of Copy.

Correct (components) (msgs) (file)

Passes the named components through the Unix typographical-error detection program, which makes lists of possible spelling errors. A list is either placed into a component, in the associated message, which begins with the same name as the component being examined, but also has the suffix "-typos1'. Alternatively, the list may be placed into the indicated "file''. "Components" defaults to "body" and "msgs" defaults to draft. The last message in "msgs" becomes the current message, if it is not the draft.

Describe (keyword)

This function is intended to allow the user to peruse online information about MS, while the Help and Syntax functions assume more urgency. A special message folder is searched for a message with a special component which contains the keyword and all the associated text is shown to the user. Note differences from the H e l p and Syntax functions.  

"xx" indicates that the parameter must be specified explicitly and may not be defaulted.
Fig. 7-Defaults for the Copy function

Discard (components) (msgs)

Marks the indicated components as discarded from the message(s), but does not physically remove the text or re-order message numbering in the folder. This action is like placing a message in the wastebasket; it is still available, but somewhat less convenient to access, and is subject to permanent removal later, by the Cleanup function. Note that, as with other functions, this can be applied to the draft message. "Components" defaults to "All". "Msgs" defaults to the current message. A Discarded message is merely a message with all of its components deleted. If no Cleanup has been performed after a Discard, then the Retrieve function can be used to "un-discard" components, retrieving them from the "wastebaskett' and placing them back on the "desk". The last message in "msgs" becomes the current message, if it is not the draft.

Ed (components) (msgs)

Repeatedly invokes the Unix Ed text editor (Thompson & Ritchie, 1975) with the contents of each named component. If the components are from old (non-draft) messages, the user is warned that the integrity of the messages may be compromised and the command interface usually requires confirmation. "Msg" defaults to "draft" and "components" defaults to "Bodyn. The last message in "msgs" becomes the current message, if it is not the draft.  

File (msgs) (folder)

Copies all components of the indicated "msgs" to the end of the named message file and then Discards them from the current file. "Msgs" defaults to the current message. The last message in "msgs" becomes the current message, if it is not the draft.

Format (components) (msgs) (justify)

Passes the named components through a fill-in/justify formatting program. The program causes blocks of text, separated by blank lines, to have lines filled-out with text, as close to the right margin as possible. "Components" defaults to "Body" and "msgs" defaults to "draft". "Justify" is a flag which determines whether text is to be right-justified or not. The default is not to justify, but this is of course settable in the Profile. This function is capable of being sufficiently traumatic that the previous version of the text is saved in the draft backup folder. The last message in "msgs" becomes the current message, if it is not the draft.  

Forward (components) (msgs) (preserve)

Packages up existing message(s) for transmission to additional mail receivers. As with Compose, the draft is checked for existing text. Copies the "Subject" component, from the old messages, into the "Subject" component of the draft, bracketing each line. The resulting "Subject" component is displayed at the user's terminal. Allows the user to Add to the Body of the draft, if the user wishes to make comments about the text being forwarded; and then Copies the indicated components of the indicated messages into the Body of the draft, separating each message with some bracketing text: tt,,, Forwarded messages:'' goes at the beginning, "--- End of forwarded messages" at the end, and a line of dashes in between messages. "Components" defaults to "All" and "msgs" defaults to the current message. "Preserve" is the same as for the Send function. The last message in "msgs" becomes the current message, if it is not the draft.

Goto (msgs)

The first message in "msgs" becomes the current message, if it is not the draft.

Help (keyword)

This is a primitive facility for providing online assistance. A special message folder is searched for a special component containing indicated text and the user is given text associated with the Summary and Syntax components of the Help messages. Note the difference from the Describe function. Calling this function with no parameters causes a general assistance message to be printed. Synonyms are allowed, to catch errors in terminology and typing, and they are pointed out to the user. The same kind of feature is provided in the initial user interface, to allow misnomers. One type of statistics gathering which the system will perform is of the incorrect command words chosen by users. These will later be added to the list of synonyms.

List (components) (msgs)' (separate) (paginate) (heading) (file)

This is a primitive function for producing page-formatted sequential (e.g., hardcopy) output. The function creates a clear, sequential and "unprocessable" text copy of the named components. "Separate" indicates pagination between messages. "Paginate" indicates paginations within messages. "Heading" causes each page of output to be prefaced with the indicated text. When more than one message is Listed, a Scan listing is pre-pended. This function is not intended for producing text to be displayed on a CRT terminal, but rather for printing on a hardcopy device. "Components" defaults to "All". "File" defaults to the text specified in the Profile. "Msgs" defaults to the current message. The last message in "msgs" becomes the current message, if it is not the draft. "Separate" and "paginate" are also defaulted.

Map (file) (components) (msgs)
(components) (msgs) (components) (msgs ) (join) (name)
(components)(msgs) (file/folder) (join) (name)

This is the basic text transferring function which can be used to:  

1. Add text, from some file or from the user's terminal, into one or more components of one or more messages; (Option 1);  

2. Add to existing components, or create new ones, based upon the contents of old components; (Option 2);  

3. Transfer copies of components or entire messages to the end of other folders; (Option 3);  

4. Transfer copies of components or entire messages to other types of files (i.e., "clear" text files); (Option 3, with "join" specified) .

See also the Add, Copy, and File functions which offer tailored subsets of this function.

The name for this function is somewhat less predictable than the names given to other functions. Because of the function's generality and complexity, it is expected that users will not frequently employ it, so a name was chosen which would be likely to decrease the chances of a user's accidentally invoking it. User interface-builders, of course, may wish to use some other term; the word "map" is intended as a guide.

For the second and third alternatives of the function, the "discard" switch may be used to cause the original (i.e., the "source") copy of the transfered text to be discarded from the mailbox. For example, the File function uses the switch to give the appearance of "filing" the message, itself, into another mailbox.

As explained in the section describing the Text Transfer domain, the Map function uses information about the source and destination specifications to decide what kind of transfer to make. Four types of transfers are described above. A fifth can be distinguished by the use of the "join" switch with the second alternative. The primary unit of transfer is the component.

The first alternative is a transfer of sequential text, either from a file or from the user's terminal, added to the end of the destination components. Thus the user can include standard mailing lists to address components, prepared documents to the Body of the draft, and so on.

The second alternative also depends upon the "join" switch and whether the user indicates specific "components" for both the source and destination. If "join" is not set and only one list of components is specified, then the transfer is a map of those components from the source message(s) onto components of the same name in the destination message(s). If "join" is set or the user does specify both component lists, then the source components are joined into a block, as described for the fourth alternative, and added to each of the destination components. If "name" is set, - then the names of the source components are added as prefatory text to the transferred string.

The third and fourth alternatives depend upon the "join" setting. Normally, the second alternative applies and the function creates a copy of a structured set of components (which thereby constitute a message) at the end of another folder; this action is equivalent to the third option for the Copy function.

If "join" is indicated, the fourth alternative applies; it is like the second alternative, except that the destination is an external file and not a structured message. The components are merged together, to form a non-structured, "clear-text" string of text which is then appended to the end of the indicated file. In this type of transfer, the copied text is no longer accessible as a message.

Fig. 8 indicates the ways that defaults are used to make specification more convenient. The first two entries for option 2 cause the same behavior; the user simply indicates the single component list differently.

Mark (components) (msgs) (status)

Alters the setting for the indicated status, such as "examined", "flagged", "answered", or "discarded". The Discard function is a special case of this function. MS is designed to allow easy addition of new status indicators. The last message in "msgs" becomes the current message, if it is not the draft.

Ned (components) (msg)

Same as Ed function, but invokes the Ned two-dimensional CRT editor (Bilofsky, 1977), which normally requires the user to have an Ann Arbor 40-line terminal. "Msgs" becomes the current message, if it is not the draft.

Image "xx" indicates that the category of information has been specified explicitly by the user;"=>" and "< =" indicate that the component specification is the some as the one specified explicitly by the user. Fig. 8- Defaults for the Map function


Shows the next message which is not discarded, relative to the current message. (Note the difference in meaning between this and the "next" message-reference keyword, in Figure 6.) Since a folder holds messages much like a file folder in an office, it is not possible to go to the "next" message after the last one; an error message is produced if this is attempted. The message shown becomes the current message.

Open (folder)

Switches primary attention to another folder. The Open function itself does not make any modifications to the original folder. When the system is first started, the user interfaces usually default to opening the user's inbox. However, they often can take an argument to cause the system to start with another folder. The basic system does not keep track of previously-opened folders, although interfaces may wish to, so that users can easily return to folders, without having to remember their names. Any new messages are incorporated into inbox each time it is opened. The default for this function is the user's inbox.


Shows the previous message which is not discarded, relative to the current message. (Note the difference in meaning between this and the "previous" message-reference keyword, in Figure 6.) Since a folder holds messages much like a file folder in an office, it is not possible to go to the "previous" message before the first one; an error message is produced if this is attempted. The message shown becomes the current message.

Process (components) (msgs) (program) (replace) (file)

Consecutively passes the named components to the named program. "Replace" indicates whether the output, produced from the processing, is to replace the original version of the components. If the components are not to be replaced, then the output is placed into components of the same messages which have names that are the concatenation of the original components' names and the "program" name. For example, Correct will normally place its output into "body-typo" in the draft. Correct uses Typo; Format uses Nroff. Alternatively, the output may be placed in a "file". If a component is replaced, then its original version is saved in the backup draft folder. The last message in "msgs" becomes the current message, if it is not the draft.


Causes the mail system to stop and returns the user to the calling program (usually Shell). Maintains enough information about a user's session to allow continuation of it when MS is run again. Notices when draft is not empty and notifies users (in case they forgot to send the message). This notification may become optional as determined by a Profile setting.

Reply (msgs) (recipients) (folder) (verify) (fcc) (preserve)

Facilitates sending a message in response to received messages. As with Compose, the draft is checked for existing text. The To component of the draft message is built from the From components of the indicated "msgs", the cc component is optionally built from address lists in the components named in the "recipients" parameter and from user input. If specified, the "fcc" component (file carbon copy) is set to be the "folder" specified or else to default to the user's inbox.  

The Subject component of the draft is built from the Subject components of the indicated messages and, optionally, from user input. The text taken from the old messages is prefaced by "Re:"; to avoid a large number of nested brackets to occur, as a result of repeated replying, the preface is used only if one does not already exist, as when replying to a reply.

An In-Reply-To component is Added to the draft and contains the names (but not addresses) of the authors of the original messages, the dates (day and month) their messages were sent, and their message identification tags. This text is written in grammatical English.  

After the standard components are created, their contents are displayed at the user's terminal, to allow verification. Then the user is allowed optionally to A* to the Subject and cc components and then to to the Body component of the draft. And finally, the message is optionally sent, as if a Send function had been invoked; and the old messages are marked as having been Answered. Other defaults are specified in the user's Profile. The verify switch is used to have the system request the user to "verify'' inclusion of each potential recipient. And the "preserve" parameter is the same as for the Send function. "Recipients" defaults to the exclusion of all components; i.e., only the originator(s) will receive a copy. The last message in "msgs" becomes the current message, if it is not the draft.  


Allows users to send comments and complaints to the MS support staff. In reality, this function merely steps the user through a special Compose, creating an additional draft, and then automatically Sends the message to the appropriate people, including the report's author. A special draft, called "msreport", is maintained and is accessible in the same manner as the regular draft message. The user's regular draft message is not affected. Copies of reports are saved, in the draft backup folder.

Retrieve (components) (msgs)

The complement of the Discard function, which also works for the draft message. "Components" defaults to "All", "msgs" defaults to the current message. Computer users often call this an "undelete" function. The first message in "msgs" becomes the current message, if it is not the draft.

Revise (components) (msg) (editor)

This feature is intended to allow modifications to be made to existing messages, without explicitly indicating the strings of text which are changed. A separate component is used to record the fact of the modification. This latter component is like an audit trail. To a large extent, this function will be used when the reviser is violating the integrity of the original message but wishes to attribute original authorship. The function repeatedly invokes the indicated text "editor" on the named components. When revision is completed, a "Revision" component is Added to the message, with the user's name, the name of the revised component, and the date. If no "Revision" components currently exist for that message, then an "Originator" component is set to contain what was originally in the "From" component. The system therefore maintains an audit trail of modifications and preserves the name of the author of the message's original version. "Components" defaults to "Body" and "msg" defaults to the current message. Note that this function is not intended for use with the draft message, although such use is not prohibited. The last message in "msgs" becomes the current message, if it is not the draft.

Scan (msgs) (file)

Scans the messages and displays a "table of contents" listing of the indicated sequence of messages. The table includes folder index number, date sent, who from, the Subject component of the message, and indication of various aspects of each message's status. If the message contains no Subject or "Re" component, the initial portion of the message "Body" text (enough to complete the current line) is displayed. This text appears in the form

("this is the beginning. . . ")

complete with parentheses, quotation marks and elipses. Given the , current limitations of display format specification, this function cannot be defined in terms of a Copy or List. "Msgs" defaults to the group of recent messages. "File" defaults to the user's terminal.

Display format: SSS IIIC (LLLL) DDD From-Name Subject

SSS Message's status (see below);
III Message's index position in folder;
C "<=" indicates the "current" message;
LLLL Message length in lines;
DDD The day and month of the message's Date component;
From-Name Person's name or ID portion of the "From" component (sans hostname); and
Subject As described above.

Only a portion of the possible status information is displayed with this function. For example, information about a message's having been answered or flagged is not included.

Status Indicators:

- not seen
+ recent
*[ discarded

Send (preserve)

Packages up the draft message into a standard format and submits it for transmission. Contrary to most network message systems, MS attempts to send all mail immediately; users may choose to observe the process, but their choice does not affect the timing of transmission. Mail is actually queued for later transmission only when an initial attempt fails. A copy of the draft is filed into a backup folder, which is in the same directory as other standard MS files. -Send may also be instructed to "preserve" the copy in draft.  



*Such per-component manipulations appear to involve issues which are also relevant to providing multi-level security in a message system.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 3:59 am

Part 3 of 3


This may be provided by the user interface and is not in the basic system. It is listed in this specification as a reminder of its utility for most interactive systems. The user is given access to a version of the Shell program (see Figure 2).

Show (components) (msgs)  

Displays messages at the user's terminal. "Components" defaults to the set stored in the user's Profile (initially, "Allf'). "Msgs" defaults to the current message. The last message in "msgsf' becomes the current message, if it is not the draft.

Statistics (name) (type) (value)

This function is not intended for the user; it is intended for standardized collection of user statistics, such as the names of functions that are called and the amount of computation which is required to perform particular functions. "Nameff is an identification name which is unique to the caller of this function. "Type" is a sub-grouping identifier; and "value" is any text to be taken as a piece of data for this statistic. The actual usage of this function will conform to legal and social privacy considerations.

Syntax (keyword)

Displays the syntax for the indicated command. This function is a subset of the Help function, printing only the "Syntax" portion of the associated online assistance message.


This function is not in the basic system; it is recommended for inclusion in most user interfaces. The feature causes a display of the list of inputs valid at that level of a specification. Therefore this function is not intended just for top-level use. It should be possible to invoke it in any argument.


MS became partially operational at Rand in the fall of 1976. The "ms", "msg", and "mail" interfaces are all used regularly by Rand staff members. Distribution of the system to other ARPA project Unix machines was begun in late summer 1977. By that time, almost all of the originally-specified functions were built. Only Annotate and Compare have not yet been implemented. More seriously, no portion of the Profile exists; its lack is felt by all users, in particular for the purposes of regularly viewing only portions of messages and setting several switches to redefine the system's default actions.

In addition, the system does not allow blind carbon copies of messages and does not strictly enforce constraints on modifying Sender, Message-ID, and Timestamp. While specifying message addresses, users cannot yet include the contents of lists in files (with "<") or direct a copy to a folder (with ">"); address list names also are not properly handled. Their lack has not been seriously felt by users, at this stage of system use. The online assistance capabilities have been implemented only partially; and the Scan listing measures message length in number of characters and not lines. Users are notified of new mail only when they initially log into Unix and, when using MS, upon Opening their inbox. In a few cases, more general message and component selection capabilities (e.g., full Boolean) would have proved useful.

Current activities involve exporting the system to other sites, adding the Profile and increasing the efficiency of the system code. Portions of MS are currently quite slow and this has deterred some users from the system. The focus of this optimization effort is the parallel "structure" file which was initially implemented in an extremely general organization. Experience with MS has suggested a more constrained organization. It should be noted that the presence of a dual-file organization makes the transition between structures quite simple.


Although MS has so far received only limited distribution, current indications are that it successfully fulfills its design goals. In particular, integrating access and modification capabilities with the draft and existing messages has proved extremely convenient. In general, the available functions and the style of their behaviors seem satisfactory to users, although the availability of the Profile would considerably improve some users' attitudes.

During the initial design review, the choice between using parallel files versus a single structured file led to some heated discussions. Experience to date thoroughly justifies the double-file choice, although its use did increase the complexity of the software needed to access and maintain text. The choice has meant that idiosyncratic, but necessary, modifications, such as massive reorganization to several messages, could be made to message files, without undue pain to the user.

The Map function has been a continuing problem. It has proved difficult to implement according to specifications and users are generally unable to employ it successfully. The Copy function is a direct result of these problems and it seems to adequately account for most users' needs, most of the time. It should be noted, however, that in at least one case a user wanted to copy a part of a message, into a draft component, and could not understand why the Copy function was unable to perform the function. This suggests that the focus on monolithicity is well-founded, and having the concept of the Map function has proved a useful focus for the MS project. In general, how- ever, such per-component manipulation is not currently needed, though this may change as the Profile enables users to specify complicated actions once and then repeatedly re-use the specification.

The Shell-syntax interface to MS has variously encouraged and deterred new users. Some indicate that the similarity of syntax did, in fact, facilitate their learning to use the system; others indicate that the inherent complexity of the full MS domain requires more effort than they wish to expend. These users are quite comfortable with the msg interface. A confounding factor is the system's slowness. Some users are waiting to make the transition to MS until after it has been made more efficient.

Implementing the basic system at the level of user-functions, rather than the more common primitive-functions, has also been a mixed blessing. User interfaces are, in fact, easier to build and the extra software overhead of placing the higher-level functions into the kernel of MS, appears to be minimal. However, the communication discipline between the user interface and MS kernel system is not wholly adequate. In particular, the user interface cannot query the kernel for status information (e.g., whether a message is discarded) and cannot adequately select subsets of different functions' behaviors. Also, the kernel's interactions with the user, such as for verification to performing some actions, cannot be fully controlled by the user interface. Remedies to these deficiencies are being considered.

From the standpoint of operational efficiency, it is unfortunately not currently possible to construct a simple system, with a subset of MS' full capabilities, without dragging along all of the software associated with the full system. The user need not see all of this, but it makes the programs more cumbersome. Some investigation is underway to discover how the system might be factored into smaller units; for example, infrequently-used functions, such as Cleanup, may be made separate processes.

Finally, use of the specification style led to a lack of precision in specifying the system's primitive functions. In some situations, this deficiency would have been disastrous. However, the project's operational environment made frequent consultation between members quite convenient. In addition, Bill Crosby, the system's primary implementor, usually chose to provide features in as general a fashion as possible; after experience was gained with the feature, tailoring it was usually quite simple. It should also be noted that much of the desired precision was not possible until we had that experience.

In spite of these problems, the specification style seems generally to have been useful, in that it has focused at the level of the user. Many systems, in spite of being examples of excellent software engineering, do not reflect this focus and are therefore inappropriate for most users.

Appendix A


Add (component)

Sequential text is Copied from the user's terminal to the end of the named component in the draft.

Annotate (components) (msg)

Allows adding text to a message, while explicitly marking it as an addition to the original text. The integrity of the original message is thereby retained.


Causes discarded components and messages to be expunged from the message file.


Allows the user to conveniently A-dd to the "To" , "CC" , "Subject" , and "Body" components in Draft, by prompting for their text.

Copy (file) (component)
(msg) (component)
(msg) (folder)

Allows copying the contents of files, or existing messages, into a component of the draft message, and copying entire messages to other message files.

Correct (component)

Passes the named component through the Typo spelling corrector program.

Describe (keyword)

For obtaining information about the message system. A special file is searched for the keyword and the associated text is shown to the user.

Discard (msgs)

Marks the indicated messages as deleted from the mailbox.

Ed (component)

Invokes Ed editor with the contents of the named component.

File (msgs) (folder)

Moves the indicated messages to the end of the named file.

Format (component)

Passes the named components through the Nroff text formatting program.

Forward (msgs)

Packages up existing messages for retransmission to other mail receivers.

Goto (msg)

Changes the current message to the specified message.

Help (keyword)

Primitive help facility. A special text file will be searched for the indicated text and the user will be given the initial text associated with the keyword.

List (msgs) (order) (options) (file)

This is a primitive formatting function for producing hardcopy versions of messages.


The generic text-transferring function, which is inconvenient to use for standard transfers. See @, Copy, and File function descriptions.

Ned (component)

Same as Ed function, but invokes the Ned two-dimensional CRT editor.


Show the next message, relative to the current message.

Open (file)

Switches to another message file. When the system is first started, it defaults to opening the user's inbox.


Show the previous message, relative to the current message.

Process (component) (program)

Consecutively passes the named components through the named program. Correct uses Typo; Format uses Nroff.


Causes the mail system to stop and returns the user to the calling program (usually Shell).

Reply (msgs)

Allows responding to received messages.

Retrieve (msgs)

The complement of the Discard function.

Scan (msgs)

Scans the messages and produces a table of contents.

Send (preserve)

Packages up the draft message and submits it for transmission.

Show (msgs)  

Displays the messages at the user's terminal.

Syntax (function)

Displays the syntax for the indicated function.


Displays a list of inputs valid at that level of a specification.

Appendix B


The sample command interface, specified here, is intended to be compatible with the syntax of the Unix Shell (see fig. 2); however, a few deviations are quite intentional.

In general, the user types the appropriate function name, to invoke a particular function. For convenience, the interface requires that only enough of the word be typed to distinguish it from other candidate names. For example "cop" means "copy". As an additional convenience, commands have a very terse form, which is shown immediately below the full form. A large number of synonyms have been defined for the commands and standard symbols, such as "examined". Users may type these synonyms, in place of the "official" terms, and they will be accepted, although they are not allowed to interfere with distinguishing between official terms. For example, "discarded" and "draft" are official terms referring to two different classes of messages; and "displayed" is a synonym for "seen". However, the user need type only "di" to mean "discarded" and must type at least "disp" to mean "displayed". The system is not so friendly as to advertise the synonyms it knows about. This limitation is imposed primarily to limit the length of listings produced with the ? function.

The system has a rudimentary error detection and correction facility appropriate to a line-oriented system. For example, upon detecting an error in part of a specification, the interface will notify the user of the nature of the error and prompt the user for the replacement information, saving all of the other information originally typed up to the point of the error. Except in the cases of folder and file names, the system will not make any distinction between upper and lower case characters in command lines.

The reader should remember that this interface is only one of several which are being implemented. It was the first interface built, in order to be compatible with the syntax of the existing Unix Shell, but is definitely not proffered as an example of a "friendly" human user interface. An MSG-type interface also is provided.

Defaults for function parameters are as recommended in the function descriptions. In addition, some abbreviated syntactic forms are allowed during specification; however, the interpretation of these depends upon context, as shown in the examples for the Copy Copy command, below. The "official" syntax, which conforms to Shell-syntax, does not have this dependency.

The system is invoked by typing "ms" to the Shell. A file name may be included as a parameter, in which case the indicated file, rather than the user's inbox, is opened.

The basic syntax for commands is:

command source -options > destination  


command is the command word;

source is a filename or message/component specification;

options are optional switch settings; each option ("switch") is prefaced by a dash ("-");

destination is filename or message/component specification; ">" is required with destinations that are not defaulted

Specific command descriptions indicate limitations on the above. Also, for prompted input from the terminal, such as for the compose function, the user may enter only one line of text (unless the last character is backslash, as shown below), unless a message is displayed to the user indicating that a Control-D (the ASCII EOT character) at the beginning of a line will terminate input.

Other standards, where applicable:

\ (Backslash, when preceding a carriage-return) Continue onto next line.

I Passes the output to a process, rather than a file; in place of the ">" destination option.

--# Where appropriate, means to reverse the the meaning of the indicated (#) switch; for example, in the Format function, "-j" means to right-justify text, so "--j" means that justification will not occur.

# An integer, indicating a message's position within a mailbox.

#-# A sequence of messages, starting with the first message and ending with the last.

-c Following arguments are component references.  

-f Following argument is a file reference.

-m Following arguments are message references.

x,x The same as two arguments separated by space.

c c Indicates a list of arguments, such as "to cc" or "3 4 7".  

"..." A quoted parameter, which allows the text to contain special characters such as space.

For convenience, the "-m" , "-f" , and "-c" switches often are not necessary. If the specification is a common one, then the text typed by the user will be interpreted correctly. For example, the formal , specification for filing the current message into mailbox "filed.m" is "file -m current > -f filed.m"; however, the user actually need type only "f > filed.m"'.

Notational conventions, for the following descriptions:

c A single component may be referenced at this point;

cs Reference to a number of components is legal;

f Reference to a file is allowed;

m Reference to a single message is allowed;

ms Reference to a number of messages is allowed;

( ) Other information may be specified; the nature of this information is explained in the text of the associated description.


Add/A c

Annotate/An cs/ms [-e]

- e Following argument names text editor


Compare/Cpr c/m > c/m

Compose/C [-c] [-p]

-p Same as Preserve option, for Send

Copy/Cp f>c
ms > c [-n]
ms > f

-n Indicates that component names are to preface component text, when the second specification option is used.


Cp > backup .msg
Appends the current message to the end of file "backup.msg".

Cp -m 2 > -c Body
Adds message 2, as a block, to the end of the Body of the Draft. The "-m" is gratuitous, but the "-c" is not, since the destination of a message is usually a file.

Cp -f document > body
Appends the contents of file "document" to the end of the Body of the draft. The ">bodyw is gratuitous, since text copied from a file usually goes to the body of the draft. However, since the source of text is usually a message in the current mailbox, the "-f" specification is necessary.

Correct/Crct cs/m

Describe/Dsc (keyword)

Discard/D cs/m

Ed cs/m

File/F m>f

Format/Fm cs/ms [-j ]

- j Justify

Forward/Fw cs/ms [-p]  

-p Preserve draft, as in Send

Goto/G m

Help/H (text)

List cs/ms [-h] [-pI [-s] ) f

-h Use next argument as page header;  

-p Paginate within messages;

-s Separate messages; start each one on a new page;


L 3-9 o0 memoform -p -h "Noteworthy Stuff" I 1pg Will list messages 3-9 on the printer; listing will be paginated with the indicated heading, and components will be ordered according to the list in the profile called Memoform. Messages will not begin on a new page.

Map f >cs/ms [-d]
cs/ms > cs/ms [-j] [-n]
cs/ms > f [-j] [-n]

-d Discard source version of text;

- j Turns on the join switch;

-n Indicates that component names are to preface component text, when the second specification option is used.


Map > backup.msg
Appends the current message to the end of file "backup.msg".

Map -c Subject -m 2,5,9 > -c Subject Keyword
Appends the text of the Subject components in messages 2, 5, and 9 to the Subject component and then the Keyword component of the draft.

Map -m 2 -c Subject,From CC To > -c Body
Adds the source components as a block to the end of the Body.

Map -m 2-5 -c From To CC BCC > -m 9
Adds the contents of each of the indicated address components onto components of the same name (creating them if they do not already exist) in message number 9.

Map -m 2-5 -c From To CC BCC > -m 9-10 -c From Subj
As when the text was copied to Body, above, the text is copied as a single group but to the end of the From and then the Subject components of messages 9 and then 10.

Map -m 2-5 -c From To,CC,BCC -n > -m 9-10 -c From Subj
Same as above, except that the text of each source component is prefaced by its component name.

Mark/Mk cs/ms (status)

Ned cs/ms


Open/O f


Process/Prc cs/ms (program [-r]

-r replace each component with the output of the processing.

Quit/eot (control-D) and Q

Reply/Rpl ms [-a] [-i] [-p] [-v]

-a Author copy: Place "inbox" into fcc component.

-i Copy contents of the components, named in the following parameters, into the cc component of the draft.

-p Preserve, as with -Send.

-v Verify inclusion of each addressee.


Retrieve/R cs/ms

Revise/Rv cs/ms [-e]  

-e Following argument names editor
{ Scan } ms [ > f]

Scan/Sc ms [>f]

Send/Snd [-p] [-q] [-s]

-p Preserve Draft after sending.

-q Queue mail.  

- s Send mail immediately.


Show/S cs/ms

Syntax/Sy (command)


Appendix C


During the initial phases of implementation, a question arose concerning the way in which MS should deal with user references to discarded or non-existent text. An exhaustive list of behaviors was created. It is included here because it represents a statement of philosophy concerning the treatment of user errors. What did the user probably mean? Some references are completely specific, in which case the user probably believes that the message is not discarded and therefore probably needs to be told, or when safe, the action should be performed. In other cases, an implicit reference is made, such as "examined", in which case the user probably does not care that a few I I extra" messages have been included; so the user is not burdened with the information that s/he has made an error.

In the following table,

Yes/No indicates whether the function is performed, or not;

Note/Quiet indicates whether a notice is displayed to user, or not;

Replace indicates whether discarded text is replaced; and

Flag indicates whether individual discarded messages are noted.

The Show function distinguishes between specific reference, as in "show 3" and implied reference, as in "show all".

Function / Component reference / Msg. reference

Add / Yes; quiet,replace / Not applicable
Comment / No; note / Not applicable
Copy -- See Map / --
Correct / No; note / Not applicable
Discard/ No; quiet / No; quiet
Ed/Re / Yes; replace / Not applicable
File / Not applicable / No; note
Format / No; note / Not applicable
Forward / No; note /Yes; quiet
Goto / Not applicable / Yes; Discard: quiet Not exist: note
List / No; quiet / no; note
Map / Srce: no; quiet Dest: note & replace / --
Next/Previous / Not applicable / Yes; discard: quiet not exist: note
Process / No; note / Not applicable
Reply / Not applicable / Yes; discard: quiet not exist: note
Retrieve / No; quiet / Yes; quiet
Revise / No; note / Not applicable
Scan / Not applicable / Yes; flag
Send / Not applicable / No; note
Show/implied / No; quiet / No; note
Show/specific / Yes; flag / Discard: yes, flag; Not exist: no; note

Appendix D







Anderson, R.H. and J.J. Gillogly, Rand Intelligent Terminal Agent (RITA): Design Philosophy, R-1809-ARPA, The Rand Corporation, Santa Monica, California, February 1976a.

Anderson, R.H. and J.J. Gillogly, "The RAND Intelligent Terminal Agent (RITA) as a Network Access Aid," Proceedings of the 1976 National Computer Conference, 1976b.

Bilofsky, W., The CRT Text Editor Ned: Introduction and Reference Manual. R-2176-ARPA. The Rand Corporation. Santa - Monica, California, in preparation, 1977.

Bobrow, D.G., J.D. Burchfiel, D.L. Murphy, and R.S. Tomlinson, TENEX, A Paged Time Sharing System for the PDP-10, BBN Report No. 2180, Bolt Beranek and Newman, Cambridge, 1971.  

Broos, M.S., E.H. Black, and A. Vezza, MSGDMS Manual (draft), Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, 1975.  

Brown, T. and M. Klerer, "The Effect of Language Design on Time Sharing Operational Efficiency," International Journal of Man-Machine Studies, Vol. 7, 1975, pp. 233-247.

Carbonnel, J.R., J.E. Elkind, and R.S. Nickerson, "The Psychological Importance of Time in a Time Sharing System," Human Factors, Vol. 10, No. 2, 1968, pp. 135-142.

Carlisle, J.H. "Man-Computer Interactive Problem Solving: Relationship Between User Characteristics and Interface Complexity," Ph.D. Dissertation, NTIS No. AD786466, School of Organization and Management, Yale University, New Haven, June 1974.

Card, S.K., T.P. Moran and A. Newell, The Manuscript Editing Task: A_ Routine Cognitive Skill, PARC Report No. P76-00082, Xerox Systems Science Laboratory, Palo Alto Research Center, Palo Alto, California, 1977.

Crocker, S.D., J. Heafner, R. Metcalfe, and J. Postel, "Function-oriented Protocols for the ARPA Computer Network, Spring Joint Computer Conference, Vol. 40, 1972, pp. 271-279.

Engelbart, D.C., Coordinated Information Services Discipline- or Mission-Oriented Community, Network Information Center No. 12445, Augmentation Research Center, Stanford Research Institute, Palo Alto, California, 1972.

Heafner, J.H. "Design of Application-Oriented Languages by Protocol Analysis," Ph.D. Dissertation, University of Southern California, Los Angeles, 1976.

Heafner,' J.H. and L.H. Miller, Design Considerations for Computerized Message Service Based on Triservice Operations Personnel at CINCPAC Headquarters, Camp Smith, Oahu, ISI/WP-3, Information Sciences Institute, University of Southern California, Marina del Rey, California, September 1976.

Miller, George, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information," Psychological Review, Vol. 63, 1956, 81-97.

Myer, T.H., J.R. Barnaby, and W.K. Plummer, TENEX Executive Language Manual for Users, Bolt Beranek and Newman, Cambridge, 1971.

Myer, T.H. and D.A. Henderson, "Message Transmission Protocol," Arpanet Request for Comments, No. 680, Network Information Center No. 32116; Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 1975.

Myer, T.H. and C.D. Mooers, Hermes Users Guide, Bolt Beranek and Newman, Cambridge, 1976.

Panko, R., The Outlook for Computer Message Services: A Preliminar Assessment, Telecommunication Sciences Center, Stanford Research Institute, Palo Alto, California, March 1976.

Pogran, K., J. Vittal, A. Henderson, and D. Crocker, "Proposed Official Standard for the Format of ARPA Network Message Headers," Arpanet Request for Comments, No. 724, Network Information Center 37435; Augmentation Research Center, Stanford Research Institute, Menlo Park, California, May 1977.

Ritchie, D.M. and K. Thompson, "The UNIX Time-sharing System," Communications of the Association for Computing Machinery, Vol. 17, No. 7, July 1974, pp. 365-375.

Roberts, L. "Computer Network Development to Achieve Resource Sharing," Spring Joint Computer Conference, Vol. 36, 1970, pp. 543-549.

Thompson, K. and D.M. Ritchie, Unix Programmer's Manual, Bell Laboratories, Murray Hill, New Jersey, 1975.

Tugender, R. and D.R. Oestreicher, Basic Functional Capabilities for a Military Message Processing Service, Information Sciences Institute, Marina del Rey, California, 1975.

Uhlig, R., "Human Factors in Computer Message Systems," Datamation, Vol. 23, No. 5, May 1977, pp. 120-126.

Vezza, A., "A Model for an Electronic Postal System," In B.M. Owen (ed. ) , Telecommunications Policy Research conference Proceedings. Aspen Institute Program on Communications and Society, 360 Bryant St., Palo Alto, California 94301, 1976.

Vezza, A. and M.S. Broos, "An Electronic Message System: Where Does It Fit?" In Trends and Applications 1976: Computer Networks, Institute of Electrical and Electronic Engineers, New York, 1976.

Vittal, J. MSG Users Guide, Information Sciences Institute, University of Southern California, Los Angeles, 1975.

Walther, G.H., The Online User-Computer Interface: The Effects of Interface Flexibility, Experience, Terminal-Type on User Satisfaction and Performance, Ph.D. Dissertation, NTIS NO. AD777314, University of Texas, Austin, 1973.

Yntema, D.B. "Keeping Track of Several Things at Once," Human Factors, Vol. 5, 1963, 7-17.

Yntema, D.B. and G.E. Meuser, "Remembering the Present State of a Number of Variables," Journal of Experimental Psychology, Vol. 60, 1960, 18-22.

Yntema, D.B. and G.E. Meuser, "Keeping Track of Variables that Have Few of Many States," Journal of Experimental Psychology, Vo1.63, NO. 4, 1962, 391-395.

Yntema, D.B. and G.M. Schulman, "Response Selection in Keeping Track of -several Things at once;" Acts Psychologica, Vol. 27, 1967, pp. 316-324.

Yonke, M. BANANARD Users Guide, Information Sciences Institute, University of Southern California, Los Angeles, 1975.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 5:39 am

Huffington Post And The View From Bogustan: Standing Behind Blatantly False Claims Isn't Journalism
from the what's-wrong-with-people-over-there dept
by Mike Masnick
Fri, Sep 5th 2014



Over the last week, we've been debunking a bizarre "series" of stories over at Huffington Post, which is claiming to be about "the history of email" but is not. It's about a guy, Shiva Ayyadurai, who may have written an implementation of email in the late 1970s, but which was clearly well after email was in widespread use. Ayyadurai's actual program (and as far as I can tell, he has not released any screenshots of what the program actually looked like) may have worked well for the University of Medicine and Dentistry of New Jersey (UMDNJ) where he wrote it as a 14-year-old, but it contributed nothing to the future of email. Beyond email existing in various forms long before that, nothing that happened later in the email space appears to have happened because of Ayyadurai's program. Each of the advancements in email came from elsewhere, with no indication that anyone anywhere was even aware of what Ayyadurai had done in New Jersey.

Ayyadurai has waged an incredibly bizarre public relations campaign, and the more you look at it, the more bizarre it becomes.
However, anyone who looks over any of the primary documentation (much of which we've linked to in our previous posts) can only conclude that while Ayyadurai may have independently come up with some ideas, he most certainly did not invent email. It was widely in use. The key arguments in his claim are obviously false, and prey on (1) a misunderstanding or misrepresentation of copyright law and (2) an almost fraudulent misquoting of Dave Crocker, a guy who really was heavily involved in early email efforts. Again, all of that is discussed in the earlier posts.

What I still cannot fathom is how the Huffington Post can stand behind this "reporting." I've now heard from three different HuffPost reporters on the news side who all say that they're horrified that no one at the company has done anything about this. The only official response I got stood by the stories, but actual reporters at the company recognize that their own credibility has been absolutely destroyed by this. It's been pointed out that the five part series is on HuffPo's "blogging" side -- which gives a platform to PR folks with no editorial oversight.

But, because HuffPo does little to separate out its "news" division from those open "blogs," the blogs get filled with all sorts of clearly bogus crap. Much of it gets totally ignored, but some (apparently including PR "guru" Larry Weber and his business partner Shiva Ayyadurai) are willing to exploit the fact that no one recognizes the blogging platform has no editorial review, to pretend that a "reputable source" has "confirmed" the story. Ayyadurai himself keeps pointing to the HuffPo stories as some sort of "vindication" (while hilarious suggesting that I'm being paid off by Raytheon...). He leaves out that these are all blog posts by his friends and partners, put up on the site with no editorial review. Again: every serious look into the history has found that he is not the inventor of email.

And that's why it's so damaging to the good reporting that some actual HuffPo reporters do, to find out that the company won't retract and renounce this series as a PR campaign for a series of blatantly fraudulent claims -- obvious to anyone who looks at the documentation. Even worse, however, is the fact that part of the HuffPo journalism side -- HuffPo Live -- picked up on the completely bogus campaign and did a whole fawning interview with Ayyadurai, never once presenting the evidence that he's fraudulently misrepresenting basic facts. And, contrary to the claims from Huffington Post's PR people, the HuffPo Live articles, written by Emily Tess Katz, do not have any "clarification" -- bogus or not.

I've now asked the author of the HuffPo live stories, Emily Tess Katz, multiple times if she still stands by this story, and she has refused to respond. Journalistic integrity! According to one report, she had said she stood by it, and then deleted the tweet.

We've talked in the past about the concept of "he said/she said" journalism -- what Journalism Professor Jay Rosen likes to call "the view from nowhere" -- in which journalists feel (incorrectly) that "being objective" means giving "both sides equal weight and letting the reader decide." That's bad. Journalism should be about the search for truth.

The thing that's truly baffling here isn't that HuffPo and HuffPo Live are doing "the view from nowhere," but that they're actually actively promoting a lie. It's the view from Bogustan. Rather than promoting the truth or presenting false balance, Huffington Post is actively claiming that a clearly false story is true -- and when presented with reams of evidence on that front, it appears that the company is simply throwing up its hands and hoping the whole story just blows over. Beyond the reporter, I've emailed Huffington Post PR people, and they, too, are now refusing to comment. Meanwhile, some of the company's very good reporters are hanging their heads in shame.

My suggestion: perhaps it's time to start looking for a publication to work for that actually takes journalistic integrity seriously.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 5:41 am

Huffington Post Finally Removes Most Articles About Fake Email Inventor; Meanwhile, Ayyadurai Threatens To Sue His Critics
from the did-he-invent-slapp-suits-too? dept
by Mike Masnick
Mon, Sep 8th 2014



Over the weekend, it appears that someone at the Huffington Post finally realized that hoping the fuss over its entirely bogus "history of email" series would blow over wasn't going to happen. In case you missed it last week, we had called out Huffington Post for allowing Shiva Ayyadurai and his friends to post an entirely bogus "history of email" series, all designed to make it look like Ayyadurai himself had invented email -- a claim he's been making for a few years, despite it being entirely false, based on totally misrepresenting a number of things, including what copyright means, misquoting a 1977 research paper and playing "no true scotsman" over what is a "true" email system. Despite the evidence of how wrong Ayyadurai and his friends were, HuffPo allowed the series to go on with more false claims, and then told me it had "added a clarification" that didn't clarify anything, but was a statement written by Ayyadurai, repeating the false claims. On Friday, we wondered how Huffington Post could justify posting obviously false information.

It appears the powers that be at HuffPo finally realized that they had a problem.

All of the posts by Shiva Ayyadurai's friends, making the entirely false argument that he "invented email," have been removed from Huffington Post, redirecting people to this page with the following text:

The post that previously appeared in this space -- part of a blogger-generated series on the history of email -- is no longer available. Readers and media commentators alerted us to factual and sourcing issues in the series and, after an internal review, we removed it from the site.

There are some interesting language choices there. First, note that they admit that it was a "blogger-generated series," which is an attempt to distance the fake series, put together by Shiva Ayyadruai himself with PR guru Larry Weber, from Huffington Post's journalistic "news" side. Ayyadurai and Weber had been banking on the fact that most people don't realize that the blogging side of HuffPo has no editorial controls to pretend that the series had some sort of journalistic credibility. They appear to be promoting the fake articles everywhere, and some of their supporters have been trying to use the Huffington Post series as credible citations for Wikipedia (amusingly, one of their supporters kept trying to reject others pointing to my detailed debunkings by saying it doesn't count since I'm just a blogger -- ignoring that Weber, Ayyadurai and their friends were using HuffPo's blogging platform as well).

Of course, what that note also (conveniently) leaves out is that it wasn't just the "blogger-generated series" that was the problem and has been taken down. HuffPo Live (part of its "journalistic" side) also did a long interview with Ayyadurai, and had articles written up by reporters like Emily Tess Katz (who continues to ignore every question asked about this), repeating ridiculous claims from Ayyadurai about how his critics are just racists who don't like the fact that a "dark-skinned immigrant boy" invented email. Of course the reality is that it has nothing to do with racism, but rather the facts -- which Huffington Post journalists apparently didn't even think were worth the trouble of a quick Googling, to find where all of Ayyadurai's claims had long since been debunked.

Finally, HuffPo didn't actually take down all such articles. There's a blog post from 2013 by Deepak Chopra and Ayyadurai making the same claims that remains on the site.
Ayyadurai is associated with Chopra and frequently uses his connection to Chopra as some sort of validation of his claims.

Amusingly, despite HuffPo PR people telling me to email them with any more questions last Wednesday, they ignored every question I sent them since then (with one exception which I'll get to below), and (of course) didn't bother to tell me they had pulled the series either, despite my sending a few questions about whether they intended to keep it up. Instead, a whole bunch of you -- the readers of this site -- let me know. It's almost as if HuffPo wished to sweep the whole thing under the rug.

Of course, one part of the problem may be that Ayyadurai is now claiming in the Economic Times of India that Arianna Huffington herself "commissioned" the series after hearing Ayyadurai give a talk. I asked HuffPo PR (and Arianna directly) if that was accurate and (finally) HuffPo PR got back to me to say that (once again) Ayyadurai is lying, and that "neither HuffPost nor Arianna 'commissioned' Shiva's series."

In that same Economic Times article, there's also the absolutely hilarious claim from Ayyadurai suggesting that he's considering legal action against his "critics."

Shiva Ayyadurai, the man in the middle of a raging controversy over his claims of being the inventor of email, doesn't want to go legal on his detractors but is looking for support from the public. "Lawsuits take a long time. If I have to pull the trigger I will. But I have decided to go directly to the people," Ayyadurai said in an interview with ET.

First off, there is no "raging controversy." There's no controversy at all. Ayyadurai is simply making false claims and that's agreed upon by pretty much everyone who's looked at the evidence. Second, "going to the people" is great, but historically he's done that with clearly bogus claims -- such as misquoting Dave Crocker's 1977 research and pretending that his 1982 copyright on his EMAIL software is the equivalent of a patent for the concept of email. So it's pretty easy to counter that, since the facts are not on his side. As for the idea of a lawsuit, I would hope that any lawyer he discusses a lawsuit with takes the time to look at the details here -- and also understand the laws around SLAPP suits and the nature of the First Amendment. Because I may not be "the inventor of email," but I can guess that any such lawsuits won't end well for Ayyadurai.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 5:45 am

Fact Checking Is Dead: Mainstream Media Goes Nuts Repeating Debunked Claims By The Fake 'Inventor Of Email'
from the is-this-really-so-hard? dept
by Mike Masnick
Tue, Sep 9th 2014



I had honestly hoped that yesterday's story about the Huffington Post finally retracting its series of totally bogus articles (mostly written by Shiva Ayyadurai or his colleagues and friends, but a few by its actual "journalists"), pretending to argue that V.A. Shiva Ayyadurai had "invented email," would be the end of this story. Ayyadurai has built up quite a reputation around this false claim, even though it's been debunked over and over and over again.

Ayyadurai keeps coming back, often moving the goalposts and changing his definitions, but still ultimately flat out lying in pretending to have "invented" email.
To be clear, he did no such thing. Email was in wide use at the time he supposedly wrote his software. Ayyadurai, however, has cleverly used misleading (to downright false) claims to make what appears on its face to be a credible story, fooling a number of gullible reporters. The crux of his argument revolves around the copyright registration he obtained for a software program in 1982 called EMAIL. But, as we've explained over and over again, a copyright is just for a specific expression (i.e., that specific program), and not for "inventing" anything. The most obvious parallel would be Microsoft, which holds a copyright on "Windows" -- the operating system -- but did not "invent" the idea of a graphical user interface involving "windows."

And yet, yesterday morning, everyone began flooding me with new stories about Ayyadurai, written by clueless entertainment reporters, all because Ayyadurai apparently got married to actress Fran Drescher. The "dating Fran Drescher" story has been making the rounds for a while now, and it was so random and unrelated that we'd ignored it in previous posts, even though one part of the HuffPo series was HuffPo Live talking to Ayyadurai about Drescher, in what was an incredibly awkward exchange (note: despite pulling most of the other articles about Ayyadurai, HuffPo left this one up). In the video (which has been taken down), Ayyadurai made this incredibly awkward "introduction" to Fran, in which he repeatedly highlights that he's just hanging out "in Malibu with Fran," and then says for emphasis "with Fran Drescher, who I'm dating." That leads Fran to jump into view, and the HuffPo live "reporter" Caroline Modarressy-Tehrani starts absolutely gushing over Fran. It was weird, but since it wasn't directly related to whole lie about "inventing email," we hadn't mentioned it.

However, thanks to the "wedding," now it appears that tons of mainstream press reports are writing about the wedding and repeating the totally debunked claim about Ayyadurai "inventing" email. This has resulted in many people wondering if the whole HuffPo series was deliberately ramped up prior to the "wedding" to get the mainstream press to roll with the bogus claim. It's entirely possible, but considering that Ayyadurai has been trying to make this lie stick for years, it may just be a convenient coincidence. Either way, the mainstream press apparently is unable to do any fact checking and is repeating bogus claims as facts. Let's highlight a few:

• People Magazine, written by "reporter" Gabrielle Olya, not only falsely claims Ayyadurai invented email, but says he "holds the patent for creating email." This is all kinds of wrong. He doesn't "hold the patent for creating email." He didn't create email, and he only got a copyright (not a patent) on a program called EMAIL long after email had been created. The People Magazine piece links to the bogus, now retracted, HuffPo story.

• E-Online "reporter" Mike Vulpo falsely calls Ayyadurai "the inventor of email" and also links to the bogus, now retracted HuffPo story. Even more bizarrely, Vulpo links to the now debunked Washington Post articles from a few years ago (which have a huge correction apologizing for the misreporting on Ayyadurai) saying "reports say he holds the copyright to the computer program known as "email." Others say he indeed came up with the term "email" when he was in high school in the late 1970s. Pretty impressive, right?" I love the hedges "reports say" and "others say" while ignoring the fact that his claims to have "invented" email are debunked. And while this is slightly more accurate in noting that he has a copyright in a program called "email," it's not "the" computer program called EMAIL, which falsely implies it was the first one. Even more bizarrely, this same piece was reposted to "NBC Bay Area." You would think, being in the Bay Area, that they might have reached out to folks actually in the tech industry to debunk Ayyadurai's ridiculous claims.

• ABC News / Good Morning America "reporter" Michael Rothman falsely claims that Ayyadurai is the "inventor of email" and makes it even more stupid by saying that Ayyadurai is "widely credited with having invented email." This is not even remotely true. He is only credited with that by himself and a tiny group of friends. Rothman also doesn't appear to understand even the basics of copyright by saying that Ayyadurai is "the first person to hold a copyright for 'EMAIL.'" Again, all he did was write a program called EMAIL, long after email had been invented. It also claims that Ayyadurai "currently teaches at MIT." A search of MIT's staff directory does not actually return Ayyadurai as a current staff member.

• CBS News expands their reputation for skipping over any fact checking by saying Ayyadurai "holds the patent for inventing email." Again, basically everything in that statement is wrong. He doesn't have a patent for inventing email. He got a copyright (very different) on a program called EMAIL. And he didn't invent email. At least CBS News is smart enough not to put a byline on this bogus reporting, but it also quotes the Huffington Post.

• UPI has an article that doesn't mention Ayyadurai's false claims in the text of the article, but does falsely call him "email creator" in the headline (which may not have been written by the reporter who wrote the article).

• The Daily Mail is somewhat famous for its lack of reporting skills and fact checking -- and the publication lives down to its reputation in an article by Chelsea White, which again repeats the myth that Ayyadurai invented email. And while it claims there's "controversy" over the claim (there isn't: everyone except him and his friends know he didn't invent email) it repeats the bogus claim that he has a patent on email: "Dr. Ayyadurai - who owns the patent to email and is often credited as the inventor of the electronic mail system amid some controversy." It also links to the Huffington Post.

• US Magazine "reporter" Madeline Boardman more or less repeats verbatim what others are saying about Ayyadurai being "the inventor" of email and that he is "widely credited" as such.

• Headline and Global News "reporter" Dina Exil repeatedly calls Ayyadurai the inventor of email and also claims he "is known for being the first person to invent email," except none of that is true. He's known for pretending that.

• Popcrush "reporter" Michelle McGahan calls Ayyadurai "the inventor of email" and also falsely claims he "owns the patent for email."

Now, considering that this just some random celebrity gossip, it's not that surprising that these "entertainment reporters" didn't bother to do any sort of fact checking. Why would they? And it's tough to fault them for going for the easy layup on the typical "famous person weds" story. But the problem here is that Ayyadurai has been focused on using any and all press mentions as "evidence" in his bogus campaign to declare himself the inventor of email, and now he has a number of other sources to cite, even though they're all totally wrong.

It is worth noting that not everyone fell for the spin. The LA Times and San Francisco Chronicle both focused mainly on Drescher and more or less ignored Ayyadurai's bogus claims (though, the LA Times does say he's at MIT, which again, does not list him as a current staff member).

The only publications I can find that really called out the bogus claims were Mashable, which noted that Drescher has married someone who "likes to claim he invented email" and Gawker, which noted that if Fran Drescher had actually read its previous articles about Ayyadurai, she might not have married him. What's funny is that in writing our series about the Huffington Post's bogus stories, some of our commenters insisted that this was actually proof as to why these "new media" players weren't trustworthy compared to traditional vetted media. And yet, above we have "trusted" media like ABC and CBS repeating totally false claims, while new media players like Mashable and Gawker are debunking them.

Anyway, I'd like to think this story is now over, but somehow I get the feeling that Ayyadurai will continue to press his bogus claims again and again and again.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 5:52 am

Guy Who Pretends He Invented Email Whines At Every Journalist For Writing Obit Of Guy Who Actually Helped Create Email
from the give-it-up-shiva dept
by Mike Masnick
Tue, Mar 8th 2016 11:40am



Over the years, we've written a few times about Shiva Ayyadurai, a guy who's basically staked his entire life on the misleading to false claim that he "invented" email. Every couple of years he pops up again as he's able to fool some reporters into believing him. In 2012, he fooled the Washington Post and, astoundingly, the Smithsonian. In 2014, he was somehow able to get the Huffington Post to publish a multi-part series claiming he had "invented" email -- though after we called them out on it (and after they stood by it) -- those stories were eventually deleted. Ayyadurai also threatened to sue us for calling out his false claims, but there's been no lawsuit yet.

In those previous stories, we've explained why his claims are false in fairly great detail. Here's the quick version:

First off, no one denies that V.A. Shiva Ayyadurai -- an apparently very bright 14-year-old at the time -- wrote an email software program for the University of Medicine and Dentistry of New Jersey (UMDNJ) in 1978. By all accounts, it was a perfectly decent email system that allowed the UMDNJ staff to send electronic messages. Further, no one doubts that, in 1981, Ayyadurai registered the copyright on his program, which was called EMAIL. The problems are that (1) email was invented long before 1978, (2) the copyright is merely on the specific software code, not the idea of email, and (3) while Ayyadurai may have independently recreated the basics of email (and even added a nice feature), none of his work was even remotely related to what later became the standards of email. What's most sickening about this is that as part of this new PR campaign, Ayyadurai is ridiculously arguing that the reason no one believes him isn't because he's simply wrong, but because they can't stand to believe that "a dark-skinned immigrant kid, 14 years old," invented email, and that it was done in "one of the poorest cities in the US" rather than at a famous university.

Again, that might make for a nice story line if there were some factual basis behind it, but there isn't. The history of email is well-documented from multiple sources and it began way, way before 1978. And while early versions were somewhat crude, by 1978 they had basically everything that Ayyadurai claims to have invented (it is entirely believable that Ayyadurai, as a bright kid, independently came up with the same ideas, but he was hardly the first). There was a messaging system called MAILBOX at MIT in 1965. You can read all the details of it here, including source code. Ray Tomlinson is frequently credited with inventing the modern concept of email for the internet by establishing the @ symbol (in 1972) as a way of determining both the user and which computer to send the email to. By 1975, there were things like email folders (invented by Larry Roberts) and some other basic email apps. As is noted, by 1976 -- two years before Ayyadurai wrote his app -- email was 75% of all ARPANET traffic.

There's also the fact that even if Ayyadurai had done something different at that dental school (and there's no evidence he really did), that had no impact at all on the growth and success of email. No one else built out email systems because of what they saw Ayyadurai build. Email came and grew out of all of that other work (most of which pre-dated Ayyadurai). Hell, just look at RFC 733 from 1977 (before Ayyadurai started working at the school), which basically lays out all of the features of email.


Requests for Comments (RFCs) were simply written documentations, not an email computer program, nor an email system. RFCs were literally meeting notes that recorded the meetings of electronic messaging researchers in the 1970s. As such, this is a flagrant misuse of the term “email”.

For example, sensationalist statements, such as the one by issued by Gizmodo in 2012 stating:

“[E]mail underpinnings were further cemented in 1977's RFC 733, a foundational document of what became the internet itself.”

are, at best misinformed, and completely lack understanding that email was the electronic interoffice mail system. Furthermore, email does not need the Internet to operate. Email systems initially ran on Wide Area Networks (WANs) and Local Area Networks (LANs), independent of the Internet and ARPANET. In fact, even today, one doesn’t need the Internet to run email.

Moreover, RFC 733 was a document to define an attempted standard that was never even fully accepted. The very term “RFC” means “Request for Comments”. It was a document created from meeting notes, and proposed ideas for message format and transmission, but said little about feature sets of individual electronic messaging or mail systems.

As the opening of RFC 733, it states:

“This specification is intended strictly as a definition of what is to be passed between hosts on the ARPANET. It is not intended to dictate either features which systems on the Network are expected to support, or user interfaces to message creating or reading programs.”—

Therefore, RFCs do not demonstrate that email existed prior to 1978. What RFCs demonstrate are that meetings and discussions were taking place on defining methods to exchange text messages, not the creation of email.

-- The Five Myths About Email’s History, by Deborah J. Nightingale, Ph.D.

Despite all of this, Ayyadurai refuses to give up his claims. Part of the way he's tried to get around this is to redefine email to include an increasingly long list of features, most of which are not at all necessary for email. The list changes over time and grows -- basically every time someone points out that all of the things he had on earlier lists were found in programs pre-dating Ayyadurai's own program. Ayyadurai also totally misrepresents what a copyright is, and insists that his copyright is just like a patent, because you couldn't patent software back then. That's basically not true. It is true that most software was not considered patentable back then (even though some was), but that still doesn't make the copyright the equivalent of a patent.

Throughout all of this, Ayyadurai and the weird collection of supporters he's built up -- bizarrely including Noam Chomsky and PR guru Larry Weber -- seemed to keep targeting Ray Tomlinson as some sort of evil mastermind behind the racist plot to take down Ayyadurai, because Tomlinson worked for Raytheon, and Weber, Chomsky and Ayyadurai could spin this bizarre and totally made up story of a big American defense contractor wanting to rewrite history to write out someone with "brown skin."

Tomlinson, as you probably have heard already, passed away this weekend, and received tremendous praise across the internet. Many referred to him as the "inventor of email" even though Tomlinson himself had long insisted that was not true either. Instead, he (unlike Ayyaudurai) long admitted that the growth and success of email involved many people working in pieces, building on each other's work successfully to build out the tool that we all use today. Still, Tomlinson actually does deserve tremendous credit for making email what it is today. The most notable claim -- and the one that everyone rightly talks about -- is his decision to make use of the @ symbol as a part of email addresses, in order to send email messages across networked computers, rather than just on a single machine (as had been done previously).

But, much more importantly, Tomlinson was actively engaged in setting the standards for email, such as in RFC 561 in 1973 (five years before Ayyadurai did anything), in which he and others laid out the standards for email headers.

Given all this, you'd hope that Ayyadurai could let Tomlinson's passing go in peace, and let people celebrate all of the work he did to actually bring email to the world. But, nope. That's not what's happening. Instead, Ayyadurai has gone on a Twitter rampage, tweeting at basically every journalist who has written about Tomlinson, and calling them liars. This is only a small snippet of about 3 hours worth of his tweets.


Most of those are pointing to his "correction" posted to his website, claiming that anyone claiming Tomlinson invented email is wrong. He repeats the false claims about how it only qualifies as email based on his totally arbitrary list of features and also that people who say he's wrong are simply backing up Raytheon trying to deny him his rightful due because he's "not white." And, amazingly, he's actually convinced some publications to write about his claim, with very little fact checking. Meanwhile, when some point out that he's lying, Ayyadurai yells at them that they're repeating "racist lies," despite the fact that all of the evidence is well-documented.

Once again, to Shiva Ayyadurai: you were almost certainly a very bright kid, who created a nice software program as a teenager at the school where you were employed. That's great. And you should be proud of your accomplishments. But you did not invent email. You had nothing to do with the invention of email. And to continue to claim otherwise makes you look petty and silly -- especially at a time when everyone is celebrating the very real accomplishment of Ray Tomlinson.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 6:37 am

Guy Who Didn't Invent Email Sues Gawker For Pointing Out He Didn't Invent Email
from the shiva,-you-ain't-hulk-hogan,-either dept
by Mike Masnick
Wed, May 11th 2016 10:44am



Oh boy. Remember Shiva Ayyadurai? The guy who has gone to great lengths to claim that he "invented email," when the reality is that he appears to have (likely independently) written an early implementation of email long after others had actually "invented email." In the past we've called out examples where gullible press have fallen for his easily debunked claims, but he keeps popping back up. He somehow got an entire series into the Huffington Post, which was clearly crafted as a PR exercise in trying to rewrite history. The mainstream press repeated his bogus claims about inventing email after he married a TV star. And, most recently, he decided to scream at the press for memorializing Ray Tomlinson -- someone who actually did have a hand in creating email -- upon his death.

We've gone through in great detail as to why Ayyadurai is simply wrong in his claims. There's a lot more to it, but the summary we've written in the past is this:

First off, no one denies that V.A. Shiva Ayyadurai -- an apparently very bright 14-year-old at the time -- wrote an email software program for the University of Medicine and Dentistry of New Jersey (UMDNJ) in 1978. By all accounts, it was a perfectly decent email system that allowed the UMDNJ staff to send electronic messages. Further, no one doubts that, in 1981, Ayyadurai registered the copyright on his program, which was called EMAIL. The problems are that (1) email was invented long before 1978, (2) the copyright is merely on the specific software code, not the idea of email, and (3) while Ayyadurai may have independently recreated the basics of email (and even added a nice feature), none of his work was even remotely related to what later became the standards of email. What's most sickening about this is that as part of this new PR campaign, Ayyadurai is ridiculously arguing that the reason no one believes him isn't because he's simply wrong, but because they can't stand to believe that "a dark-skinned immigrant kid, 14 years old," invented email, and that it was done in "one of the poorest cities in the US" rather than at a famous university.

Again, that might make for a nice story line if there were some factual basis behind it, but there isn't. The history of email is well-documented from multiple sources and it began way, way before 1978. And while early versions were somewhat crude, by 1978 they had basically everything that Ayyadurai claims to have invented (it is entirely believable that Ayyadurai, as a bright kid, independently came up with the same ideas, but he was hardly the first). There was a messaging system called MAILBOX at MIT in 1965. You can read all the details of it here, including source code. Ray Tomlinson is frequently credited with inventing the modern concept of email for the internet by establishing the @ symbol (in 1972) as a way of determining both the user and which computer to send the email to. By 1975, there were things like email folders (invented by Larry Roberts) and some other basic email apps. As is noted, by 1976 -- two years before Ayyadurai wrote his app -- email was 75% of all ARPANET traffic.

For what it's worth, some have disputed the idea that he even added any features not existing in previous discussions. Nevertheless, he's not the "inventor" of email, no matter how many times he claims he is.

We, of course, have not been alone in debunking his claims. Back in 2012, a few weeks after we first debunked them, Gawker's Sam Biddle did a long and thorough takedown of Ayyadurai's claims. Apparently that story really angers Ayyadurai, and I'm guessing that seeing Hulk Hogan win his crazy lawsuit against Gawker helped Ayyadurai to decide to sue Gawker as well.

And, in keeping with my belief that this is all one giant PR stunt, the lawsuit filing was accompanied by a press release that repeats the same debunked claims, and selectively quotes the very media he fooled as evidence that he really invented email. The actual lawsuit is a joke. As in the Hogan case, Ayyadurai is suing not just Gawker, but also the company's founder Nick Denton, along with the author of the articles (in this case, Sam Biddle).

The filing again lays out Ayyadurai's highly misleading version of history, insisting again that getting the copyright on a program called EMAIL is the equivalent of "inventing" email. He continues to conflate patent and copyright law and misleadingly claim that because you couldn't get a patent on software at the time, a copyright is basically the same thing. This is wrong on both counts. You could patent some software at the time, and either way a copyright is nowhere near the equivalent.

19. At the time of Dr. Ayyadurai’s invention of email, software inventions could not be protected through software patents. It was not until 1994 that the United States Court of Appeals for the Federal Circuit ruled that computer programs were patentable as the equivalent of a “digital machine.” However, the Computer Software Act of 1980 allowed software inventions to be protected to a certain extent, by copyright. Therefore, in or about 1981, Dr. Ayyadurai registered his invention with the U.S. Copyright Office. On August 30, 1982, Dr. Ayyadurai was legally recognized by the United States government as the inventor of email through the issuance of the first Copyright registration for “Email,” “Computer Program for Electronic Mail System.” With that U.S. Copyright of the system, the word “email” entered the English language.1

-- Shiva Ayyadurai, Plaintiff, vs. Gawker Media, LLC, Sam Biddle, John Cook, Nicholas Guido Anthony Denton, Defendants

He also relies on debunked reports in Time Magazine and CBS. And also Wired, though he leaves out that Wired was just quoting Noam Chomsky, who bizarrely has become one of Ayyadurai's biggest defenders, and that the Wired story includes other evidence that Ayyadurai is wrong.

21. On or about November 15, 2011, TIME magazine published an article titled “The Man Who Invented Email,” which outlines the history of email and Dr. Ayyadurai’s invention. The article states that “email – as we currently know it – was born” when Dr. Ayyadurai created it replicating an interoffice mail system at the University of Medicine and Dentistry in Newark, New Jersey. The article states that “the original system was set up for doctors to communicate electronically using the [physical] template they were already used to” and the interface “hasn’t changed all that much” in becoming the email system we know and use today. The TIME article also states that in “1981, Shiva took honors at the Westinghouse Science Awards for his ‘High Reliability, Network-Wide, Electronic Mail System’” and that in 1982 he “won a White House competition for developing a system to automatically analyze and sort email messages.”

22. In June 2012, Wired magazine reported that: “Email … the electronic version of the interoffice, inter-organizational mail system, the email we all experience today, was invented in 1978 by [Dr. Ayyadurai] …. The facts are indisputable.”

23. In July 2015, CBS reported on The Henry Ford Innovation Nation, hosted by Mo Rocca: “Next time your fingers hit the keyboard to write a quick email, you might want to say, thank you to Shiva Ayyadurai.... he is credited with inventing email…. in the late 1970s.”

-- Shiva Ayyadurai, Plaintiff, vs. Gawker Media, LLC, Sam Biddle, John Cook, Nicholas Guido Anthony Denton, Defendants

Ayyadurai claims that Gawker's articles were defamatory, specifically stating:

As described herein, the February 2012 Article arises to the level of defamation per se, in that it falsely states that “[Dr.] Ayyadurai is a fraud.”

As described herein, the March 2012 Article falsely alleges that:

a) Dr. Ayyadurai engaged in “semantic tricks, falsehoods, and a misinformation campaign.”

b) Dr. Ayyadurai is engaged in “revisionism” in his claim of invention of email.

As described herein, the 2014 Article arises to the level of defamation per se, by stating that Dr. Ayyadurai is a “fraud,” thus falsely accusing Dr. Ayyadurai of a crime and causing prejudice to his personal and professional reputation and business.

The 2014 Article also falsely states:

a) Dr. Ayyadurai is a “renowned liar” with respect to his statements that he invented email,

b) Dr. Ayyadurai is a “big fake,” and

c) Dr. Ayyadurai is engaged in “cyber-lies.”

These defamation claims seem extremely weak. First off, as the detailed records show, Ayyadurai did not invent email. So truth is generally a good response to defamation claims. Second, even if he did create email (and he didn't), most of these statements would be protected as either statements of opinion or rhetorical hyperbole. Finally, Ayyadurai as a self-proclaimed public persona would have to show actual malice for it to be defamatory. Hilariously, the lawsuit claims no actual malice is necessary, which is nonsense. Ayyadurai is so focused on making himself a famous person over his exaggerated claims to have invented email that for him to try to argue he's not a public figure is laughable. His lawyers also show no evidence that there is actual malice from Gawker but insist that if they could get to the discovery phase, they could find evidence supporting actual malice.

72. The 2014 Article also falsely states:

a) Dr. Ayyadurai is a “renowned liar” with respect to his statements that he invented email,

b) Dr. Ayyadurai is a “big fake,” and

c) Dr. Ayyadurai is engaged in “cyber-lies.”

73. These false statements wrongly accuse Dr. Ayyadurai of having made statements and acted in a manner that would subject him to hatred, distrust, contempt, aversion, ridicule and disgrace in the minds of a substantial number in the community, and were calculated to harm his social and business relationships, and did harm his social and business relationships.

74. The statements made intentionally, purposefully and with actual malice by Defendants were false and no applicable privilege or authorization protecting the statements can attach to them.

75. Plaintiff has been seriously damaged as a direct and proximate cause of the falsity of the statements made by Defendants in an amount to be determined at trial. The false statements attribute conduct, characteristics and conditions incompatible with the proper exercise of Plaintiff’s business and duties as an inventor, scientist and entrepreneur. Because the statements were widely disseminated on the Internet, they were also likely and intended to hold the Plaintiff up to ridicule and to damage his social and business relationships.

76. The above-quoted published statements constitute egregious conduct constituting moral turpitude. As such, in addition to compensatory damages and/or presumed damages, Plaintiff demands punitive damages relating to Defendants’ making of the above-quoted defamatory statements, in an amount to be determined at trial.

-- Shiva Ayyadurai, Plaintiff, vs. Gawker Media, LLC, Sam Biddle, John Cook, Nicholas Guido Anthony Denton, Defendants

There are then three other claims: one for "intentional interference with prospective economic advantage," one for "intentional infliction of emotional distress" (the "my feelz!" argument), and one for (and I'm not kidding) "negligent hiring and retention."

Ayyadurai goes into detail about how people pointing out that he is exaggerating his claims has made people less willing to work with him. But that's not the fault of accurate reporting. It's the fault of him focusing so much on a false claim to have invented email.

This is the situation here: Defendants’ false statements in the articles at issue had the effect of so severely discrediting Dr. Ayyadurai—based on the false statement that he is a “fraud”—that Dr. Ayyadurai’s career was severely damaged. As a direct result of Defendants’ publication of the false and defamatory statements about Dr. Ayyadurai, on information and belief, Dr. Ayyadurai has lost teaching positions at MIT, lost several paid speaking engagements at the time and in the future, lost an accolade and display dedicated to his invention at the Smithsonian Institute, lost contracts and renewals, lost opportunities for investment in his emerging companies, suffered substantial personal and professional reputational harm, and suffered substantial harm to his career, business and income.

I'm sure that's distressing, but it's not the fault of Gawker for pointing out that Ayyadurai was exaggerating what he did. It's what happens when you exaggerate like that and make grandiose claims that are not accurate.

The "negligent hiring" claims seems to just be an attempt to attack and mock Sam Biddle. I'm not a Sam Biddle fan by any stretch of the imagination. I think he has a history of taking things completely out of context and creating sensational posts that are misleading, at best. But that's not defamation. It's just bad reporting. And Ayyadurai's claims about "negligent hiring" basically accuse Biddle of being a drug addict and, potentially, mentally unstable. That claim is not going to last very long and seems to serve no purpose other than to attack Biddle's reputation.

The filing also spends a ton of completely wasted space on other lawsuits against Gawker, as if trying to prove that the company has a history of bad actions. But the litany of bad actions listed are extremely exaggerated. Yes, Gawker has been sued for defamation, but Gawker has not lost those cases and they are extremely unlikely to lose them. I mean, you're reaching really, really low if you're citing Chuck Johnson's laughable defamation lawsuit against Gawker that has already been tossed out of a Missouri court for being ridiculous. And yes, Johnson also filed an identical case in California, but it's going nowhere (it was so identical that it focused on the harms in Missouri, despite being filed in California). But Ayyadurai's lawyers pretend that it's evidence of Gawker's defamatory history:

Gawker has been sued multiple times for defamation, including currently in an action in New York State Court, by the Daily Mail newspaper, and in an action in California by an individual named Charles Johnson, for writing and publishing false and unsubstantiated rumors that Mr. Johnson had been involved in misconduct and criminal activity.

The lawsuit also cites a variety of other lawsuits involving Gawker that have nothing to do with defamation at all, including (obviously) the Hulk Hogan case that will almost certainly be overturned on appeal, and also a copyright lawsuit from Dr. Phil and a few other examples of people being unhappy with Gawker's coverage.

This case should go nowhere fast, and Ayyadurai may be opening himself up to a world of hurt in exposing himself to discovery, should the case even reach that stage. Unfortunately for Gawker, Massachusetts -- where Ayyadurai filed this lawsuit -- has an anti-SLAPP statute that is much more limited and unfortunately may not be that helpful to Gawker. Yet another reason why we need a federal anti-SLAPP law as soon as possible.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am

Re: Shiva Ayyadurai suing TechDirt over Stories Saying He Di

Postby admin » Tue Feb 14, 2017 6:42 am

Univision Execs Have No Backbone: Pull A Bunch Of Gawker Stories Over Legal Disputes
from the no-credibility dept
by Mike Masnick
Mon, Sep 12th 2016 6:27am



People celebrating the "demise" of Gawker in being forced into bankruptcy by a questionable lawsuit and ruling from Hulk Hogan, financed by Peter Thiel, keep insisting that it has no real impact on the freedom of the press. And yet... things keep showing that's wrong. Gawker filed for bankruptcy and sold off its assets to media giant Univision, which agreed to close down the flagship Gawker site and redistribute some of the reporters to other sites. But late Friday, Univision management made another decision, and this one is horrific: they agreed to delete six stories on the site (with a seventh one being considered) because those stories were the subject of lawsuits against Gawker.

The reasoning given by Univision is that it only agreed to buy the assets of Gawker, not the liabilities, and keeping those stories posted gave it liability. First of all, this is wrong on the legal side of things. As Gawker's executive editor, John Cook (who fought this decision) notes, Univision doesn't take on the liability here:

Though the posts were published by Gawker Media, and therefore under the so-called “first publication rule” should only be the legal responsibility of the Gawker Media estate being left behind in the transaction, Unimoda’s legal analysis was that the continued publication of the posts under the new entity would constitute the adoption of liability, and that Unimoda is therefore obligated to delete them.

But that's not the most disturbing thing here. The really problematic issue is that the stories that are being removed involve stories where the lawsuits are almost entirely completely bogus SLAPP suits designed to annoy Gawker, rather than with any serious legal basis -- for example, the two stories that Gawker published about Shiva Ayyadurai, the guy who keeps trying to convince the world that he invented email when he didn't. We've discussed Ayyadurai and his bogus claims many times, and also covered the lawsuit. There is no legitimate reason to take down those posts.

Perhaps even more incredible is that Univision also agreed to take down the story that nutty troll Chuck C. Johnson had filed a lawsuit against Gawker. That's a lawsuit that is so ridiculous it was laughed out of court in Missouri. And while Johnson filed a nearly identical lawsuit (including references to Missouri) in California, it was similarly going nowhere, and Johnson recently said that he'd dropped the case.

And yet Univision voted to delete the story anyway.

This is... bad. It's one thing to make a decision to pull a story once you've analyzed the situation and decided that the story has problems and should be pulled. But that's not what happened here. Univision execs flat out told Cook that this was solely about not taking on the liability. In other words, Univision has absolutely zero backbone to stand up for its journalists. That's shameful.

This move basically immediately does two things. First, it alerts anyone who wants a heckler's veto to threaten Univision with a lawsuit. Second, it should immediately cause any good journalist working for Univision or its properties (including Gawker and Fusion) to start looking for a new job elsewhere. If you can't have your publisher back you up on things like this, that's a dangerous place for a reporter to work. Kudos to Cook for trying to stand up to Univision, but if those execs wouldn't listen to him, the company's got really big problems.

I communicated to Felipe and Jay in the strongest terms that deleting these posts is a mistake, and that disappearing true posts about public figures simply because they have been targeted by a lawyer who conspired with a vindictive billionaire to destroy this company is an affront to the very editorial ethos that has made us successful enough to be worth acquiring. I told them that I am proud that this company refused to delete its accurate posts about Shiva Ayudurrai’s false claim to have invented the email system of communication, and that I am proud that our decision not to take down accurate posts about Mitch Williams’ meltdown at a children’s baseball game was vindicated by a federal judge, who ruled in our favor in his case against us. I am mortified to see them taken down now. We are at the center of an unprecedented assault on the ability of reporters and editors to challenge and critique public figures. While I believe that Univision is a company that values and defends aggressive, independent reporting, the decision to remove these posts is, in my view, at odds with its tradition of confronting bullies with honesty.

Univision just did a big thing badly. And it sullies the company's reputation and brand, and it makes all of the company's remaining journalistic staff look bad.

And, of course, this is the internet, where trying to make stuff disappear never works. I went over to soon after the announcement came out (and before the stories had been taken down) and every single one had been re-archived (many had been previously archived) within the previous hour. So if you're curious what was in the stories too hot for Univision's backboneless execs, here they are:

The Inventor of Email Did Not Invent Email?
Corruption, Lies, and Death Threats: The Crazy Story of the Man Who Pretended to Invent Email
Man Acquitted Of Sexual Assault Sues Blog For Calling Him Serial Rapist
Wait, Did Clowntroll Blogger Chuck Johnson Shit On The Floor One Time?
Uber Driver in California Will Be Considered Employee, Not Contractor
Mitch Williams Ejected From Child's Baseball Game For Arguing, Cursing
Witnesses: Mitch Williams Called Child "A Pussy," Ordered Beanball

This is why we need publications that don't back down in the face of SLAPP suits. This is why we need stronger anti-SLAPP laws (and a federal anti-SLAPP law). This is why we express concerns about billionaires ganging up to sue publications out of existence in a vengeance play. Publications are vulnerable, but they're supposed to stand up to bogus threats, not cave in out of fear.
Site Admin
Posts: 17163
Joined: Thu Aug 01, 2013 5:21 am


Return to A Growing Corpus of Analytical Materials

Who is online

Users browsing this forum: Bing [Bot] and 2 guests