[ih] IPv8...

Sun Apr 19 14:13:57 PDT 2026

On Apr 19, 2026, at 3:34 AM, Vint Cerf <vint at google.com> wrote:
> 
> From Gemini:
> 
> J.C.R. Licklider, often called the "Computing's Johnny Appleseed," didn't just view electronic mail as a digital version of a post office. In his seminal 1968 paper, "The Computer as a Communication Device" (co-authored with Robert Taylor), he envisioned a future where email was the backbone of collaborative intelligence.
> 
> Licklider’s scenarios for electronic mail weren't just about moving text; they were about distributed thinking. Here are the key scenarios and concepts he outlined:
> 
> 1. The "OLIVER" (Automated Digital Assistants)
> One of Licklider’s most prophetic scenarios involved what he called the OLIVER (On-Line Interactive Vicarious Expediter and Responder).
> 
> The Scenario: He imagined a personalized program that would reside in the network to handle your mail.
> 
> The Function: The OLIVER would screen incoming messages, reply to routine inquiries on your behalf, and prioritize important data. This is essentially the 1960s vision of AI-driven inbox management and automated responders.
> 
> 2. Communities of Common Interest
> Licklider predicted that electronic mail would destroy the tyranny of geography.
> 
> The Scenario: He argued that people would no longer be grouped by where they lived, but by what they cared about.
> 
> The Impact: He foresaw "online interactive communities" where specialists across the globe could exchange ideas instantly. To Licklider, email was the "glue" that would hold these non-geographic communities together.
> 
> 3. Collaborative "Modeling"
> For Licklider, communication wasn't just sending a message; it was about cooperation.
> 
> The Scenario: He envisioned two researchers using the network to work on a shared "model" (data or a simulation).
> 
> The Function: Email and network messaging would allow people to send not just words, but executable programs and data sets. One person could "mail" a piece of code, and the receiver could run it immediately to see the sender’s logic.
> 
> 4. Asynchronous Problem Solving
> He recognized that human schedules are messy.
> 
> The Scenario: Licklider saw electronic mail as a way to facilitate "interpersonal communication" without requiring both parties to be present at the same time.
> 
> The Value: This would allow for a "more thoughtful and better-documented" exchange than a telephone call, as users could take time to research a response before sending it back through the system.
> 
> 5. The "Information Utility"
> Licklider compared the future of electronic communication to a public utility, like electricity or water.
> 
> The Scenario: He imagined a world where everyone—not just scientists—had a terminal at home.
> 
> The Daily Use: People would use the "mail" system to check bank balances, schedule appointments, and engage in "the creative process" of social interaction.
> 
> Summary of Licklider’s Vision
> Feature	Licklider's Prediction	Modern Equivalent
> Medium	"The message is the model"	Shared Google Docs / GitHub
> Agent	The OLIVER	AI Assistants (Copilot, Gemini)
> Geography	"Communities of interest"	Subreddits / Discord / Slack
> Speed	"Interactive but asynchronous"	Modern Email / Threaded messaging
> "In a few years, men will be able to communicate more effectively through a machine than face to face."
> 
> — J.C.R. Licklider, 1968
> 
> Licklider’s genius was realizing that the computer wasn't a "giant brain" meant for calculating trajectories, but a medium meant for connecting human minds.
> 
> 

Thanks for the scenarios.  I probably should have been more specific.  I was hoping Jack would give examples of what he wrote on those mailing lists that he considered to be scenarios based on Lick’s visions.  That way, we could make some comparisons between the way that was done and how it’s done on IETF lists today.  Since in his response to Tony he mentioned email archives which are probably lost by now, I thought the header-people and msggroup lists, both of which have survived (mostly), might at least give some idea of how those scenarios were discussed.

I am not an email guru, so my assessments are based on a cursory glance at some IETF lists that are about email standards.  There is a list called ietf-822 that seems similar to the header-people and msggroup lists, in the sense that its participants bring scenarios to the discussions.  [1] But ietf-822 is not a working group list.  There are some other lists such as emailcore and mailmaint that are working group lists. [2] [3] The discussions are more focused on getting drafts ready for publication, making use of more specific information, such as use cases.  In my experience, use cases are more concrete, thus more of an aid to getting drafts publication-ready.

--gregbo

[1] https://mailarchive.ietf.org/arch/browse/ietf-822/ 
[2] https://mailarchive.ietf.org/arch/browse/emailcore/
[3] https://mailarchive.ietf.org/arch/browse/mailmaint/

