From pnr at planet.nl  Thu Feb  9 13:56:51 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 9 Feb 2017 22:56:51 +0100
Subject: [ih] IEN's as txt
Message-ID: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>

Dear all,

I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?

Paul




From pnr at planet.nl  Thu Feb  9 14:28:27 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Thu, 9 Feb 2017 23:28:27 +0100
Subject: [ih] IEN's as txt
In-Reply-To: <CDFA757F-4699-4DEC-815F-11650C69AFB9@sobco.com>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<CDFA757F-4699-4DEC-815F-11650C69AFB9@sobco.com>
Message-ID: <C87E48D0-A3A9-442D-B8D7-63280574C379@planet.nl>

https://www.rfc-editor.org/rfc/ien/

On 9 Feb 2017, at 23:22 , Scott Bradner wrote:

> where did you find them as pdfs?  - I?m missing a number of IENs and those are two of them
> 
> thanks
> 
> Scott
> 
>> On Feb 9, 2017, at 4:56 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
>> 
>> Dear all,
>> 
>> I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
>> Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?
>> 
>> Paul
>> 
>> 
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.
> 




From larrysheldon at cox.net  Thu Feb  9 14:51:04 2017
From: larrysheldon at cox.net (Larry Sheldon)
Date: Thu, 9 Feb 2017 16:51:04 -0600
Subject: [ih] IEN's as txt
In-Reply-To: <imAh1u00d3VDnm801mAi4k>
References: <imAh1u00d3VDnm801mAi4k>
Message-ID: <e143c965-8b49-befd-efb2-2b1917a6f054@cox.net>



On 2/9/2017 15:56, Paul Ruizendaal wrote:

> I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
> Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?

I can make Microsoft Word output stuff as .pdf, .txt. and a varietyu of 
.doc variants.

I can load it with .txt. and the .doc variants.

Never tried loading a .pdf, but it might be fun.

-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.


From larrysheldon at cox.net  Thu Feb  9 15:02:44 2017
From: larrysheldon at cox.net (Larry Sheldon)
Date: Thu, 9 Feb 2017 17:02:44 -0600
Subject: [ih] IEN's as txt
In-Reply-To: <e143c965-8b49-befd-efb2-2b1917a6f054@cox.net>
References: <imAh1u00d3VDnm801mAi4k>
	<e143c965-8b49-befd-efb2-2b1917a6f054@cox.net>
Message-ID: <a0b9ff19-f71a-927d-6985-2085eba37bb7@cox.net>



On 2/9/2017 16:51, Larry Sheldon wrote:
>
>
> On 2/9/2017 15:56, Paul Ruizendaal wrote:
>
>> I'm looking for IEN81 and IEN55 as text files. It seems that they are
>> only available as PDF scans.
>> Does anyone know where to find those IEN's as .txt files? Or is
>> OCR'ing my only route?
>
> I can make Microsoft Word output stuff as .pdf, .txt. and a varietyu of
> .doc variants.
>
> I can load it with .txt. and the .doc variants.
>
> Never tried loading a .pdf, but it might be fun.

Tried it.

Can't be did, it appears.

At least not without the pricey Adobe spread.

-- 
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.


From bob.hinden at gmail.com  Thu Feb  9 15:36:22 2017
From: bob.hinden at gmail.com (Bob Hinden)
Date: Thu, 9 Feb 2017 15:36:22 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
Message-ID: <9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>

Paul,

I did an OCR of IEN55 in Adobe and saved the text.  It?s not pretty, and would require a lot of editing to be useful.

Let me know if you would like me to send it to you.

Bob


> On Feb 9, 2017, at 1:56 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
> 
> Dear all,
> 
> I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
> Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?
> 
> Paul
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170209/22868b80/attachment.asc>

From pnr at planet.nl  Thu Feb  9 16:02:17 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 10 Feb 2017 01:02:17 +0100
Subject: [ih] IEN's as txt
In-Reply-To: <9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
Message-ID: <ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>

Bob,

I did push IEN81 through an OCR tool with much the same result.
Many thanks for the offer though!

I won't have time for the manual patch up job until later in the
year.

---

All,

My underlying motive for this is to understand the changes to
TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
of the IEN's and RFC's would help. Perhaps this analysis has
already been done?

One thing that surprised me is that the closing mechanics in the
TCP state diagram kept changing until very late. Perhaps it
was just a matter of ever more precise specification, but if it
was conceptual change it would seem odd that it did not show up
earlier in the testing process and 'bake offs'.

Same goes for ICMP: it was a late arrival and the rationale for
abandoning the earlier approach is not entirely clear.

Paul


On 10 Feb 2017, at 0:36 , Bob Hinden wrote:

> Paul,
> 
> I did an OCR of IEN55 in Adobe and saved the text.  It?s not pretty, and would require a lot of editing to be useful.
> 
> Let me know if you would like me to send it to you.
> 
> Bob
> 
> 
>> On Feb 9, 2017, at 1:56 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
>> 
>> Dear all,
>> 
>> I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
>> Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?
>> 
>> Paul
>> 
>> 
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.
> 




From touch at isi.edu  Thu Feb  9 16:26:27 2017
From: touch at isi.edu (Joe Touch)
Date: Thu, 9 Feb 2017 16:26:27 -0800
Subject: [ih] seeking aggregate RFC term for "host or gateway"
Message-ID: <111fec34-dc7e-236a-3599-07ba169df721@isi.edu>

Hi, all,

I'm in the process of completing an RFC on tunneling in the Internet,
and need to be able to cite an RFC-based term that refers to "host or
gateway".

I originally considered "network node" to be obvious, but that term
appears in early (two-digit) RFCs to refer only to relays (precursors to
gateways), as distinct from hosts.

Does anyone know if there is a term that refers to both hosts (sources
and sinks of datagrams) and gateways (relays of datagrams) as s a set?

Thanks,

Joe



From touch at isi.edu  Thu Feb  9 16:29:21 2017
From: touch at isi.edu (Joe Touch)
Date: Thu, 9 Feb 2017 16:29:21 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
Message-ID: <92bf0d75-2d77-83a9-6f66-e9f963793884@isi.edu>

Hi, all,

I maintain an archive of these here at the Postel Center:

http://www.postel.org/ien/txt/

http://www.postel.org/ien/pdf/

If you do generate a verified txt of any of the PDFs not already
text-ed, please let me know.

Joe (as list admin)


On 2/9/2017 4:02 PM, Paul Ruizendaal wrote:
> Bob,
>
> I did push IEN81 through an OCR tool with much the same result.
> Many thanks for the offer though!
>
> I won't have time for the manual patch up job until later in the
> year.
>
> ---
>
> All,
>
> My underlying motive for this is to understand the changes to
> TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
> of the IEN's and RFC's would help. Perhaps this analysis has
> already been done?
>
> One thing that surprised me is that the closing mechanics in the
> TCP state diagram kept changing until very late. Perhaps it
> was just a matter of ever more precise specification, but if it
> was conceptual change it would seem odd that it did not show up
> earlier in the testing process and 'bake offs'.
>
> Same goes for ICMP: it was a late arrival and the rationale for
> abandoning the earlier approach is not entirely clear.
>
> Paul
>
>
> On 10 Feb 2017, at 0:36 , Bob Hinden wrote:
>
>> Paul,
>>
>> I did an OCR of IEN55 in Adobe and saved the text.  It?s not pretty, and would require a lot of editing to be useful.
>>
>> Let me know if you would like me to send it to you.
>>
>> Bob
>>
>>
>>> On Feb 9, 2017, at 1:56 PM, Paul Ruizendaal <pnr at planet.nl> wrote:
>>>
>>> Dear all,
>>>
>>> I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
>>> Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?
>>>
>>> Paul
>>>
>>>
>>> _______
>>> internet-history mailing list
>>> internet-history at postel.org
>>> http://mailman.postel.org/mailman/listinfo/internet-history
>>> Contact list-owner at postel.org for assistance.
>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.



From touch at isi.edu  Thu Feb  9 16:47:44 2017
From: touch at isi.edu (Joe Touch)
Date: Thu, 9 Feb 2017 16:47:44 -0800
Subject: [ih] Found on Twitter: a map of the Internet from 1973
In-Reply-To: <804078329.1748214.1481552691356@mail.yahoo.com>
References: <20161212011027.59D7018C08E@mercury.lcs.mit.edu>
	<alpine.OSX.2.20.1612111729170.62043@auge.attlocal.net>
	<804078329.1748214.1481552691356@mail.yahoo.com>
Message-ID: <24607757-93c5-8d61-5924-c45dfaf25cb7@isi.edu>

Hi, all,

We have an archive here at the Postel Center of Jon's notes.

Although I'm no handwriting expert, some of the early hand-drawn ones do
look like Jon's handwriting.

FWIW.

Joe


