[ih] IPv8...

[Greg Skinner]

On Apr 18, 2026, at 6:15 PM, Jack Haverty via Internet-history <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