Xref: utzoo comp.protocols.tcp-ip:3003 comp.protocols.iso:74
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!ames!ucsd!rutgers!mtunx!whuts!homxb!hou2d!n2dsy
From: n2dsy@hou2d.UUCP (G.BEATTIE)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: SLIP working group?
Message-ID: <1970@hou2d.UUCP>
Date: 31 Mar 88 17:19:27 GMT
References: <1966@hou2d.UUCP>
Organization: AT&T Bell Laboratories, Holmdel
Lines: 62
Summary: Differences between SLIP and AFT another thought

POINT 1

It has been suggested that the differences between SLIP
and AFT are limited to the "gratuitous" alteration of the
transparency and framing characters.  

This is hardly the case...the additional features of
AFT are three levels of charater transparency, seven-bit
transparency and prefix and suffix characters outside the 
frame to manipulate any intervening devices such as modems,
PADs, etc.  

POINT 2

It has been suggested that these extra features are not
prohibited by SLIP.

We agree, they are not.  Unfortunately, these additional 
features have not been uniformly outlined in SLIP.  This
may cause the evolution of several systems using SLIP which
will each have different way of handing the variations of
transparency found in asynchronous environments.  AFT DOES
standardize these conditions and I suggest that maybe SLIP
should be altered to handle them too.

POINT 3

It has been suggested that this is a divisive issue wrought
by the ISO folks to further separate the DoD Internet
and OSI commmunities.

On this point I wholehartedly disagree.  In fact, the problem
is identical for both groups and should help unite them.
The OSI model is not an issue here, the aysnchronous interface
and transparency through that interface is.

POINT 4

It has been suggested that the number of errors encountered
on an Asynchronous Link is minimal, therefore some error
checking is not required on the link and that error recovery
can be accomplished on an end-to-end basis.  

If I was experiencing a low residual error rate, then I would
agree.  The fact is I am not.  Every dial-up link I have
outside of my local area, but within my LATA is noisy.
If your requirements are less, so be it, but I would like the
have the local loop tend to it's own housekeeping and not
send errored frames on through the network and force end-to-end
recovery.

POINT 5

Anyone want to work on the convergence of these protocols into
a common solution ?  Please let me know and we can get
started. 


Thanks,
            J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office)     201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)