On 12/12/2016 6:24 AM, Alex McKenzie wrote:
> The origin of the famous hand-drawn first map is unclear.  Many of us
> think it was probably drawn by Jon Postel, but Jon had died before the
> question of its origin became interesting to most people.  When Peter
> Salus was writing his book "Casting the Net" he wanted to use that
> map, but his publisher insisted on a signed release from the author. 
> Peter approached me at some conference and asked if I knew who the
> author was.  I suggested Jon, and Peter sighed because Jon had already
> died and therefore it would be impossible to get a release from him. 
> So I offered to redraw the map from memory on the spot and then sign a
> release to Peter.  For that reason some versions of the hand-drawn map
> are attributed to me.
>
> Cheers,
> Alex
>
>
> ------------------------------------------------------------------------
> *From:* Stephen Casner <casner at acm.org>
> *To:* Noel Chiappa <jnc at mercury.lcs.mit.edu>
> *Cc:* internet-history at postel.org
> *Sent:* Sunday, December 11, 2016 8:29 PM
> *Subject:* Re: [ih] Found on Twitter: a map of the Internet from 1973
>
> On Sun, 11 Dec 2016, Noel Chiappa wrote:
>
> >    > Did they all come from BBN?
> >
> > All the ARPANet ones, yes, I m pretty sure (except for a few early ones,
> > maybe).
>
> The famous first one was hand drawn by Jon Postel, as I recall.
>
>                                                         -- Steve
>
> _______
> internet-history mailing list
> internet-history at postel.org <mailto:internet-history at postel.org>
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org <mailto:list-owner at postel.org> for
> assistance.
>
>
>
>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170209/460af603/attachment.htm>

From jnc at mercury.lcs.mit.edu  Thu Feb  9 16:48:43 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  9 Feb 2017 19:48:43 -0500 (EST)
Subject: [ih] IEN's as txt
Message-ID: <20170210004843.2005D18C098@mercury.lcs.mit.edu>

    > From: Paul Ruizendaal

    > I did push IEN81 through an OCR tool with much the same result.

Not too surprising; the resolution and contrast in those scans is pretty
poor. Eyes can deal; computers, not so much.


    > My underlying motive for this is to understand the changes to TCP (and
    > IP/ICMP/UDP) in the 1978-1981 time frame ... Perhaps this analysis has
    > already been done?

I don't think so, but maybe there's something I'm not aware of. You might try
reading the IEN meeting minutes from that period, to see what's documented
there.

    > if it was conceptual change it would seem odd that it did not show up
    > earlier in the testing process

I honestly don't recall - maybe someone who was more active in TCP work can
speak to this.


    > Same goes for ICMP: it was a late arrival and the rationale for
    > abandoning the earlier approach is not entirely clear.

This I can speak to.

Before ICMP, the only protocol for exchanging information between hosts and
routers about the state of the network, was GGP, IEN-109. In that protocol,
inter-router messages/mechanisms (e.g. path computation) were mixed in with
router-host messages (destination unreachable, redirects, etc).

This was 'obviously bad' for several reasons. One of the major ones was that
it was obvious to us at that point that the routing was going to need a lot
of work, and we wanted to cleanly and clearly separate that all out.

Putting all the router<->host interactions in a separate protoocol was
clearly a desirable move, architecturally.

	Noel


From johnl at iecc.com  Thu Feb  9 16:55:00 2017
From: johnl at iecc.com (John Levine)
Date: 10 Feb 2017 00:55:00 -0000
Subject: [ih] IEN's as txt
In-Reply-To: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
Message-ID: <20170210005500.20644.qmail@ary.lan>

In article <C5DCB96D-DCE2-455C-A40D-68FC28B64B88 at planet.nl> you write:
>Dear all,
>
>I'm looking for IEN81 and IEN55 as text files. It seems that they are only available as PDF scans.
>Does anyone know where to find those IEN's as .txt files? Or is OCR'ing my only route?

There's a putrid OCR version at archive.org.  Other than that, all
I've ever found is the PDF.

If anyone wants, I have a version of the PDF with somewhat better OCR text than the
archive.org version.

R's,
John


From brian.e.carpenter at gmail.com  Thu Feb  9 17:01:50 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Fri, 10 Feb 2017 14:01:50 +1300
Subject: [ih] seeking aggregate RFC term for "host or gateway"
In-Reply-To: <111fec34-dc7e-236a-3599-07ba169df721@isi.edu>
References: <111fec34-dc7e-236a-3599-07ba169df721@isi.edu>
Message-ID: <b82364c5-4251-470b-8eab-f982683fb3e4@gmail.com>

For IPv4, I suspect it's vague. There's a precise definition of 'node'
for IPv6, in RFC2460 section 2.

Regards
   Brian

On 10/02/2017 13:26, Joe Touch wrote:
> Hi, all,
> 
> I'm in the process of completing an RFC on tunneling in the Internet,
> and need to be able to cite an RFC-based term that refers to "host or
> gateway".
> 
> I originally considered "network node" to be obvious, but that term
> appears in early (two-digit) RFCs to refer only to relays (precursors to
> gateways), as distinct from hosts.
> 
> Does anyone know if there is a term that refers to both hosts (sources
> and sinks of datagrams) and gateways (relays of datagrams) as s a set?
> 
> Thanks,
> 
> Joe
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From jack at 3kitty.org  Thu Feb  9 20:36:50 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Thu, 9 Feb 2017 20:36:50 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
Message-ID: <d858865b-0f02-1bb6-7e0a-24ecdc1e75b5@3kitty.org>

On 02/09/2017 04:02 PM, Paul Ruizendaal wrote:

> My underlying motive for this is to understand the changes to
> TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
> of the IEN's and RFC's would help. Perhaps this analysis has
> already been done?
> 
> One thing that surprised me is that the closing mechanics in the
> TCP state diagram kept changing until very late. Perhaps it
> was just a matter of ever more precise specification, but if it
> was conceptual change it would seem odd that it did not show up
> earlier in the testing process and 'bake offs'.
> 
> Same goes for ICMP: it was a late arrival and the rationale for
> abandoning the earlier approach is not entirely clear.
> 

Hi Paul,

I don't think you'll find much in the IENs and RFCs about the rationale
for the various design changes in the 1978-81 timeframe.  There was a
lot going on then, and most of us had become electronic mail addicts by
then.   There was much more discussion and debate carried out on mailing
lists (like this one) than appeared in RFCs or IENs.  Those documents,
despite their names, were viewed as more "formal" places to document
results rather than as places to carry out discussions as things were
changed.  Electronic mail and FTP were just so much faster than the
traditional stream of papers in academic situations.

If you can find ancient archives of lists such as the TCP-IP Working
Group (can't recall it's exact mail address format), that would be the
best source.

I'm still trying to get to scanning in some of the ancient paper in my
basement (e.g., my listing of 1979 Unix TCP).  I also have my old
notebooks from all of the meetings in that time frame, which I'll go
through as well.

Meanwhile, ... from what I remember:

- TCP progressed rapidly through a bunch of slightly different versions
from TCP 2, 2.5, 2.5+epsilon, 2.5+2epsilon, and 3, eventually congealing
in 4.   All of these changes, IMHO, reflected 2 influences: what we had
learned by experimenting with a live Internet, and what we learned
people wanted to do using the Internet.

There was a lot of discussion about how to handle the fact that
datagrams might linger on the Internet, in buffers in hosts or gateways,
for quite a while, even hours or days.  They would cause considerable
confusion, and possibly incorrect data streams, if they surfaced after a
new connection had been established.  Machines went up and down a lot
more frequently in those days than today.  So the conventional wisdom
that packet lifetimes wouldn't ever be more than a few seconds was
judged to be incorrect.

We also discovered some obscure situations in which such spurious
packets could cause problems with closing connections.  These
discussions led to the changes in the state machine.  IIRC, several
additional states were added.  These changes continued "very late"
because we kept finding additional situations where some change was
needed to make sure the connection worked properly.

In our experiments with the live Internet, we learned that it was rather
difficult to tell what was going on, especially when things weren't
working right (very common in those early days).  ICMP was added as a
mechanism for adding in some of the functionality needed for things like
debugging (Ping), and "out-of-band" control (Source Quench, URGent) in
case the windowing mechanisms in-band in the data stream didn't do the job).

There was still a lot of uncertainty about exactly what the Internet
service should be.

For example, some host computers were "record-oriented" and liked to
deal with communications as exchanging "records" (think of the
punch-card days, which we were still doing back then).  In TCP, that
service was implemented in the "letter" mechanisms, and the EOL flag
("End Of Letter") and the "Rubber EOL" mechanism, also known as "Rubber
Baby Buffer Bumpers".  All of this kind of discussion really had to do
with ease of implementation and efficiency inside the various kinds of
machines involved.

Sometimes, design choices were made by non-technical means.  Tenex liked
"Rubber EOLs", and Bill Plummer was a major proponent of that mechanism.
 At one point, he left the TCP world to join another project ... and at
the next TCP meeting we all decided to remove Rubber EOL and Letters
from the TCP design.  The "byte-stream" model was so much cleaner.

Another example is voice.  The ARPANET never really tried to do anything
other than textual interactions with such limited bandwidth.  But DARPA
had desires for the Internet to be able to carry voice, especially
interactive voice.  Voice and data datagrams have different needs.  With
data, you want all of the data to get to the destination, no matter how
long it takes.  With voice, you want as much data as you can get for the
next fraction of a second that you're converting that data into sound.

TCP isn't the best choice for voice.  Various ARPA projects (e.g., Steve
Casner's work at ISI) wanted to experiment with voice coding and
protocols, but it wouldn't work well over TCP.

That was one motivation for the splitting apart of TCP and IP; it
permitted UDP to ride on top of IP in parallel with TCP.

