Xref: utzoo comp.protocols.tcp-ip:2993 comp.protocols.iso:71
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!uw-beaver!cornell!rochester!bukys
From: bukys@cs.rochester.edu (Liudvikas Bukys)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: SLIP working group?
Message-ID: <8273@sol.ARPA>
Date: 1 Apr 88 15:41:10 GMT
References: <1966@hou2d.UUCP> <1016@thumper.bellcore.com> <9312@tut.cis.ohio-state.edu> <1017@thumper.bellcore.com> <20989@amdcad.AMD.COM>
Reply-To: bukys@cs.rochester.edu (Liudvikas Bukys)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 7

One should either leave SLIP alone (it works as it is), or re-do it
altogether, addressing some of the most severe problems while you're at
it.  For instance, someone at UDEL (Dave Farber & et al) noted that
header bytes are mostly predictable, and devised a faster (less
wasteful) serial-line protocol for slower lines.  If a SLIP working
group emerges, *that* is the direction it should take off in.  If
you're going to have a new protocol, it might as well be better, not
just different!