Subject: Re: status of T/TCP

From: "Charles M. Hannum" <[email-masked]>
Date: Wed, 16 Sep 1998 22:05:14 -0400 (EDT)

Since there seems to be some confusion about this, I'd like to state
my position on the whole T/TCP thing explicitly:

My concern is whether, by introducing T/TCP, we are creating new ways
to lose that users are not expecting.  The purpose of my original
draft, and further comments here, is to bring light to these issues so
that they are addressed.  There's really nothing more to it than this.
I don't have some vendetta against T/TCP, or Bob.

Assuming that the problems are addressed, I think T/TCP is actually a
good idea.  There isn't really a way to lose here.  With the changes I
proposed, and the changes someone else (sorry, I forget who) proposed
to simplify the setup, the changes to the TCP protocol are relatively
simple.

There is still an issue with servers that implement RFC793 to the
letter, but I think this is probably an ignorable issue for the most
part (especially considering my intent of not using T/TCP at all for
some protocols).

So, I think the thing to do at this point is review the T/TCP spec,
incorporating relevant requirements and modifications proposed here,
implement it, and see how it fares.

This is, after all, what the RFC process is about.

---

From: [email-masked] (Alan Cox)
Date: Thu, 17 Sep 1998 04:11:08 +0100 (BST)

> part (especially considering my intent of not using T/TCP at all for

An awful lot of low end "contraption in a box" devices are KA9Q derived
and older KA9Q does not like T/TCP one bit.

> implement it, and see how it fares.

If this is to be done perhaps the first thing to issue is a small rfc
note on making sure your stack doesnt break when .. so that things are
ready for T/TCP. IPv6 is kindly going to kill a lot of the dinosaur
stacks for everyone so it would be good that nobody commits t/tcp 
incompatibility across it