With more than one service offered by the Internet ("get it all there
eventually" and "get whatever you can there fast"), there was a need to
tell the Internet how to treat your datagrams.  That motivated the
inclusion of the Type-Of-Service field and mechanisms.

With multiple types-of-service, the question of course was what
mechanisms are needed to actually treat packets differently.  E.G., it
might be necessary to have multiple simultaneous routing protocols in
action, each reflecting the state of the network for a particular type
of service.

There were lots of ideas about what to put in the IP layer, but it was
already getting pretty big... So, the "Options" mechanism was added to
permit anybody to add extra mechanisms.  That was, IIRC, how the "SPT"
functionality was introduced to reflect Autodin needs.

Much of the impetus for ICMP, and other "ancillary" mechanisms such as
SNMP, came from the experiences in the ARPANET.   I was at BBN in the
same group that built and was operating the ARPANET, and I took the helm
of various ARPA projects, including the gateway one, at that time.  So
we did a lot of stuff in the gateways based on the experience with what
had been proven to work in the ARPANET.  It was a way to bring the
Internet into reliable operation as a service rather than just an
experiment.

Dave Mills was very interested in Time, and I'm sure some of the
mechanisms put into IP/ICMP enabled him to define and refine the NTP
mechanisms.  He in particular wanted to do a lot of experiments
measuring how long it took for things to happen on the Internet, and the
lack of a coordinated time measurement mechanisms was a big obstacle.
So he built one.

I'm sure there's a lot more "rationale" to explain what happened.  Maybe
some of the others who "were there" at the time could recount their
experfiences too... (you know who you are!)

You also need to remember that the Internet was officially an
Experiment, and was officially tasked to try things that had not been
tried before, and might not work.  Source Quench was one of those things
- many of us didn't think it would actually work as a means for
congestion control.

Another thing to remember is that TCP4 was the 4th or 5th new version of
TCP over that few years, and we all expected the next version to arrive
in another year or so after TCP4 was defined.   So it was OK to have
mechanisms in TCP/IP/ICMP that were unproven, so we could get experience
in the live net for changing the specs.

Our estimate of that timeline was of course off by multiple
decades...and counting.

After I go through my notes, I'm going to try to write up some more
about what happened back then.  It was a wild time, and not well
captured in the more formal RFCs and IENs of that day.   We were too
busy getting rough consensus and running code.

HTH,
/Jack Haverty





From casner at acm.org  Thu Feb  9 22:09:35 2017
From: casner at acm.org (Stephen Casner)
Date: Thu, 9 Feb 2017 22:09:35 -0800 (PST)
Subject: [ih] IEN's as txt
In-Reply-To: <d858865b-0f02-1bb6-7e0a-24ecdc1e75b5@3kitty.org>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<d858865b-0f02-1bb6-7e0a-24ecdc1e75b5@3kitty.org>
Message-ID: <alpine.OSX.2.20.1702092206540.4040@auge.attlocal.net>

On Thu, 9 Feb 2017, Jack Haverty wrote:

> TCP isn't the best choice for voice.  Various ARPA projects (e.g., Steve
> Casner's work at ISI) wanted to experiment with voice coding and
> protocols, but it wouldn't work well over TCP.
>
> That was one motivation for the splitting apart of TCP and IP; it
> permitted UDP to ride on top of IP in parallel with TCP.

Credit Danny Cohen for that push, sparked by Bob Kahn's support of the
packet voice idea.

                                                        -- Steve


From vint at google.com  Fri Feb 10 03:05:50 2017
From: vint at google.com (Vint Cerf)
Date: Fri, 10 Feb 2017 06:05:50 -0500
Subject: [ih] IEN's as txt
In-Reply-To: <alpine.OSX.2.20.1702092206540.4040@auge.attlocal.net>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<d858865b-0f02-1bb6-7e0a-24ecdc1e75b5@3kitty.org>
	<alpine.OSX.2.20.1702092206540.4040@auge.attlocal.net>
Message-ID: <CAHxHggcjfZ=fsUibSvkAJpK=-fHVTvUoz9z9AW7gqq_YqMUdSw@mail.gmail.com>

Danny Cohen, Jon Postel and David Reed (MIT) all press for the IP split and
creation of UDP. Also, add to packet voice, packet video - Steve Casner at
ISI worked on both.

Keep in mind that the Internet layer sat on top of a bunch of independent
networks whose performance properties varied greatly.  The satellite net
had a synchronous satellite round trip delay; packet radio was variable and
lossy; ethernet was fast but potentially lossy, ARPANET was slow (50 kb/s)
but fairly reliable. So the IP and TCP mechanisms had to work for a range
of operating points.

Some of the rationale for various choices can be found in published papers.
The SNMP choice came from a contentious three-alternative debate that was
resolved and written up as an RFC. IENs were melded into RFCs eventually as
the Internet went from an experiment to something we indnded to rely upon.
The first TCP spec was published as an IEN and as RFC 675 if memory serves.
Jack's summary of the rapid shifts led to the TCP/IP split of TCP/IP v3 and
TCP/IP v4. Note we even tried IPv5 for streaming but abandoned as it did
not seem to scale well.

v


On Fri, Feb 10, 2017 at 1:09 AM, Stephen Casner <casner at acm.org> wrote:

> On Thu, 9 Feb 2017, Jack Haverty wrote:
>
> > TCP isn't the best choice for voice.  Various ARPA projects (e.g., Steve
> > Casner's work at ISI) wanted to experiment with voice coding and
> > protocols, but it wouldn't work well over TCP.
> >
> > That was one motivation for the splitting apart of TCP and IP; it
> > permitted UDP to ride on top of IP in parallel with TCP.
>
> Credit Danny Cohen for that push, sparked by Bob Kahn's support of the
> packet voice idea.
>
>                                                         -- Steve
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170210/a1b88273/attachment.htm>

From pnr at planet.nl  Fri Feb 10 04:23:45 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Fri, 10 Feb 2017 13:23:45 +0100
Subject: [ih] IEN's as txt
In-Reply-To: <ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
Message-ID: <C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>

Many thanks to all for your input. It already gives me a lot
to digest.

I understand that I won't find much rationale in the IEN/RFC
docs, but at least I can trace that way what the changes were
and how this affected the various code bases.

---

One fool can ask more questions than a thousand wise men can
answer, so here are some other things that puzzle me:

- The specs and implementations of 1978/9 don't interoperate (I
think) with those from 1981, not at the IP level and not at the
TCP level. Why were the protocol numbers never bumped?

- I believe BBN got the contracts for reference implementations
in the last quarter of 1980 and that work started immediately.
Was there a sense in late 1980 that the specs were already final?

- I think the flag day decision must informally have been taken
in the summer of 1981, allowing time for it to travel up and
down the chain of command and be formally declared in November.
The specs were still changing as late as April, and as Jack said
that was in response to bugs creeping out of the woodwork.
What gave the comfort to declare TCP ready for use and that the
changes were all done? Or was it simply that it could not be
postponed further without loss of credibility or some such?

- As I understand, in November 1981 there was not a single
production quality implementation of the April specs ready.
Is that correct and if so, were the spec's simply frozen for
a while to allow/force implementations to catch up?

- The post flag-day part of Mike Muuss' tcp-ip digest seems to
be mostly concerned with routing problems, even more so when the
MILNET split happened soon after. Noel's message on GGP and
ICMP suggests that this was foreseen. Is that correct or are
these issues unrelated?


On 10 Feb 2017, at 1:02 , Paul Ruizendaal wrote:

> My underlying motive for this is to understand the changes to
> TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
> of the IEN's and RFC's would help. Perhaps this analysis has
> already been done?
> 
> One thing that surprised me is that the closing mechanics in the
> TCP state diagram kept changing until very late. Perhaps it
> was just a matter of ever more precise specification, but if it
> was conceptual change it would seem odd that it did not show up
> earlier in the testing process and 'bake offs'.
> 
> Same goes for ICMP: it was a late arrival and the rationale for
> abandoning the earlier approach is not entirely clear.
> 
> Paul



From jnc at mercury.lcs.mit.edu  Fri Feb 10 05:17:18 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Feb 2017 08:17:18 -0500 (EST)
Subject: [ih] IEN's as txt
Message-ID: <20170210131718.CDE2118C0A7@mercury.lcs.mit.edu>

    >> Same goes for ICMP: it was a late arrival and the rationale for
    >> abandoning the earlier approach is not entirely clear.

    > Before ICMP, the only protocol for exchanging information between hosts
    > and routers about the state of the network, was GGP, IEN-109.
    > ...
    > it was obvious to us at that point that the routing was going to need a
    > lot of work

Oh, you might be asking yourself 'surely it was obvious early on that you all
needed something better, why didn't it get done sooner'. Two answers: manpower,
and knowledge.

First, the effort was pretty small (on the order of a few dozen people), and
most time and energy was being spent in simply writing code for the many
different OS's (there were a lot more back then, and many had to be coded in
assembler). That whole effort was made more difficult because OS's of that era
were generally not 'networking friendly', and often needed major internal
surgery to successfully support any networking. So there just weren't people
sitting around twiddling their thumbs waiting to think about, e.g. routing. We
all had 'day jobs' (I was building routers), and we had to fit this redesign
work in in what little time we could spare from actually getting the thing
running (which was absolutely flat-out, more-than-full-time already).

