From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 6877 invoked from network); 9 Apr 2020 10:23:33 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with UTF8ESMTPZ; 9 Apr 2020 10:23:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E911693DBF; Thu, 9 Apr 2020 20:23:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D514593D44; Thu, 9 Apr 2020 20:22:59 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="MLbYodId"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 537A593D44; Thu, 9 Apr 2020 20:22:56 +1000 (AEST) Received: from cpsmtpb-ews05.kpnxchange.com (cpsmtpb-ews05.kpnxchange.com [213.75.39.8]) by minnie.tuhs.org (Postfix) with ESMTP id 7320693D1B for ; Thu, 9 Apr 2020 20:22:53 +1000 (AEST) Received: from cpsps-ews13.kpnxchange.com ([10.94.84.180]) by cpsmtpb-ews05.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Thu, 9 Apr 2020 12:22:50 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=(e1=10;e3=10;e2=11;e4=10);EVW:Whi te;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.3 cv=A4b3w5eG c=1 sm=1 tr=0 cx=a_idp_e a=aIJzBKXFL4aO3PtWP49Erg==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=x1i13A_MHe4A:10 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=GzAcQkMYAAAA:8 a=ziT8QxlrMPPsXmrdGHEA:9 a=pGz_Czuf9x5CCopw:21 a=wSXDAGc-uRnPsted:21 a=QEXdDO2ut3YA:10 a=4rMoGBsuVEyF1rsU7C0G:22 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.43]) by cpsps-ews13.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 9 Apr 2020 12:22:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=message-id:to:date:subject:mime-version:content-type:from; bh=+2ffRKtOlTUSBBNSUSWzLlWSeVsq2myaE1rKs9/7umM=; b=MLbYodIdgdJTqDSxhfPGbL845+2JjGT6lCLGO6oOIMfOM0pfbNJPh0+crMXsSZg29oRefidx0G3Gf 6tIt3eNcNeZbtLZ+TPVIQ1T8J0cNDUZW1t+eWGf5Mz4UzGbKEWLo5jMNDJwK2nSpzwVtUN/FChTcrK r2KK1taixbWtK9Ns= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|MTCto7lTvUBnmTGTEqBvdsit0Id8TRbk+R7THQvUhNkl1kDlpdpg36kf+oDaA/0 v4yGfv7y/8e3RAHBQ8h6wZQ== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 105b7cbc-7a4c-11ea-9fcb-005056ab1411; Thu, 09 Apr 2020 12:22:50 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 9 Apr 2020 12:22:49 +0200 References: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl> To: TUHS main list In-Reply-To: <1E2FB6CE-868E-45D3-81DA-9DCA94283800@planet.nl> Message-Id: <585EA404-7C39-46A1-BD72-E5493D62103B@planet.nl> X-Mailer: Apple Mail (2.3445.104.11) X-OriginalArrivalTime: 09 Apr 2020 10:22:50.0030 (UTC) FILETIME=[D2304CE0:01D60E58] X-RcptDomain: minnie.tuhs.org Subject: Re: [TUHS] PK protocol X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > On 6 Apr 2020, at 20:12, Paul Ruizendaal wrote: >=20 > Now I=E2=80=99m wondering. It looks like UUCP packet "protocol g=E2=80=9D= is maybe much the same as the original (=E2=80=9CChesson=E2=80=9D) = packet algorithm for Datakit, and if so it would be =E2=80=9Cdual = use=E2=80=9D. It would seem that in V7 line discipline =E2=80=980=E2=80=99= was normal tty handling, discipline =E2=80=981=E2=80=99 was PK protocol = over serial and line discipline =E2=80=982=E2=80=99 was PK protocol over = something with CRC in the driver - whatever that was. >=20 > Am I on the right track? It seems the story is more complicated. In a 1993 retrospective Fraser = writes: "The first Datakit protocols used a packet structure that was aligned = with cell boundaries. Chesson designed a file transfer protocol that = transported data in variable length packets, each ending with a trailer. = There was no packet header. It was argued that it is easy to generate a = trailer after the body of a packet has been transmitted, and that = control information in a trailer arrives at the receiver just when the = receiver is ready to process that information.=E2=80=9D Fraser uses the plural =E2=80=9Cthe first protocols=E2=80=9D: it would = seem that there is not a single reference point. It also mentions that = the protocols used a trailer, which does not match with the PK protocol. = On the other hand this is a reference to a =E2=80=9Cfile transfer = protocol=E2=80=9D which is not the same as a =E2=80=9Clink protocol=E2=80=9D= . Also, Chesson wrote a note on the PK driver a few years after the V7 = release (e.g. here: = https://pd.spuddy.org/fs/simtel20/uucp/uucproto.des). In this note he = writes: "The resemblance between the flow control procedure in the packet driver = and that defined for X.25 is no accident. The packet driver protocol = began life as an attempt at cleaning up X.25. That is why, for example, = control information is uniform in length (one byte), there is no RNR = message (not needed), and there is but one timeout defined in the = sender.=E2=80=9D Earlier in the note Chesson also emphasised that the PK protocol was = used for variation and experimentation. In the X.25 context, the = reference to a CRC-based driver in the PK source may refer to a = HDLC-like physical link. All in all it would seem that the PK driver is *not* what was used as an = early Datakit protocol. However, it is probably the best proxy for what = such a driver looked like that we have. It would seem likely to me that = for instance the buffer strategy used in the PK driver would be about = the same as that used for the Datakit driver(s) in V7. It is possible that a variation of the PK protocol was used for Datakit = around V7 time.