[ih] when did APRANET -TIPs become known as -TACs

[Jack Haverty]

IMHO, most of the people in the Internet community didn't know much 
about ISO/OSI.  The documentation was locked up behind paywalls; there 
was little code you could look at or even try out; the documents you 
could get were often confusing.

E.G., I remember trying once in some ISO/OSI protocol to figure out what 
the error code for "ship not in port" meant, to figure out when our code 
should return that error.   I knew what ports were from ARPANET and 
Internet folklore, but couldn't figure out the "ship" part.  There was 
no explanation in whatever document I had somehow obtained.   It just 
said error code XXX should be used to indicate the "ship not in port" error.

Later I found out that what the error code actually meant had nothing to 
do with the protocol interactions.  It was for use in maritime 
communications, and literally meant that the ship you were trying to 
connect to was not in a harbor - a port - at that time. Duhh...   
Perhaps there was some other protocol that enabled a ship, or a 
harbormaster, to somehow tell the network that a ship was leaving or 
arriving at a port, so the network could return the proper error code.

Jack


On 9/28/25 17:28, Karl Auerbach via Internet-history wrote:
> It annoyed me that IPv6 did not adopt the Fletcher checksum that was 
> used in ISO/OSI TP[1234] and CLNP.  (Or perhaps even a Hamming error 
> correcting code.)
>
> (At first glance the Fletcher checksum looks like a computational 
> burden with expensive machine operations, such as integer multiplies, 
> but there are both full and incremental algorithms for it that are 
> quite efficient, avoid expensive machine instructions, and fast.  And 
> the Fletcher checksum does catch byte big-endian/little-endian 
> reversals, or what was called in the early days of Unix the "nUxi" 
> [pairs of bytes reversed] problem.)
>
> We now live in a world where jumbograms - and large path MTU values, 
> on the order of 8K+, are rather common.  And those larger packets are 
> more likely to get hit with a burst of line noise than were the 
> shorter packets of days gone by.  But that revives the old debate 
> whether to do error checks/correction on a per-link basis or 
> end-to-end basis (in addition to per-link checks/correction.)  (Those 
> of us who were burned by the old Sun S-bus has no parity check, 
> coupled with Suns NFS using zero as null UDP checksum, kinda cling to 
> the end-to-end check side of the argument.  [When I was at Sun a 
> critical machine had an S-Bus/Ethernet path that became noisy and the 
> effect caused the major source code repository used for all Sun code 
> to become corrupted.  It was a mess to clean up.])
>
>     --karl--
>
>
> On 9/28/25 4:26 PM, John Day via Internet-history wrote:
>> No one took those seriously.
>> TP0 was for CCITT SGVIII, TP1 was for CCITT SGVII, TP2 was for the 
>> Brits who had to use X.25, and TP3 was for the Germans.
>>
>> No one paid them any mind. The real focus was on TP4 which was a 
>> major advance because it adopted Watson’s insight on synchronization 
>> which made it much simpler and more secure.
>>
>> Take care,
>> John
>>
>>> On Sep 28, 2025, at 19:21, Dave Crocker <dhc at dcrocker.net> wrote:
>>>
>>> On 9/28/2025 4:13 PM, John Day via Internet-history wrote:
>>>> The OSI vision was, if anything, Ethernet (an ISO standard), CLNP, 
>>>> TP4, and ACSE.
>>> That sounds reasonable, except for TP0, TP1, TP2, and TP3.
>>>
>>>
>>>
>>> and the various CONS alternatives to CLNP.
>>>
>>> OSI went for the union of everybody's wish lista.  The Internet went 
>>> for the intersection.
>>>
>>> d/
>>>
>>> -- 
>>> Dave Crocker
>>>
>>> Brandenburg InternetWorking
>>> bbiw.net
>>> bluesky: @dcrocker.bsky.social
>>> mast: @dcrocker at mastodon.social

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250928/42397c78/attachment-0001.asc>