Second, we had so little practical experience to go on at the time, and you
shouldn't underestimate how much of a handicap that was. The picture of what
is needed is much clearer today than it was at the time. E.g. subnetting only
got added as LANs appeared; when the early work was done, there were only a
few large long-haul networks (hence the original addressing structure in IP).
We just didn't know.

	Noel


From jnc at mercury.lcs.mit.edu  Fri Feb 10 06:02:51 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 10 Feb 2017 09:02:51 -0500 (EST)
Subject: [ih] IEN's as txt
Message-ID: <20170210140251.CC5A218C0E4@mercury.lcs.mit.edu>

    > From: Paul Ruizendaal

    > - The specs and implementations of 1978/9 don't interoperate (I think)
    > with those from 1981, not at the IP level and not at the TCP level. Why
    > were the protocol numbers never bumped?

To start with, using years doesn't work well, for me at least (perhaps others'
memories work differently/better). I can remember that we did X before we did
Y, but I have no idea which years X and Y were in.

Assuming that you're speaking of the various changes to TCPv4/IPv4, the packet
formats are 'mostly' the same (modulo changes to things like addresses), which
is why they're all the same version number.  As I have already stated on
another list, my belief is that, provided suitable addresse are picked, one of
those older TCPv4/IPv4 implementations probably _would_ talk to a modern
TCP/IP.

The changes in that period _had_ to be interoperable, because at that point we
were already running services over TCP/IP, and another flag day wasn't in the
cards.  Well, if we'd had a major show-stopper, perhaps, but we already had
enough experience at that point to know that was not in the cards.


    > Was there a sense in late 1980 that the specs were already final?

Looking at the IEN Index, to try and give myself a time reference, I think by
1980 we were into the 'interoperable change' period, so although I'm sure we
didn't think we were _done_, we did feel there would not be any more flag days
(internal to the TCP/IP world, I mean).


    > I think the flag day decision must informally have been taken in the
    > summer of 1981

I can't speak to that, others will have to.

    > The specs were still changing as late as April

Sorry, exact which changes are you speaking of here?

Do note that the TCP/IP stack kept changing for years after this - e.g. the
subnetting in hosts change, which only became formal with RFC-1122 in October
1989!

    > as Jack said that was in response to bugs creeping out of the woodwork.

I think he was speaking in generalities. You'd need to ask about specific
changes, and say 'why did change X happen'.

    > What gave the comfort to declare TCP ready for use and that the changes
    > were all done?

The changes clearly _weren't_ all done - and we knew that at the time. What we
did have was i) enough experience to know that it would 'sorta' work, and ii)
it was clear that running it would provide benefits.

    > Or was it simply that it could not be postponed further without loss of
    > credibility or some such?

I can't speak to the credibility aspect, but I do recall, when 'ordinary
network users' grumped about the trouble that was going to be caused by the
switch from NCP to TCP/IP, it was pointed out to them that DARPA wasn't paying
for the ARPANET for them to amuse themselves, it was paying for it so lessons
about networking could be learned - and the switch was to learn.


    > As I understand, in November 1981 there was not a single production
    > quality implementation of the April specs ready.  Is that correct

Contemporary documentation is probably the best place to look for an answer to
that. It was a long time ago now, human memories have issues, etc, etc.

    > were the spec's simply frozen for a while to allow/force implementations
    > to catch up?

I don't recall any formal freeze, but maybe there was one. Check the meeting
notes, and things like memos that announced the forthcoming change, the
DDN Newsletters, etc.

And note that experimental changes were still happening, locally - e.g.  MIT
started using subnetting, in service internally, around this time period. So
even if they was a formal freeze, stuff was still happening.


    > The post flag-day part of Mike Muuss' tcp-ip digest seems to be mostly
    > concerned with routing problems ...  GGP and ICMP suggests that this was
    > foreseen. Is that correct or are these issues unrelated?

I don't recall the issues you mention (again, detail is needed - it was a
_long_ time ago, and unless there was something special/important about a
problem - problems were a constant thing for decades - generally they will
have faded from memory), but my suspicion is that such problems were with the
_existing_ routing, and not to do with the need for new routing ideas (e.g.
the IGP/EGP split).

	Noel


From vint at google.com  Fri Feb 10 06:14:34 2017
From: vint at google.com (Vint Cerf)
Date: Fri, 10 Feb 2017 09:14:34 -0500
Subject: [ih] IEN's as txt
In-Reply-To: <C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>
Message-ID: <CAHxHggfQhjHbxLC8jkRLK5b-UKDZj++VWW0ZtBO4ocGVL_TaQw@mail.gmail.com>

On Fri, Feb 10, 2017 at 7:23 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

> Many thanks to all for your input. It already gives me a lot
> to digest.
>
> I understand that I won't find much rationale in the IEN/RFC
> docs, but at least I can trace that way what the changes were
> and how this affected the various code bases.
>
> ---
>
> One fool can ask more questions than a thousand wise men can
> answer, so here are some other things that puzzle me:
>
> - The specs and implementations of 1978/9 don't interoperate (I
> think) with those from 1981, not at the IP level and not at the
> TCP level. Why were the protocol numbers never bumped?
>

because we were not in "release mode" this was experimental code and we
were not releasing into a large ecosystem.

>
> - I believe BBN got the contracts for reference implementations
> in the last quarter of 1980 and that work started immediately.
> Was there a sense in late 1980 that the specs were already final?


yes - they were pretty much frozen by 1978.

>


> - I think the flag day decision must informally have been taken
> in the summer of 1981, allowing time for it to travel up and
> down the chain of command and be formally declared in November.
> The specs were still changing as late as April, and as Jack said
> that was in response to bugs creeping out of the woodwork.
> What gave the comfort to declare TCP ready for use and that the
> changes were all done? Or was it simply that it could not be
> postponed further without loss of credibility or some such?
>

I wanted to get more experience in operational mode and the only way to do
that was to get it out into regular use. as program manager I felt a lot of
urgency since this has been in development since 1973.

>
> - As I understand, in November 1981 there was not a single
> production quality implementation of the April specs ready.
> Is that correct and if so, were the spec's simply frozen for
> a while to allow/force implementations to catch up?
>
well, that's your opinion. actually revisions in implementations have gone
on for decades including new flow control concepts and refined addressing
interpretations, etc.

>
> - The post flag-day part of Mike Muuss' tcp-ip digest seems to
> be mostly concerned with routing problems, even more so when the
> MILNET split happened soon after. Noel's message on GGP and
> ICMP suggests that this was foreseen. Is that correct or are
> these issues unrelated?
>
>
> On 10 Feb 2017, at 1:02 , Paul Ruizendaal wrote:
>
> > My underlying motive for this is to understand the changes to
> > TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
> > of the IEN's and RFC's would help. Perhaps this analysis has
> > already been done?
> >
> > One thing that surprised me is that the closing mechanics in the
> > TCP state diagram kept changing until very late. Perhaps it
> > was just a matter of ever more precise specification, but if it
> > was conceptual change it would seem odd that it did not show up
> > earlier in the testing process and 'bake offs'.
> >
> > Same goes for ICMP: it was a late arrival and the rationale for
> > abandoning the earlier approach is not entirely clear.
> >
> > Paul
>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
>



-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170210/78a760a6/attachment.htm>

From touch at isi.edu  Fri Feb 10 09:46:34 2017
From: touch at isi.edu (Joe Touch)
Date: Fri, 10 Feb 2017 09:46:34 -0800
Subject: [ih] seeking aggregate RFC term for "host or gateway"
In-Reply-To: <b82364c5-4251-470b-8eab-f982683fb3e4@gmail.com>
References: <111fec34-dc7e-236a-3599-07ba169df721@isi.edu>
	<b82364c5-4251-470b-8eab-f982683fb3e4@gmail.com>
Message-ID: <0a2dc3a6-ad8c-778f-cda0-ff61dfd98dd2@isi.edu>



On 2/9/2017 5:01 PM, Brian E Carpenter wrote:
> For IPv4, I suspect it's vague. There's a precise definition of 'node'
> for IPv6, in RFC2460 section 2.
Thanks. "Device" comes with baggage too; it's often a physical entity on
which multiple OSes or network stacks operate too, which means it isn't
directly comparable to "gateway or host" in that sense, but the
definition would be OK for RFC2460...

Joe

>
> Regards
>    Brian
>
> On 10/02/2017 13:26, Joe Touch wrote:
>> Hi, all,
>>
>> I'm in the process of completing an RFC on tunneling in the Internet,
>> and need to be able to cite an RFC-based term that refers to "host or
>> gateway".
>>
>> I originally considered "network node" to be obvious, but that term
>> appears in early (two-digit) RFCs to refer only to relays (precursors to
>> gateways), as distinct from hosts.
>>
>> Does anyone know if there is a term that refers to both hosts (sources
>> and sinks of datagrams) and gateways (relays of datagrams) as s a set?
>>
>> Thanks,
>>
>> Joe
>>
>> _______
>> internet-history mailing list
>> internet-history at postel.org
>> http://mailman.postel.org/mailman/listinfo/internet-history
>> Contact list-owner at postel.org for assistance.
>>
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.



