Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: X Terminals & SLIP
Message-ID: <8807072305.AA03109@devnull.sun.com>
Date: 7 Jul 88 21:01:25 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 50

I was very impressed with the X terminal prototype that XPi and Visual had
at Usenix.  It was directly connected to the Ethernet,  but I expect to
see people trying to do the same thing over the phone soon.  I'm not an
expert on communication protocols,  but I had heard of SLIP,  so I asked
around to see if this was the answer.

The experts I talked to were unanimous that SLIP is not the right answer;
here are a selection of the reasons they gave:

1)	There are a number of incompatible versions of SLIP.  The RFC1055
	"generic" version does not cover compression,  which would be important
	for X terminals.

2)	SLIP connections need a separate network number - this fills up
	the route daemon tables.

3)	SLIP connections need statically assigned network and host numbers
	- this makes it impossible to have a pool of dial-in lines.  I know
	that UC Davis has hacked around this,  but once again this isn't
	RFC1055 "standard".

4)	SLIP does no error checking.  It depends on higher-level protocols
	to detect errors and do re-transmission.  Doing this at the
	end-to-end level is very inefficient,  and can mean that a very
	short error burst at the low level can cause a very long delay
	at the higher level.  This would be a particular problem for any
	X clients that were accessed via gateways,  etc.  It could also
	be a problem for an X terminal that used NFS client code to access
	fonts,  which would be a really good way of getting at them.

5)	SLIP does not support an Ethernet-like packet type field to permit
	extensions (for example,  extensions for compression,  ISO protocols,
	and so on).

As I understand it,  an Internet Engineering Task Force has been
chartered by the Internet Activities Board to attack this area.  I
believe they expect to have a prototype implementation in the next few
months.  The contact people for this effort are:

	Drew Daniel Perkins 
	Russ Hobby 
	Philip Prindeville 

Is anyone from the "xserial" world in touch with this effort?  Since these
terminals will depend on the OS they're accessing to support their brand
of serial-line networking,  making sure that they use whatever turns out
to be the Internet standard would be pretty important.  And it is
probably important to get the requirements of X terminals into the design
process early on.

	David.