Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!husc6!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: X Terminals & SLIP
Message-ID: <8807142332.AA15613@devnull.sun.com>
Date: 14 Jul 88 21:24:08 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 28

> Many of the points you make below are good, but there are a few corrections.
> It seems to me that SLIP is the best thing we have at the moment, but that we
> should look for better alternatives for the future.

The point of the mail was to show people where the "better alternatives" were
coming from and what the timescale was.  People interested in getting a
functional defacto standard for use with X terminals need to be in touch
with the IETF effort.

> I think 4.3BSD SLIP is close to a defacto standard, though certainly there are
> incompatible versions, and this is a problem.  Compression is definitely a
> problem, though it can be handled in hardware (for instance Telebit
> Trailblazers do hardware data compression if requested).  It's not clear that
> compression is really that big a win during interactive use of X.  It will
> probably only help during transfers of large bitmaps or significant other
> amounts of data.  The handshake will slow things down in interactive response.

4.3BSD SLIP isn't a good enough defacto standard for X terminals to use,
and incompatible versions are more than just "a problem" if you're shipping
machines with software in ROM.  The compression that matters is not Telebit-type
data compression,  but header compression.  The headers can be many times the
size of the data.

To repeat,  if you are planning to ship X terminals that work over the phone
with generic systems,  rather than just one type of proprietary box,  you need
to be in touch with the IETF effort.

	David.