From brian.e.carpenter at gmail.com  Fri Feb 10 11:12:27 2017
From: brian.e.carpenter at gmail.com (Brian E Carpenter)
Date: Sat, 11 Feb 2017 08:12:27 +1300
Subject: [ih] The Experiment [was: IEN's as txt]
In-Reply-To: <d858865b-0f02-1bb6-7e0a-24ecdc1e75b5@3kitty.org>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<d858865b-0f02-1bb6-7e0a-24ecdc1e75b5@3kitty.org>
Message-ID: <fe47372c-bf64-21a5-85a9-65f143847aaf@gmail.com>

On 10/02/2017 17:36, Jack Haverty wrote:
...
> You also need to remember that the Internet was officially an
> Experiment, and was officially tasked to try things that had not been
> tried before, and might not work.  

According to Martin Geddes, it still is, and it has failed:

https://www.linkedin.com/pulse/lets-face-facts-we-need-new-industrial-internet-martin-geddes

http://www.martingeddes.com/think-tank/the-future-of-the-internet-the-end-to-end-argument/

People here might be interested by his revisionism.

   Brian Carpenter


From jack at 3kitty.org  Fri Feb 10 11:21:11 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 10 Feb 2017 11:21:11 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <CAHxHggfQhjHbxLC8jkRLK5b-UKDZj++VWW0ZtBO4ocGVL_TaQw@mail.gmail.com>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>
	<CAHxHggfQhjHbxLC8jkRLK5b-UKDZj++VWW0ZtBO4ocGVL_TaQw@mail.gmail.com>
Message-ID: <60b7ddda-88e6-b36e-03b1-4c6e1a2794ed@3kitty.org>

I think there's a difference between tracking specifications and
tracking implementations.  It will be interesting to see how your
analysis of old code actually compares to the specs.

One of the beauties of the TCP/IP design is that the specifications did
not overspecify. They essentially defined what the formats and protocols
had to be "on the wire" so that different implementations could
communicate.  But there were a lot of design decisions still to be made
by each implementer or system builder.

For example, one TCP implementation might be oriented toward an
environment where bulk traffic was dominant (FTP).  That implementation
would strive to send "full" datagrams to minimize the overhead of the
TCP/IP headers.  Another implementation might be oriented toward
interactive traffic (Telnet), and strive to get the user data out onto
the wire immediately, since the user might be expecting the computer on
the other end to respond (echo a character, move a cursor, whatever).
Another might be oriented toward voice, another for situations involving
satellite paths, etc., etc.

There were lots of such decisions - how and when and what to retransmit,
what to do when you get back a Source Quench, what to do with different
settings of the header bits (e.g., TOS), etc. etc.  None of these were
specified in the docs.  The packet formats, state machine, and related
mechanisms were specified, but other things, like the user-interface
functionality, were included as examples.

That meant that, even when the specifications were "finalized" there was
still considerable work to be done and decisions to be made about how to
design a specific implementation.  Some of that subsequent work became
more formal as an RFC/IEN (e.g., Van Jacobson's work on retransmission
algorithms.)

As you look at actual implementations, it would be interesting to see
how those kinds of non-mandatory design decisions evolved over the last
30+ years.  I must admit I haven't followed the 1000s of RFCs which
probably capture a lot of the evolution of the protocols and algorithms.

It would also be interesting to see how well implementations actually
followed the specifications and the "recommended practices" that came
with experience.   TCP/IP is so forgiving about many things and a TCP/IP
implementation may "work" even if it's doing lots of things "wrong".

I worked with a TCP in the 1990s that had subpar performance and after a
few hours doing tcpdump analyses I had the pleasure of informing the
computer manufacturer that their TCP had a bug such that only
retransmitted segments would be accepted.  All first-time segments  were
incorrectly dropped as having bad checksums.  Just a bug.  But it
"worked" and was production quality...and in the released product.

A different computer's TCP had the characteristic that, after a glitch
of some kind in the network, it would settle down and traffic flows
would again stabilize on that connection.  As it should.  But tcpdump
revealed that after the glitch, the new stable state had every packet
being sent twice.  The retransmission timer had dropped just below the
round-trip delay.  But everything worked, and nobody complained.  We
only noticed because it was travelling over a very expensive
trans-Pacific circuit and we were watching utilization on that circuit
closely.

I'm not sure if the manufacturers ever fixed either of these behaviors.

As you examine old Unix code, you may unearth interesting artifacts.
For example, one of the Unix implementations (BSD IIRC) decided to put
the IP headers at the *back* of the packet.  This made things easier for
them inside the OS with buffer management.  They had some means to do
this only when communicating with another host running the same OS.  It
worked well for a collection of workstations and servers on a LAN.  But
we (BBN Network Op Center) noticed because one day all sorts of alarms
went off when the "core" gateways started getting streams of "bad
checksum" errors, because those weird Unix packets escaped the LAN and
the gateways didn't know that the IP header would be at the end of the
packet instead of the front.

One of the things I've noticed about RFCs and IENs is that they tend to
assume that the specification and the implementation are equivalent.
Not necessarily true...

HTH,
/Jack


On 02/10/2017 06:14 AM, Vint Cerf wrote:
> 
> 
> On Fri, Feb 10, 2017 at 7:23 AM, Paul Ruizendaal <pnr at planet.nl
> <mailto:pnr at planet.nl>> wrote:
> 
>     Many thanks to all for your input. It already gives me a lot
>     to digest.
> 
>     I understand that I won't find much rationale in the IEN/RFC
>     docs, but at least I can trace that way what the changes were
>     and how this affected the various code bases.
> 
>     ---
> 
>     One fool can ask more questions than a thousand wise men can
>     answer, so here are some other things that puzzle me:
> 
>     - The specs and implementations of 1978/9 don't interoperate (I
>     think) with those from 1981, not at the IP level and not at the
>     TCP level. Why were the protocol numbers never bumped?
> 
> 
> because we were not in "release mode" this was experimental code and we
> were not releasing into a large ecosystem. 
> 
> 
>     - I believe BBN got the contracts for reference implementations
>     in the last quarter of 1980 and that work started immediately.
>     Was there a sense in late 1980 that the specs were already final?
> 
> 
> yes - they were pretty much frozen by 1978.
> 
>      
> 
> 
>     - I think the flag day decision must informally have been taken
>     in the summer of 1981, allowing time for it to travel up and
>     down the chain of command and be formally declared in November.
>     The specs were still changing as late as April, and as Jack said
>     that was in response to bugs creeping out of the woodwork.
>     What gave the comfort to declare TCP ready for use and that the
>     changes were all done? Or was it simply that it could not be
>     postponed further without loss of credibility or some such?
> 
> 
> I wanted to get more experience in operational mode and the only way to
> do that was to get it out into regular use. as program manager I felt a
> lot of urgency since this has been in development since 1973. 
> 
> 
>     - As I understand, in November 1981 there was not a single
>     production quality implementation of the April specs ready.
>     Is that correct and if so, were the spec's simply frozen for
>     a while to allow/force implementations to catch up?
> 
> well, that's your opinion. actually revisions in implementations have
> gone on for decades including new flow control concepts and refined
> addressing interpretations, etc.  
> 
> 
>     - The post flag-day part of Mike Muuss' tcp-ip digest seems to
>     be mostly concerned with routing problems, even more so when the
>     MILNET split happened soon after. Noel's message on GGP and
>     ICMP suggests that this was foreseen. Is that correct or are
>     these issues unrelated?
> 
> 
>     On 10 Feb 2017, at 1:02 , Paul Ruizendaal wrote:
> 
>     > My underlying motive for this is to understand the changes to
>     > TCP (and IP/ICMP/UDP) in the 1978-1981 time frame, and diff's
>     > of the IEN's and RFC's would help. Perhaps this analysis has
>     > already been done?
>     >
>     > One thing that surprised me is that the closing mechanics in the
>     > TCP state diagram kept changing until very late. Perhaps it
>     > was just a matter of ever more precise specification, but if it
>     > was conceptual change it would seem odd that it did not show up
>     > earlier in the testing process and 'bake offs'.
>     >
>     > Same goes for ICMP: it was a late arrival and the rationale for
>     > abandoning the earlier approach is not entirely clear.
>     >
>     > Paul
> 
>     _______
>     internet-history mailing list
>     internet-history at postel.org <mailto:internet-history at postel.org>
>     http://mailman.postel.org/mailman/listinfo/internet-history
>     <http://mailman.postel.org/mailman/listinfo/internet-history>
>     Contact list-owner at postel.org <mailto:list-owner at postel.org> for
>     assistance.
> 
> 
> 
> 
> -- 
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
> 
> 
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From touch at isi.edu  Fri Feb 10 15:31:06 2017
From: touch at isi.edu (Joe Touch)
Date: Fri, 10 Feb 2017 15:31:06 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <60b7ddda-88e6-b36e-03b1-4c6e1a2794ed@3kitty.org>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>
	<CAHxHggfQhjHbxLC8jkRLK5b-UKDZj++VWW0ZtBO4ocGVL_TaQw@mail.gmail.com>
	<60b7ddda-88e6-b36e-03b1-4c6e1a2794ed@3kitty.org>
Message-ID: <82ebbc71-3060-b091-42e1-14a26986674f@isi.edu>

Hi, Jack (et al.),

On 2/10/2017 11:21 AM, Jack Haverty wrote:
> One of the beauties of the TCP/IP design is that the specifications did
> not overspecify. They essentially defined what the formats and protocols
> had to be "on the wire" so that different implementations could
> communicate.  But there were a lot of design decisions still to be made
> by each implementer or system builder

