Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!pyramid!csg
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.mail.uucp
Subject: Re: UUCP Over 7-bit connection
Message-ID: <149586@pyramid.pyramid.com>
Date: 25 Mar 91 18:23:04 GMT
References: <91070.203832LDSHANER@MTUS5.BITNET> <1991Mar17.224601.27427@scuzzy.in-berlin.de> <1991Mar22.001432.1420@eci386.uucp>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 20

In article <1991Mar22.001432.1420@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes:
>On the other hand, AT&T's 'e' protocol may work over 7-bit paths, if
>the data has the 8'th bit quoted.  I don't know if the rest of the
>protocol is 8-bit transparent though.

Neither the 't' nor 'e' protocols will work over what one would normally con-
sider a "7-bit path," like a PAD. 't' binary encodes its header, and 'e' has
a NULL terminated ASCII string in its header. Of course, the real problem with
't' and 'e' is that neither does an error checking. They're strictly for use
over error-free transport protocols, like TCP/IP or an OSI stack. (Can you
see it? uucico 'e' protocol over OSI Session over TP4 over SNDCF over X.25.)

On the 'f' protocol, note that for really random binary data -- like compress
output -- you are better off prefiltering the data through an encoder like
btoa or the Netnews encode program. The 'f' 8-bit quoting can add 50% to the
size of the data, while atob adds a fixed 18%, and ~news/encode 11% or so. But
if speed and/or transmission cost are not that important, then 'f' will handle
8-bit data just fine.

<csg>