[ih] Internet-history Digest, Vol 69, Issue 11

[vinton cerf]

 again from Gemini:


the Defense Messaging System (DMS) was based on the *X.400* international
standard for secure electronic messaging.

The DMS was developed by the U.S. Department of Defense (DoD) to replace
the older, less flexible AUTODIN network. To achieve its goal of a modern,
interoperable, and secure message handling system, the DoD chose to build
DMS on top of existing commercial standards, primarily the Open Systems
Interconnection (OSI) standards.

Specifically, DMS utilized a suite of OSI protocols:


   -

   *X.400* for its message handling services. This protocol provides a
   robust "store-and-forward" system for transmitting messages and is known
   for its advanced addressing and security capabilities.

   -

   *X.500* for its directory services, which provided a way to look up and
   manage user information within the network.

   -

   *X.509* for its public key certificates, which were crucial for
   security, identity verification, and encryption.


On Sat, Aug 16, 2025 at 9:59 PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> Gemini didn't catch some Internet-related aspects of History.
>
> AUTODIN encountered the ARPANET in the mid 1970s.  There was a program
> called the "Military Message Experiment" (MME), intended to evaluate the
> possibility of providing AUTODIN functionality but using the ARPANET.
> It resulted in an actual experiment using military personnel.  The
> after-action report is available at
> https://archive.org/stream/DTIC_ADA155585/DTIC_ADA155585_djvu.txt
>
> I was in Lick's group at MIT during that time, and we were implementing
> electronic mail, so we got involved in the MME.
>
> There were quite a few functions present in AUTODIN that weren't of much
> interest to the ARPANET research community.  AUTODIN messages had
> security markings.   They also had various levels of "priority", such as
> ROUTINE, FLASH, FLASH OVERRIDE, et al, which dictated how messages
> should be handled.  They had notions of "workflow", in which various
> people in the command chain had to approve ("chop") a message before it
> could actually be transmitted.
>
> Most of such features weren't available in the ARPANET email systems of
> the era, and there was a strong desire in the community to keep email
> things simple.  With Lick's oversight and Al Vezza's pressure, we tried
> to get appropriate primitives for AUTODIN added into the email protocols
> but mostly failed to reach "rough consensus and running code."
>
> One of the artifacts which you can still see today (e.g., in this
> message) is the "Message-ID:" field which appears if your system lets
> you view the full header of today's emails.  I lobbied hard to get that
> included in the ARPANET mail header specs, so that it could be used for
> functions such as tracking messages as they passed through an approval
> chain, linking together replies, and other such functionality.  We
> viewed the message header as a poor place to keep all that metadata.
>
> AUTODIN was due for replacement in the 1980s by AUTODIN II, with a
> typical big government contractor expected to be awarded the contract.
> After much outside pressure from ARPA and others, BBN reluctantly
> submitted a proposal, to use the ARPANET technology as the replacement
> for AUTODIN.
>
> We submitted what was probably the largest proposal BBN ever did. We
> were surprised to receive an acknowledgement from the government
> congratulating us for the brevity of our proposal.  All the other bids
> were much more verbose, with lots of foldout color diagrams and such stuff.
>
> Our surprise turned to shock when we learned that we had won the
> contract.   BBN had recently reorganized, and the contract landed in our
> new division.   Since I was the one with the more "operational"
> interest, I became the first program manager for the new DDN contract.
> That seemed like a full time job, involving lots of paper pushing which
> wasn't very interesting.  So we hired someone from a big government
> contractor to run the contract.  He quickly observed that it was much
> more than a full time job, and created a DDN Program Office at BBN, with
> lots of staff to handle all of the contract paperwork, scheduling,
> reports, and such stuff.  Whew, I escaped that one.
>
> Autodin II had become the Defense Data Network, and was basically a
> larger clone of the proven ARPANET technology.
>
> As part of a "System Engineering" task, we helped get various
> applications running on the DDN.  One I recall was a "mail gateway" for
> the US Army in Europe, used for communicating between Army supply
> officers and vendors out in the public world in Europe.  That was how
> things like toilet paper were purchased for the various military bases.
>
> That "gateway" was extremely low tech.  A soldier was stationed at a
> desk, with two terminals.  One terminal was on the "inside" mail system,
> where security was highly important.  The other terminal was on the
> "public" network (X.25 probably), where all the vendors were
> accessible.  The soldier would retype messages to pass them "through"
> the gateway.
>
> The Defense Message System (DMS) apparently happened after I had moved
> into the networked database world in the 1990s.   So I don't know much
> about DMS.  I wonder if the security, priority, and other issues
> surfaced in the 1970s Experiment were solved in the DMS deployment.
>
> In any event, there was a lot of AUTODIN DNA in the Internet History.
>
> Jack Haverty
>
> On 8/16/25 14:25, vinton cerf via Internet-history wrote:
> > one might also check the timeline for AUTODIN
> >
> > from gemini:
> >
> > The *Automatic Digital Network (AUTODIN)* was built between 1959 and
> 1963,
> > with its initial operational phase beginning in 1962. It was officially
> > declared fully operational in February 1963.
> >
> > The system was originally designed as the "Combat Logistics Network"
> > (ComLogNet) to handle the U.S. Air Force's logistics challenges. In 1962,
> > the U.S. Department of Defense realized its broader value and transferred
> > it to the Defense Communications Agency, renaming it AUTODIN.
> >
> > The initial network consisted of five switching centers in the United
> > States, with a global expansion beginning in 1966. AUTODIN remained a
> > primary communication system for the DoD until it was replaced by the
> > Defense Message System (DMS) in the late 1990s and early 2000s.
> >
> > On Sat, Aug 16, 2025 at 5:18 PM John Shoch via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> My friends at the Computer History Museum always warn me about declaring
> >> "firsts":
> >> a.  you better get the facts absolutely correct, and
> >> b.  you better be fanatically precise in defining the terms (every noun,
> >> every adjective, etc.) -- and you better include the definitions.
> >>
> >> The UCLA statement which started this exchange lacks both -- thus,
> almost
> >> by definition, it is ambiguous and imprecise (and thus probably wrong).
> >>
> >> Efforts at NPL and Sage are certainly worth looking at.
> >>
> >> In addition, there was earlier work at SDC -- apparently in 1963 w/SRI,
> and
> >> ca. 1966 with MIT Lincoln Labs.  I will make no judgement about any
> >> "firsts" but let me bring to everyone's attention a couple of items:
> >>
> >> --There is an interesting and comprehensive historical look at this Q-32
> >> work in a paper by David Hemmendinger, published in 2016:
> >> "Two Early Interactive Computer Network Experiments."
> >>
> https://www.computer.org/csdl/magazine/an/2016/03/man2016030012/13rRUwciPgt
> >> You can also access it at:
> >> https://cs.union.edu/~hemmendd/History/network6.pdf --In that paper
> >> he discusses an experiment in 1963 between SRI and SDC. At that time
> >> Lick had taken over ARPA/IPTO, and ARPA had taken over the Sage Q-32
> >> prototype that had been built for Sage at SDC. Lick wanted SRI to
> >> connect to the Q-32. Doug Engelbart described the work at the History
> >> of Workstations conference in 1986 [I spoke at the conference, and
> >> heard Doug's talk, but 40 years later I do not remember these
> >> comments]: https://dl.acm.org/doi/pdf/10.1145/61975.66918 "Lick moved
> very swiftly. By early 1963 we had a funded project. But,
> >> whereas I had proposed using a local computer and building an
> interactive
> >> workstation, Lick asked us instead to connect a display to the System
> >> Development Corporation's (SDC's) AN/FSQ32 computer, on site in Santa
> >> Monica, to do our experimenting under the Q32's projected new
> time-sharing
> >> system. (Converting the Q32 to be a timeshared machine was SDC's IPTO
> >> project.) Later that year, our project was modified to include an online
> >> data link from Menlo Park to Santa Monica, with a CDC 160A minicomputer
> at
> >> our end for a communication manager, supporting our small-display
> >> workstation."
> >>
> >> --Hemmendinger also discusses the more well-known work several years
> later,
> >> ca. 1966, by Tom Marill (at CCA) and Larry Roberts (at MIT) to connect
> the
> >> TX-2 to the Q-32 machine at SDC.
> >>
> >> --There seems to have been a CCA Technical Report in mid-1966, but I
> have
> >> never seen it;  Hemmendinger cites it as:
> >> T. Marill, "A Cooperative Network of Time-Sharing Computers: Preliminary
> >> Study," Technical Report No. 11, Computer Corporation of America,
> >> Cambridge, Mass. (1966).
> >> The preliminary study is also cited in a bibliography about the Arpanet:
> >> https://apps.dtic.mil/sti/tr/pdf/ADA026900.pdf
> >> Marill, T. A cooperative network of time-sharing computers: preliminary
> >> study. Cambridge, Ma., Computer Corporation of America, I Jun 66. 53 p.
> >> CCA-TR1-1 NIC 06458.  [Is this an SRI NIC identifier?]
> >>
> >> --The Preliminary Report may have been a predecessor or an early draft
> or a
> >> pre-print of a paper published later that year, to which Larry Roberts
> is
> >> added as a co-author:
> >> Thomas Marill and Lawrence G. Roberts, “Toward a cooperative network of
> >> time-shared computers” in Proceedings of the AFIPS Fall Joint Computer
> >> Conference, pp. 425-431, ACM, New York, NY (November, 1966).
> >> https://dl.acm.org/doi/10.1145/1464291.1464336
> >>
> >> --Some interesting highlights from the paper:
> >> --They talk in passing about shipping programs from one machine to
> another,
> >> but then focus only on providing remote terminal access -- from a
> terminal
> >> on one computer, through a "network" to a program running on another
> >> computer.
> >> --An "elementary" model merely routes characters from a user's terminal
> >> through to the local machine, and then out another terminal link to the
> >> distant machine.  This requires no modifications at either end, but
> runs at
> >> terminal speeds.
> >> --They then expand the model:  "Thus, a possible alternative technique
> for
> >> achieving increased data-rates without greatly increasing the burden on
> the
> >> monitor would be to use high-rate data-only links, supplementing these
> by
> >> low-rate command-plus-data channels over which communication to the
> remote
> >> monitor could take place."  But this would require changes to the OS or
> >> monitor.
> >> --"The first step in that direction is the establishment of a message
> >> protocol, by which we mean a uniform agreed-upon manner of exchanging
> >> messages between two computers in the network."
> >> --These are point-to-point messages, but can provide error control:
> "The
> >> primary reasons for considering the establishment of a message protocol
> are
> >> the following: ... By formatting transmissions into messages, and
> including
> >> a check-sum with each message, transmission errors can frequently be
> >> detected. If detected, the messages can automatically be retransmitted
> in
> >> accordance with the protocol."
> >> --But this was (at the time the paper was written) still an experimental
> >> work-in-progress:  "As will be seen below, work is proceeding on an
> >> experimental network between the TX-2 computer at Lincoln Laboratory and
> >> the Q-32 computer at System Development Corporation."
> >> --"As soon as possible, a series of demonstrations and experiments will
> be
> >> performed using the experimental network. The experience gained will be
> >> reported at the conference."  [Was anyone at the 1966 Fall Joint?]
> >>
> >> For more background on these early "networking" efforts I commend to you
> >> the Hemmendinger paper from 2016.
> >>
> >> John Shoch
> >> --
> >> Internet-history mailing list
> >> 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
> >>
>
> --
> Internet-history mailing list
> 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
>