I sincerely wish the phrase "on the wire" would go away. It was NEVER
sufficient to describe a protocol; it defines only the messages that are
exchanged.

A protocol consists of a FSM specification:
    - those messages that are exchanged (sent or received) "on the wire"
    - state
    - events sent/received to the next layer up
    - time events
    - the relationship between the above events and states (a transition
table)

The constellation of items above provides the context in which the
messages have meaning. Without that, they are identical to noise.

Note - TCP got this right early on. The IETF made a serious error in
claiming the "API" wasn't part of a protocol spec for many decades, and
is only now recovering.

But NONE of the above is a decision made by the implementer - they are,
by definition, the aspects of a protocol that ensure that all
implementations interoperate.

Joe




From dhc2 at dcrocker.net  Fri Feb 10 17:28:47 2017
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Fri, 10 Feb 2017 17:28:47 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <82ebbc71-3060-b091-42e1-14a26986674f@isi.edu>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>
	<CAHxHggfQhjHbxLC8jkRLK5b-UKDZj++VWW0ZtBO4ocGVL_TaQw@mail.gmail.com>
	<60b7ddda-88e6-b36e-03b1-4c6e1a2794ed@3kitty.org>
	<82ebbc71-3060-b091-42e1-14a26986674f@isi.edu>
Message-ID: <bb9560af-4836-7c06-b4f4-1262de00d2e7@dcrocker.net>

On 2/10/2017 3:31 PM, Joe Touch wrote:
> A protocol consists of a FSM specification:
>     - those messages that are exchanged (sent or received) "on the wire"
>     - state
>     - events sent/received to the next layer up
>     - time events
>     - the relationship between the above events and states (a transition
> table)


Actually, the constraint to the comms channel perspective has 
historically been extremely helpful in getting people to focus on 
machine-independent interoperability rather than to fall back on 
defining things in terms of APIs, as has become increasingly common.

Issues of 'state' derive from the rules about what PDUs are allowed when 
and what they must/may contain.

However the point about provider and consumer interfaces -- that is, 
interacting with the layers below and aove -- for an engine implementing 
the protocol is a different matter and frequently gets inadequate 
attention.  The concept of protocol 'payload' often provides helpful 
assistance in getting folk to distinguish between information that is 
'within' the protocol mechanism versus information that is external to it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From touch at isi.edu  Fri Feb 10 18:04:11 2017
From: touch at isi.edu (Joe Touch)
Date: Fri, 10 Feb 2017 18:04:11 -0800
Subject: [ih] IEN's as txt
In-Reply-To: <bb9560af-4836-7c06-b4f4-1262de00d2e7@dcrocker.net>
References: <C5DCB96D-DCE2-455C-A40D-68FC28B64B88@planet.nl>
	<9923C963-6D6C-4462-8EF9-2D5DE047C847@gmail.com>
	<ABA7CD65-27DE-48EC-A3F1-5DFCCB7A0C3D@planet.nl>
	<C3D80C53-CC69-4395-BEF1-3AE7AB6E4163@planet.nl>
	<CAHxHggfQhjHbxLC8jkRLK5b-UKDZj++VWW0ZtBO4ocGVL_TaQw@mail.gmail.com>
	<60b7ddda-88e6-b36e-03b1-4c6e1a2794ed@3kitty.org>
	<82ebbc71-3060-b091-42e1-14a26986674f@isi.edu>
	<bb9560af-4836-7c06-b4f4-1262de00d2e7@dcrocker.net>
Message-ID: <59fd7c6b-598a-316b-cdae-40541bcfa56c@isi.edu>

Hi, Dave,


On 2/10/2017 5:28 PM, Dave Crocker wrote:
> On 2/10/2017 3:31 PM, Joe Touch wrote:
>> A protocol consists of a FSM specification:
>>     - those messages that are exchanged (sent or received) "on the wire"
>>     - state
>>     - events sent/received to the next layer up
>>     - time events
>>     - the relationship between the above events and states (a transition
>> table)
>
>
> Actually, the constraint to the comms channel perspective has
> historically been extremely helpful in getting people to focus on
> machine-independent interoperability rather than to fall back on
> defining things in terms of APIs, as has become increasingly common.
A protocol that transmits RFC793-compatible segments but does not
support the equivalent of open() and close() calls is not TCP.

I'm speaking of the abstract API, as is described in RFC793, not the
details of how that's rendered in Unix as socket calls.

> Issues of 'state' derive from the rules about what PDUs are allowed
> when and what they must/may contain.

State is context for those rules. E.g., the same PDU can cause different
events depending on the state. I can't see how they could be "derived".

> However the point about provider and consumer interfaces -- that is,
> interacting with the layers below and aove -- for an engine
> implementing the protocol is a different matter and frequently gets
> inadequate attention.  
That's what I call the APIs (there are two - one above, and one below -
for TCP, these include open() and close() above as well as send() and
receive() segments below).

> The concept of protocol 'payload' often provides helpful assistance in
> getting folk to distinguish between information that is 'within' the
> protocol mechanism versus information that is external to it.

I'm not sure I understand that. The payload describes the messages
between the endpoints. There are other messages - e.g., from the user,
from other protocols (e.g., ICMP) and from timers that also affect the
protocol mechanism. The rules for how all of those are handled are part
of the protocol - IMO, the specification of the parameters of the
accept() or connect() calls is as much part of TCP as the segment layout
description.

Joe


From scott.brim at gmail.com  Sat Feb 11 10:01:09 2017
From: scott.brim at gmail.com (Scott Brim)
Date: Sat, 11 Feb 2017 13:01:09 -0500
Subject: [ih] seeking aggregate RFC term for "host or gateway"
In-Reply-To: <b82364c5-4251-470b-8eab-f982683fb3e4@gmail.com>
References: <111fec34-dc7e-236a-3599-07ba169df721@isi.edu>
	<b82364c5-4251-470b-8eab-f982683fb3e4@gmail.com>
Message-ID: <CAPv4CP97m95o1W7d6m2hrdWu3+NswR15=VH7QRArSLDTsZUhnw@mail.gmail.com>

On Thu, Feb 9, 2017 at 8:01 PM, Brian E Carpenter
<brian.e.carpenter at gmail.com> wrote:
> For IPv4, I suspect it's vague. There's a precise definition of 'node'
> for IPv6, in RFC2460 section 2.

and I recall using "node" for IPv4 as a de facto lowest common
denominator, as well.


From pnr at planet.nl  Mon Feb 13 04:50:15 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Mon, 13 Feb 2017 13:50:15 +0100
Subject: [ih] TCP/IP timeline
Message-ID: <CBB28295-44C7-46B2-945A-48D4F0DA6214@planet.nl>


Many thanks for the feedback on my earlier questions around the
TCP/IP specification timeline.

To get things clear in my mind I made a little table linking
dates with IEN/RFC numbers. The result is here:
https://1fichier.com/?03hz69bj5e (one page 24KB PDF).

Of course, it doesn't mean much as long as the changes from
version to version are not clear. It could be real change and
it could be editorial clean-up.

I've also noted the caution that development of the specs and
of the code bases may not be the same.

Paul



From jnc at mercury.lcs.mit.edu  Mon Feb 13 09:09:19 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 13 Feb 2017 12:09:19 -0500 (EST)
Subject: [ih] RAND Unix Port code
Message-ID: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>

I'm not sure if this news has spread widely yet, but I have just recovered a
complete copy of the filesystem for the MIT-CSR Unix (the V6 Unix system at
MIT-LCS on which most of the early TCP/IP work at MIT was done). I have found
many treasures therein, including several early TCP/IP's. (More on this
below.)

I'm trying to make them all accessible through Unix source archives:

  http://minnie.tuhs.org/cgi-bin/utree.pl

for public access. To do so, I need to make sure they are all OK to release
publicly. (Back in the day, they were not, but that was because the underlying
UNIX code was protected.)

One of them is the BBN TCP/IP done by Mike Wingfield. It uses the RAND Port
code, and I'm trying to work out who can tell me, or OK, the release of that
code.

Alas, Steven Zucker, the person who wrote the RAND report detailing the
implementation of ports (and likely the actual author of the code) is no
longer with us. Carl Sunshine wrote the overview document, but I don't know
how to reach him - does anyone here? Does anyone else have any information
on whether or not we can make this code public? Thanks!


We do not, alas, have the source for the first BBN Unix TCP/IP - the one done
by Jack Havery as, I am under the impression, a port of Jim Mathis' TIU code.

We do, however, have the complete TIU source, and I hope to make that
available too. Same question(s) about that: does anyone know how to reach Jim,
or know anything about the releaseability of that code? (I seem to recall it
was done under contract to DARPA, and so probably was open, but not all code
written under a contract with the USG is necessarily public.)


Thanks!

	Noel


From jack at 3kitty.org  Mon Feb 13 12:33:19 2017
From: jack at 3kitty.org (Jack Haverty)
Date: Mon, 13 Feb 2017 12:33:19 -0800
Subject: [ih] RAND Unix Port code
In-Reply-To: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>
References: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>
Message-ID: <4641d8b9-5816-2760-0e3b-d284db7e47f1@3kitty.org>

OK, OK, I'll get my old listing of the Unix TCP and start scanning.
This will generate some huge files.  It's probably about 100 8.5x11
pages of stuff.  Has anybody figured out the "right" way to do this to
maximize usability (in case someone really wants to OCR or whatever)?
600DPI TIFs?  One-file-per-page?   And where on the net do you put such
piles of files so they're accessible?