> On Sun, Apr 19, 2026 at 3:13 AM Greg Skinner via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> On Apr 18, 2026, at 6:15 PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> > 
>> > On 4/18/26 14:38, Tony Li wrote:
>> >> Hi Jack,
>> >> 
>> >>> Somewhere in the timeline of Internet History, the notion of scenarios as drivers of technical choices must have disappeared.
>> >> No, not at all.  In fact, it’s hard to get any solution through the IETF anymore without an independent “use cases” document.
>> >> 
>> >> Regards,
>> >> Tony
>> >> 
>> > "Use Cases" and "Scenarios" are different things.   Both are needed.
>> > 
>> > My understanding of "Use Cases" is that they serve to show how some particular technology (protocol, algorithm, whatever) can be actually used in the Internet.  In other words, they are driven from the technology side, explaining how a technology could be used.
>> > 
>> > In contrast, "Scenarios" are driven from the end-users' perspective.  They capture things that the end users need to be able to do, given the overall system of technologies that exist at the time.  The C3I scenario I described earlier captured one example of what the aggregate of military end-users needed to do, using the Internet to provide the communications infrastructure.   If there was a technological piece still missing, the scenario was not possible.
>> > 
>> > A particular technology may be useful and even necessary.  But by itself it is likely insufficient to actually enable any but the simplest end-users' scenarios.  Other technologies may also be needed before a particular scenario is workable.   Sometimes many technologies have to exist and work together.
>> > 
>> > It's also conceivable that some particular decision of a technology precludes ever reaching the goal of enabling a scenario.  A particular technology decision with a "use case" may rule out approaches to other technology issues that must also exist to enable the scenario.
>> > 
>> > In the C3I example I described, lots of technology advances seemed to be likely needed.  Routing algorithms almost certainly needed to evolve.  Congestion and flow control likely needed changes too.  In military contexts, security was always a requirement.   Techniques for prioritizing traffic flows were likely needed.  Techniques for compressing large documents, voice streams, et al had to be created.  Etc.   To meet the needs of the scenario, all the technical pieces had to exist and work together.
>> > 
>> > I first encountered "scenarios" while I was a student, in Professor Licklider's group at MIT.  Lick was my adviser and later boss for several years in the 1970s.  About ten years earlier, Lick had written memos about his vision of a "galactic network" in which computers were available to humans everywhere, and were somehow interconnected so that they could communicate with each other.
>> > 
>> > Lick's training was in psychology, so he thought from the human's end-user point of view.  He described the "scenario" of his "galactic network" vision as "computers everywhere helping humans do everything that humans do."  He understood that such a scenario was a bit too vague to serve as a specification.   But for a vision that was OK, and could serve to create other more detailed scenarios -- like the military ones.
>> > 
>> > In the mid-70s, one of the network research topics focussed on what came to be called email on the ARPANET.  I recall lots of discussions with Lick and many others to define relevant and more detailed scenarios.  Lick's vision was broad, encompassing all sorts of human-human communication.  Emails might be short notes or massive documents.  They might be urgent, and require mechanisms for tracking through delivery.  They might be multi-media, perhaps starting as text communications, switching to conversational voice, and even evolving into an interactive conferencing session using text and/or voice (video was just too hard to think about in the 1970s).  Interactions could be saved (such as on the "Datacomputer", which did exist on the ARPANET and our email system used it).  Long "conversations" could be related to each other as something like today's email "threads" and "forums".  Some communications might have to be private, protected from prying eyes along the way.  Some might need to have the author, and/or recipients, verified so that you could believe what you saw or heard came from where you thought it came from.   Some might be routed through a kind of "escrow agent", who could later independently testify that a document was real and had been authored, created, delivered, and handled at particular points in time.  The scenario for comprehensive human-human communications was very complex.
>> > 
>> > We developed a rudimentary technical architecture for such a scenario, to at least serve as a starting point while computer technology advanced and more things became feasible.    Sadly it was probably never captured in any form more permanent than email archives, which are probably lost by now.  Lots of technologies would be needed.   It would take a while.   Research does.
>> > 
>> > That human-human communications architecture was shelved by ARPA in the mid-1970s in favor of a much simpler approach, to provide an interim solution that we now would all recognize as today's electronic mail.   I think Lick's scenario is still a good target, but I don't think anyone's been working on it for the last 50 years.
>> > 
>> > Anyway, I hope that explains the concept of "Scenario".....
>> > 
>> > /Jack Haverty
>> > 
>> 
>> Jack, you contributed regularly to the header-people and msggroup mailing lists, most of which are still available.  If you have time, can you review some of what you wrote about, and identify topics that reflected Lick’s vision of what human-human communication could be, based on scenarios?  Offhand, I did see one in which you posted an example of how in the military, messages were required to be from the commander, with an address distinct from a person. [3]
>> 
>> --gregbo
>> 
>> [1] https://web.archive.org/web/20241123091106/http://www.chiappa.net/~jnc/tech/header/
>> [2] https://web.archive.org/web/20241123091106/http://www.chiappa.net/~jnc/tech/msggroup/
>> [3] https://web.archive.org/web/20250121110700/http://mercury.lcs.mit.edu/~jnc/tech/msggroup/msggroup0401-0500.txt
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
> 
> 
> 
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 