Re: that Unix TCP.  My TCP was derived from Jim Mathis' TCP that was
part of the TIU and other boxes built from LSI-11s.  Jim's TCP was
written to run on top of MOS (IIRC Micro Operating System).  MOS was the
underpinning for the TIU as well.  I essentially took Jim's TCP, mixed
well with Unix V6 and Rand ports, reworked to use Unix system services
in place of MOS, reworked Rand ports to be faster, defined await/capac
primitives in Unix, and defined the basic open/close/read/write/etc
Unix-style interfaces for higher level applications to use TCP.

Re Rand ports:  I added a few lines to the basic Rand ports code to
improve performance by avoiding writing all data to the underlying disk
file (which the base code actually did although it wasn't obvious;
perhaps unintentional).  So you may find some of my fingerprints in
there too...

The other major player in the MOS family tree was the Port Expander.  A
common configuration was to put a Port Expander between your old
friendly NCP host and its ARPANET IMP.  That configuration provided 3
additional ARPANET TCP-only ports, err, sockets, err, you know, the
actual hardware connectors you plugged real physical cables into.

We never did get terminology nailed down....

/Jack


On 02/13/2017 09:09 AM, Noel Chiappa wrote:
> I'm not sure if this news has spread widely yet, but I have just recovered a
> complete copy of the filesystem for the MIT-CSR Unix (the V6 Unix system at
> MIT-LCS on which most of the early TCP/IP work at MIT was done). I have found
> many treasures therein, including several early TCP/IP's. (More on this
> below.)
> 
> I'm trying to make them all accessible through Unix source archives:
> 
>   http://minnie.tuhs.org/cgi-bin/utree.pl
> 
> for public access. To do so, I need to make sure they are all OK to release
> publicly. (Back in the day, they were not, but that was because the underlying
> UNIX code was protected.)
> 
> One of them is the BBN TCP/IP done by Mike Wingfield. It uses the RAND Port
> code, and I'm trying to work out who can tell me, or OK, the release of that
> code.
> 
> Alas, Steven Zucker, the person who wrote the RAND report detailing the
> implementation of ports (and likely the actual author of the code) is no
> longer with us. Carl Sunshine wrote the overview document, but I don't know
> how to reach him - does anyone here? Does anyone else have any information
> on whether or not we can make this code public? Thanks!
> 
> 
> We do not, alas, have the source for the first BBN Unix TCP/IP - the one done
> by Jack Havery as, I am under the impression, a port of Jim Mathis' TIU code.
> 
> We do, however, have the complete TIU source, and I hope to make that
> available too. Same question(s) about that: does anyone know how to reach Jim,
> or know anything about the releaseability of that code? (I seem to recall it
> was done under contract to DARPA, and so probably was open, but not all code
> written under a contract with the USG is necessarily public.)
> 
> 
> Thanks!
> 
> 	Noel
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.
> 


From johnl at iecc.com  Mon Feb 13 12:34:14 2017
From: johnl at iecc.com (John Levine)
Date: 13 Feb 2017 20:34:14 -0000
Subject: [ih] RAND Unix Port code
In-Reply-To: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>
Message-ID: <20170213203414.10847.qmail@ary.lan>

>Alas, Steven Zucker, the person who wrote the RAND report detailing the
>implementation of ports (and likely the actual author of the code) is no
>longer with us. Carl Sunshine wrote the overview document, but I don't know
>how to reach him - does anyone here? Does anyone else have any information
>on whether or not we can make this code public? Thanks!

I think they were working for Peter Weiner.  He's still around, now
semi-retired in Malibu as a professional photographer.

http://www.peter-g-weiner.com/contact

R's,
John


From b_a_denny at yahoo.com  Mon Feb 13 12:41:47 2017
From: b_a_denny at yahoo.com (Barbara Denny)
Date: Mon, 13 Feb 2017 20:41:47 +0000 (UTC)
Subject: [ih] RAND Unix Port code
In-Reply-To: <mailman.1.1487016001.3549.internet-history@postel.org>
References: <mailman.1.1487016001.3549.internet-history@postel.org>
Message-ID: <4269083.3965939.1487018507310@mail.yahoo.com>

Noel,
I have an email address for Jim.? I am not sure if he wants it broadcasted on an email list so I will send you a separate message.

I also saw Carl Sunshine at a meeting about 6 years ago. He was working for the Aerospace Corporation.? I don't know if he is still there.? If you can't find other information for him, I know people who work at Aerospace who might be able to give me his email address or let me know if he is still there.
barbara


      From: "internet-history-request at postel.org" <internet-history-request at postel.org>
 To: internet-history at postel.org 
 Sent: Monday, February 13, 2017 12:00 PM
 Subject: internet-history Digest, Vol 111, Issue 6
   
Send internet-history mailing list submissions to
??? internet-history at postel.org

To subscribe or unsubscribe via the World Wide Web, visit
??? http://mailman.postel.org/mailman/listinfo/internet-history
or, via email, send a message with subject or body 'help' to
??? internet-history-request at postel.org

You can reach the person managing the list at
??? internet-history-owner at postel.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of internet-history digest..."



Today's Topics:

? 1. TCP/IP timeline (Paul Ruizendaal)
? 2. RAND Unix Port code (Noel Chiappa)


----------------------------------------------------------------------

Message: 1
Date: Mon, 13 Feb 2017 13:50:15 +0100
From: Paul Ruizendaal <pnr at planet.nl>
Subject: [ih] TCP/IP timeline
To: internet-history at postel.org
Message-ID: <CBB28295-44C7-46B2-945A-48D4F0DA6214 at planet.nl>
Content-Type: text/plain; charset=us-ascii


Many thanks for the feedback on my earlier questions around the
TCP/IP specification timeline.

To get things clear in my mind I made a little table linking
dates with IEN/RFC numbers. The result is here:
https://1fichier.com/?03hz69bj5e (one page 24KB PDF).

Of course, it doesn't mean much as long as the changes from
version to version are not clear. It could be real change and
it could be editorial clean-up.

I've also noted the caution that development of the specs and
of the code bases may not be the same.

Paul



------------------------------

Message: 2
Date: Mon, 13 Feb 2017 12:09:19 -0500 (EST)
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Subject: [ih] RAND Unix Port code
To: internet-history at postel.org
Cc: wkt at tuhs.org, jnc at mercury.lcs.mit.edu
Message-ID: <20170213170919.8552E18C09C at mercury.lcs.mit.edu>

I'm not sure if this news has spread widely yet, but I have just recovered a
complete copy of the filesystem for the MIT-CSR Unix (the V6 Unix system at
MIT-LCS on which most of the early TCP/IP work at MIT was done). I have found
many treasures therein, including several early TCP/IP's. (More on this
below.)

I'm trying to make them all accessible through Unix source archives:

? http://minnie.tuhs.org/cgi-bin/utree.pl

for public access. To do so, I need to make sure they are all OK to release
publicly. (Back in the day, they were not, but that was because the underlying
UNIX code was protected.)

One of them is the BBN TCP/IP done by Mike Wingfield. It uses the RAND Port
code, and I'm trying to work out who can tell me, or OK, the release of that
code.

Alas, Steven Zucker, the person who wrote the RAND report detailing the
implementation of ports (and likely the actual author of the code) is no
longer with us. Carl Sunshine wrote the overview document, but I don't know
how to reach him - does anyone here? Does anyone else have any information
on whether or not we can make this code public? Thanks!


We do not, alas, have the source for the first BBN Unix TCP/IP - the one done
by Jack Havery as, I am under the impression, a port of Jim Mathis' TIU code.

We do, however, have the complete TIU source, and I hope to make that
available too. Same question(s) about that: does anyone know how to reach Jim,
or know anything about the releaseability of that code? (I seem to recall it
was done under contract to DARPA, and so probably was open, but not all code
written under a contract with the USG is necessarily public.)


Thanks!

??? Noel


------------------------------

_______________________________________________
internet-history mailing list
internet-history at postel.org
http://mailman.postel.org/mailman/listinfo/internet-history
Contact list-owner at postel.org for assistance.


End of internet-history Digest, Vol 111, Issue 6
************************************************


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170213/c7dbbb28/attachment.htm>

From jnc at mercury.lcs.mit.edu  Mon Feb 13 13:48:38 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 13 Feb 2017 16:48:38 -0500 (EST)
Subject: [ih] RAND Unix Port code
Message-ID: <20170213214838.E962818C09E@mercury.lcs.mit.edu>

    > Has anybody figured out the "right" way to do this to maximize usability
    > (in case someone really wants to OCR or whatever)? 600DPI TIFs?
    > One-file-per-page?

What we generally do for text (engineering drawings are slightly different) on
BitSavers (what, you don't know about BitSavers? ;-) is scanned at 300 dpi in
Black-and-White and then saved as TIFFs with CCITT Fax 4 compression. (A nice
image tool called IrfanView is good for producing those, if your scanning
program doesn't produce these natively.) That produces pretty small per-page
files, which we then combine into a single PDF.

If anyone really wants to OCR this, they might want to start with Jim's
TIU TCP code (as I mentioned, the MIT machine had a copy of the source).

    > Jim's TCP was written to run on top of MOS (IIRC Micro Operating
    > System).

There were allegations that it stood for 'Mathis' Operating System'... :-)

    > The other major player in the MOS family tree was the Port Expander.

Yeah, we tried to get that running at MIT. (We had the TIU code but I don't
think ever used it.) MIT's two IMP's were maxed out, port-wise. Alas, the
people who had done the hardware interfaces on the ITS machine (we were
working with MIT-DM) had taken advantage of the fact that on the IMP side of
the DH connection, there were opto-isolators, and they'd done a short-cut with
grounding one side of the differential, or something like that. The IMP
interface cards we got from SRI (they worked with DRV11 parallel interface
cards, and did level conversion, etc) couldn't emulate _that_. So that's why
it took so long for MIT (other than Multics) to show up on the Internet -
DARPA had to buy us another IMP (one of the first C/30's), first.

	 Noel


From scott.brim at gmail.com  Sat Feb 18 15:49:30 2017
From: scott.brim at gmail.com (Scott Brim)
Date: Sat, 18 Feb 2017 18:49:30 -0500
Subject: [ih] RAND Unix Port code
In-Reply-To: <4641d8b9-5816-2760-0e3b-d284db7e47f1@3kitty.org>
References: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>
	<4641d8b9-5816-2760-0e3b-d284db7e47f1@3kitty.org>
Message-ID: <CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>

On Mon, Feb 13, 2017 at 3:33 PM, Jack Haverty <jack at 3kitty.org> wrote:

> OK, OK, I'll get my old listing of the Unix TCP and start scanning.
> This will generate some huge files.  It's probably about 100 8.5x11
> pages of stuff.  Has anybody figured out the "right" way to do this to
> maximize usability (in case someone really wants to OCR or whatever)?
> 600DPI TIFs?


For 100 pages, could you get some eager (cheap) undergrads to type it in
again and then correct the typos? Give five kids 20 pages each?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170218/1dc3e7ae/attachment.htm>

From bernie at fantasyfarm.com  Sat Feb 18 16:25:03 2017
From: bernie at fantasyfarm.com (Bernie Cosell)
Date: Sat, 18 Feb 2017 19:25:03 -0500
Subject: [ih] RAND Unix Port code
In-Reply-To: <CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>
References: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>,
	<4641d8b9-5816-2760-0e3b-d284db7e47f1@3kitty.org>,
	<CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>
Message-ID: <58A8E5DF.17720.AC412CB4@bernie.fantasyfarm.com>

On 18 Feb 2017 at 18:49, Scott Brim wrote:

> On Mon, Feb 13, 2017 at 3:33 PM, Jack Haverty <jack at 3kitty.org> wrote:
>     OK, OK, I'll get my old listing of the Unix TCP and start
> scanning.
>     This will generate some huge files.? It's probably about 100
> 8.5x11
>     pages of stuff.? Has anybody figured out the "right" way to do this
> to
>     maximize usability (in case someone really wants to OCR or
> whatever)?
>     600DPI TIFs? ?
> 
> For 100 pages, could you get some eager (cheap) undergrads to type it in
> again and then correct the typos? Give five kids 20 pages each?

Give ten kids 20 pages each and diff the results...:o)
    /Bernie\

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       






From pnr at planet.nl  Sun Feb 19 01:24:31 2017
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 19 Feb 2017 10:24:31 +0100
Subject: [ih] RAND Unix Port code
In-Reply-To: <CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>
References: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>
	<4641d8b9-5816-2760-0e3b-d284db7e47f1@3kitty.org>
	<CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>
Message-ID: <BF89C288-22F6-4563-9A12-BD78201EA49C@planet.nl>


>From recent experience I can confirm that OCR'ing a faded 40 year old printout from a drum line printer is hard. I found that correcting the OCR output was as time consuming as retyping, so after doing some 10 pages the OCR way I switched to retyping from scratch for the rest. For C code I got to about 5 pages per hour.

On 19 Feb 2017, at 0:49 , Scott Brim wrote:

> On Mon, Feb 13, 2017 at 3:33 PM, Jack Haverty <jack at 3kitty.org> wrote:
> OK, OK, I'll get my old listing of the Unix TCP and start scanning.
> This will generate some huge files.  It's probably about 100 8.5x11
> pages of stuff.  Has anybody figured out the "right" way to do this to
> maximize usability (in case someone really wants to OCR or whatever)?
> 600DPI TIFs?  
> 
> For 100 pages, could you get some eager (cheap) undergrads to type it in again and then correct the typos? Give five kids 20 pages each?
> _______
> internet-history mailing list
> internet-history at postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-owner at postel.org for assistance.




From julf at julf.com  Sun Feb 19 02:48:53 2017
From: julf at julf.com (Johan Helsingius)
Date: Sun, 19 Feb 2017 11:48:53 +0100
Subject: [ih] RAND Unix Port code
In-Reply-To: <CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>
References: <20170213170919.8552E18C09C@mercury.lcs.mit.edu>
	<4641d8b9-5816-2760-0e3b-d284db7e47f1@3kitty.org>
	<CAPv4CP8XNHjDDH+CiM-UcQrwHrX8YT3Mo0OqsxQQCtWqBbttkw@mail.gmail.com>
Message-ID: <c5b83509-691d-c65b-a8e8-ae0b505d5f32@julf.com>

> For 100 pages, could you get some eager (cheap) undergrads to type it in
> again and then correct the typos? Give five kids 20 pages each?

Reminds me of how, back in 1997 or so, the source code of PGP was
printed into books (6000 pages) and legally exported, despite the
US export regulations at the time, and then scanned and proofread
to produce the "international version".

	Julf




From jnc at mercury.lcs.mit.edu  Sun Feb 19 07:36:36 2017
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 19 Feb 2017 10:36:36 -0500 (EST)
Subject: [ih] RAND Unix Port code
Message-ID: <20170219153636.C664418C0CA@mercury.lcs.mit.edu>

    > From: Paul Ruizendaal

    > I found that correcting the OCR output was as time consuming as
    > retyping, so after doing some 10 pages the OCR way I switched to
    > retyping from scratch for the rest.

If anyone wants to re-type the code, it might be faster to start with the code
base the MACRO-11 V6 UNIX TCP was based on, the SRI TIU TCP/IP, rather than
re-keying the whole thing from scratch.

I do have that source in machine readable form (it was on CSR); I wasn't about
to release it 'soon', but if anyone's going to try re-creating this code, I
can send it to them.

     Noel


From bill.n1vux at gmail.com  Sun Feb 19 08:54:08 2017
From: bill.n1vux at gmail.com (Bill Ricker)
Date: Sun, 19 Feb 2017 11:54:08 -0500
Subject: [ih] Diff double entry. OCR. Re:  RAND Unix Port code
In-Reply-To: <CAAbKA3XsNFkYacQkcs-ZoYx0CP9QY5J7YCfhPZZ8_0g4PH8TCw@mail.gmail.com>
References: <CAAbKA3WYmQJymR3uuC1LT0YF813Zvv38mTnHqvfUOQNKAOztsg@mail.gmail.com>
	<CAAbKA3XuyneSv60ELdQujaLSHR2vzcEMr1CSDRdA2L1H5t9Y7w@mail.gmail.com>
	<CAAbKA3UhKia_LPUVcXa8uqdXwHqPmK1HNgxPU4yrfScZ40YQKQ@mail.gmail.com>
	<CAAbKA3VmjBd0AezOTETn7XMmp4PmQKGbajSLN+ccg8Tvne6N1g@mail.gmail.com>
	<CAAbKA3X=jD5DFbvvW3wuTkgo6=WJJ=Mh+96f9Tu8qjoE_GCjmg@mail.gmail.com>
	<CAAbKA3WopqV5fJQ=0u9yHd79DEw+kO4-hX=TeSknGHsO5dhGbA@mail.gmail.com>
	<CAAbKA3UPbfiYzjr+7LS=SkbhD+EnCDmLu2U_2DUCfa33qXEMZA@mail.gmail.com>
	<CAAbKA3UrXaA7A6Pgq-CfeF8mniJq2zpykvnXkfK4SauTXo85HQ@mail.gmail.com>
	<CAAbKA3XsNFkYacQkcs-ZoYx0CP9QY5J7YCfhPZZ8_0g4PH8TCw@mail.gmail.com>
Message-ID: <CAAbKA3XCtKT4sOJzw6uZP=uncg_Umn6_s=rHnJjnCVR+5eQgNg@mail.gmail.com>

Give ten kids 20 pages each and diff the results...:o)
    /Bernie\


We did exactly that 39 years ago with n=2 for survey data not received on
op scan media.

My first paid coding job. I was supposedly one of the data entry undergrads
but I took over support of Fortran4 and PL1 diff and column swap utilities.

 (Also took op scan sheets to batch window and used offline accounting
machines with the opscanned card deck, because my time using the offline
sorted was cheaper than mainframe sort job. I hope I'm the youngest person
who can say that!)

With NL text, might want a format forgiving diff unless setting rigid
guidelines.

Having been researching in Google Books and ArchiveORG/PG PDFs of early and
mid 20thC publications for a project unrelated to IH (but WWW is saving me
N-1 trips to NARA), I'll concur that scan quality is very important for the
OCR, and not just resolution. Contrast, focus, alignment all matter.
Especially with elegant light "Modern" typefaces. An adaptive BW scan
particularly helpful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20170219/3d4fe3bb/attachment.htm>