FTP: ASCII vs Binary vs Tenex (was Re: What is "ASCII"?)
Douglas W. Jones,201H MLH,3193350740,3193382879
From article <4th8t5$g...@nntp.ucs.ubc.ca>, by sho...@alph02.triumf.ca
(Tim Shoppa):
>
> It's been so long since I used it that I've now forgotten: most
> ftp clients support(ed) "tenex" mode in addition to binary and
> ASCII. I believe this referred to a specific packing of characters
> into a 36-bit word, but at the moment I don't remember exactly what
> packing this specifies.
Isn't that the one with 5 7-bit ASCII characters per word? (with one
bit wasted).
Of course, the DEC-10 also supported 6 6-bit (upper case only) characters
per word or 4 9-bit characters per word (with a bunch of extra shift and
control buts -- bucky bits).
Doug Jones
> PS: Tim! I think I once sent you a bound photocopy of
Introduction to Programming, 1973. You were supposed to
send me an RX8E interface card in trade. Then there was
an earthquake, and our E-mail never seems to have made
contat since.
DJ
William
Note that "netascii" is actually an RFC-defined machine-independent
representation for text, and this is what the "ascii" command in FTP
refers to. In theory, if you do an ASCII transfer between an IBM mainframe
and a unix system, the IBM translates from EBCDIC to NETASCII (a rather
major conversion, and probably results in adding CRLFs where the IBM
had "record boundries".) Then the unix system translates from netascii
to the unix file format appropriate for text (ie, does CRLF-->\n.)
In general usage, an ASCII file is one where all the data actually fits
in 7 bits instead of 8 bits. The PDP10 computers had an ASCII assembler
directive that carefully packed its text argument five 7-bit bytes per
36 bit word, so in that case it implied a very specific format.
BillW
Smith and O'Halloran
In article <BILLW.96J...@puli.cisco.com>,
William <bi...@puli.cisco.com> wrote:
>Note that "netascii" is actually an RFC-defined machine-independent
>representation for text, and this is what the "ascii" command in FTP
>refers to.
RFC-959 describes the FTP protocol, and refers to TELNET's NVT-ASCII.
RFC-854 describes the TELNET protocol.
RFC-683 describes how to deal with TENEX files with holes.
The PDP-10 systems (TOPS-10, TENEX, TOPS-20) store 36-bit data in
128-word blocks or 512-word pages. Transferring files to 8, 16, 32 or
64-bit systems requires data conversion.
FTP uses three primary modes for exchanging data between dissimilar systems:
1) NET-ASCII - each line of text is terminated by a <CR><LF> pair.
Bare <CR> characters are transmitted as <CR><NULL>. Data is sent
as 7-bit USASCII in 8-bit bytes.
On PDP-10 systems, <NULL> characters are stripped out, and LSN
(Line Sequence Numbers) from editors like SOS are optionally removed.
2) BINARY - the input file is a contiguous stream of bits. Starting
with the most significant bit of the first word, data is transmitted
8 bits at a time.
On PDP-10 systems, this can be done by reading the file a nybble at
a time with a 4-bit byte pointer and sending each pair of nybbles as
8 bits.
Byte 9*n+0 = bits 0-7 of the even numbered word (starting with word 0)
Byte 9*n+1 = bits 8-15 of the even word
Byte 9*n+2 = bits 16-23 of the even word
Byte 9*n+3 = bits 24-31 of the even word
Byte 9*n+4 = bits 32-35 of the even word << 4 + bits 0-3 of odd word
Byte 9*n+5 = bits 4-11 of the odd numbered word
Byte 9*n+6 = bits 12-19 of the odd word
Byte 9*n+7 = bits 20-27 of the odd word
Byte 9*n+8 = bits 28-35 of the odd word (ending with word 0177 or 0777)
3) TENEX mode (Local Bytesize 8) - tells the TOPS10/TOPS20/TENEX system
to use a byte size of 8, 16 or 32 when reading/writing its file.
This uses only bits 0-31 of the 36-bit file; bits 32-35 are never
sent when reading and set to zero when writing the 36-bit file.
FTP also defines a fourth mode for sending TENEX files a page at a time.
This allows files with holes in them to be exchanged between 36-bit
systems, but is not for exchanging data between dissimilar systems.
In addition to those methods, two others are useful:
4) ANSI-ASCII / KERMIT-36 - the 36-bit word is broken up into 5 bytes,
the first 4 use only 7 of the 8 bits, the last one uses all 8 bits
and has its MSB set only if bit 35 of the word is set.
Byte 5*n+0 = 0 << 7 + bits 0-6 of word
Byte 5*n+1 = 0 << 7 + bits 7-13 of word
Byte 5*n+2 = 0 << 7 + bits 14-20 of word
Byte 5*n+3 = 0 << 7 + bits 21-27 of word
Byte 5*n+4 = (bit 35 of word) << 7 + bits 28-34 of word
Note that a 36-bit binary file can be transfered to an 8-bit system and
then back again without losing any bits. PDP-10 text files are readable
asis when transfered to CP/M, MS-DOS, and anythine else that uses
<CR><LF> as the line separator on disk.
Later versions of TOPS-10 and TOPS-20 had tape controllers that used
microcode in the tape formatter to do this sort of bit shuffling.
5) UNIX-ASCII - like ANSI-ASCII, except that <NULL> characters and <CR>
immediately before <LF> are discarded, and bit 35 is always ignored.
This mode is something we used in-house to write to 1/2-inch tapes
in 'tar' format. The idea was to create a tape that could be
used on our UNIX system with no postprocessing. This meant that
file 36-bit file had to be read from disk twice: once to calculate the
byte count for the 'tar' header, and another pass to write the data.
A method of storing 36-bit data as 6 bytes of 6 bits each on an 8-bit
medium is less efficient than the methods above. It was mainly used
only for bootstrapping a PDP-6, KA or KI from paper tape. In this
application, simplicity of hardware was more important than efficiency.
I will put this document on my PDP-10 page: www.inwap.com/pdp10/.
-Joe
--
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran (and our cats).
See http://www.inwap.com/ for "ReBoot", PDP-10, and Clan MacLeod.
j...@kouzlo.com
In article <4tqc72$3...@kannews.ca.newbridge.com>,
Paul DeMone <pde...@tundra.com> writes:
> Don't forget "radix 50" on PDP-11s. Encoded 3 alphanumeric characters
> (40 characters: A-Z,0-9,$,_ ... can't remember the last two) per 16 bit
> word. Actually radix 40 decimal (50 octal = 40); given character values
> C1, C2, and C3, the 16 bit value calculated as C1*1600 + C2*40 + C3.
>
> It was used by some PDP-11 operating systems but I don't know if any
> communications software ever used it.
It was used pretty extensively in RT-11. Just about all the system
software depended on it (directory entries, MACRO-11 symbol tables,
etc).
I never saw a comm program that used it other than the one I wrote
to play with briefly back in '82 or '83. It was all right for
sending basic text and that was it.
jrs
Richard M. Alderson III
In article <4tqc72$3...@kannews.ca.newbridge.com> Paul DeMone
<pde...@tundra.com> writes:
>Don't forget "radix 50" on PDP-11s.
RADIX50 preceded the PDP-11 by a long time. It was used on the PDP-10 (and I
think the PDP-6), where it allowed packing 6-character symbol names into the
rightmost 32 bits of a 36-bit word, with the other 4 bits used for flags to the
linker.
I also don't think it was a DEC invention; I seem to remember that it was first
devised by J. A. N. Lee for the FORTRAN compiler on the IBM 704, another 36-bit
machine.
--
Rich Alderson You know the sort of thing that you can find in any dictionary
of a strange language, and which so excites the amateur philo-
logists, itching to derive one tongue from another that they
know better: a word that is nearly the same in form and meaning
as the corresponding word in English, or Latin, or Hebrew, or
what not.
--J. R. R. Tolkien,
alde...@netcom.com _The Notion Club Papers_
Paul DeMone
Don't forget "radix 50" on PDP-11s. Encoded 3 alphanumeric characters
(40 characters: A-Z,0-9,$,_ ... can't remember the last two) per 16 bit
word. Actually radix 40 decimal (50 octal = 40); given character values
C1, C2, and C3, the 16 bit value calculated as C1*1600 + C2*40 + C3.
It was used by some PDP-11 operating systems but I don't know if any
communications software ever used it.
Paul
All opinions strictly my own.
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race to put
Kanata, Ontario more PRECISION and POWER into architectures with
pde...@tundra.com MIPSed results but ALPHA's well that ends well.
Satan's CPU? The P666 of course - check out Appendix H(ell) under NDA
Alexandre Pechtchanski
Paul DeMone <pde...@tundra.com> wrote:
>Don't forget "radix 50" on PDP-11s. Encoded 3 alphanumeric characters
>(40 characters: A-Z,0-9,$,_ ... can't remember the last two)
Why, space and - sign, of course ;-) And I believe (memory really hazy) that
there was a decimal point instead of underscore there.
> per 16 bit
>word. Actually radix 40 decimal (50 octal = 40); given character values
>C1, C2, and C3, the 16 bit value calculated as C1*1600 + C2*40 + C3.
BTW, makes for a nice simple "encoding" for non-serious "protection" (security
through obscurity: modern crackers-wanna-be haven't heard about it).
>It was used by some PDP-11 operating systems but I don't know if any
>communications software ever used it.
IIRC, RT-11, RSX-11 (and IAS), and DOS-11 all used it for directory entries
(6.3 filename format in 4 words, the 4th kept version number).
MUMPS used it also for tokens, I believe.
Alexandre Pechtchanski, GCRC system manager sys...@vaxa.crc.mssm.edu
Kevin Ashley
In article <4tt8ua$o...@news.cuny.edu>, pech...@vaxa.crc.mssm.edu (Alexandre Pechtchanski) writes:
|>Paul DeMone <pde...@tundra.com> wrote:
|>
|>>Don't forget "radix 50" on PDP-11s. Encoded 3 alphanumeric characters
|>>(40 characters: A-Z,0-9,$,_ ... can't remember the last two)
|>
|>Why, space and - sign, of course ;-) And I believe (memory really hazy) that
|>there was a decimal point instead of underscore there.
I recall seeing more than one interpretation of RAD50, the difference
being what that last character was. However, for most uses on the PDP11
operating systems, dot (or full stop, decimal point, whatever) had to
be one of the characters. Object files output by the compilers and assembler
used RAD50 to encode internal and external symbol names. $ and dot were
valid characters in global symbols, as anyone who has spent any time
calling RT11 EMTs or RSX system calls will remember.
------------------------------------------------------------------------------
Kevin Ashley K.As...@Ulcc.ac.uk
Systems Development Group Manager http://www.ulcc.ac.uk/staff/Kevin+Ashley
University of London Computer Centre. ...ukc!ncdlab!K.Ashley
This is not a signature
DoN. Nichols
In article <4tkebo$2...@shellx.best.com>,
Smith and O'Halloran <in...@best.com> wrote:
[ ... ]
>3) TENEX mode (Local Bytesize 8) - tells the TOPS10/TOPS20/TENEX system
> to use a byte size of 8, 16 or 32 when reading/writing its file.
> This uses only bits 0-31 of the 36-bit file; bits 32-35 are never
> sent when reading and set to zero when writing the 36-bit file.
I suspect that this must have been what the TENEX mode in the ftp
for the BBN C-70 did. It had 10-bit bytes, 20-bit words, and 40-bit longs.
I *think* that the physical wordsize was 20 bits, but this was rather
difficult to determine from the terminal, since it had a philosophy of
"having no assembly language", and an instruction set designed to be a
target of a C compiler.
Those 10-bit bytes sure confused "compress", though. :-) There was
an alternate compression program, which *I* got from an OS-9 users' group
distribution, but which was obviously written for unix, with the "magic
number" at the beginning of the output file, and all. (2995 -- ascribed as
being the result of too much late-night TV. :-) That program, whose name I
have unfortunately forgotten, had internal configuration parameters in the
source so you could tune it to the less common byte sizes. The
administrator of that system certainly thanked me for installiing *that*
program on the system.
--
Email: <dnic...@d-and-d.com> | Donald Nichols (DoN.)
Voice Days: (703) 704-2280 | Eves: (703) 938-4564
My Concertina web page: | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
Richard M. Alderson III
>In article <4tkebo$2...@shellx.best.com>,
>Smith and O'Halloran <in...@best.com> wrote:
>>3) TENEX mode (Local Bytesize 8) - tells the TOPS10/TOPS20/TENEX system
>> to use a byte size of 8, 16 or 32 when reading/writing its file.
>> This uses only bits 0-31 of the 36-bit file; bits 32-35 are never
>> sent when reading and set to zero when writing the 36-bit file.
>I really don't remember "TENEX mode" w.r.t. the TOPS10 operating system.
>For instance, I don't remember anything in UUOSYM defining this a data
>mode. Would someone please refresh my memory?
"TENEX mode" was a Unixism, having to do with file transport of binaries
between PDP-10 systems and your typical 8-bits/byte Unix box. It's the moral
equivalent of "Industry-Compatible" mode for magtapes (mode .TFM8B according to
my Chapter 14 of my 7.04 UUO manual).
It allowed an 8-bit file to be stored undisturbed on the -10.
Eric Smith
In article <4v1uar$s...@newsbf02.news.aol.com> jmf...@aol.com (JMFBAH) writes:
> I really don't remember "TENEX mode" w.r.t. the TOPS10 operating system.
> For instance, I don't remember anything in UUOSYM defining this a data
> mode. Would someone please refresh my memory?
FTP TENEX mode isn't a mode of the operating system or file system, it is a
mode of FTP. The FTP client and server implementations simply agree in TENEX
mode to treat the data in a certain way. The implementation is responsible
for doing any necessary massaging of the data to conform to the storage
requirements of the host, OS, and file system.
Cheers,
Eric
JMFBAH
[ ... ]
>3) TENEX mode (Local Bytesize 8) - tells the TOPS10/TOPS20/TENEX system
> to use a byte size of 8, 16 or 32 when reading/writing its file.
> This uses only bits 0-31 of the 36-bit file; bits 32-35 are never
> sent when reading and set to zero when writing the 36-bit file.
I really don't remember "TENEX mode" w.r.t. the TOPS10 operating system.
For instance, I don't remember anything in UUOSYM defining this a data
mode. Would someone please refresh my memory?
/BAH
Smith and O'Halloran
In article <ERIC.96Au...@goonsquad.spies.com>,
Eric Smith <er...@goonsquad.spies.com> wrote:
>In article <4v1uar$s...@newsbf02.news.aol.com> jmf...@aol.com (JMFBAH) writes:
>> For instance, I don't remember anything in UUOSYM defining this a data
>> mode. Would someone please refresh my memory?
>
>mode of FTP. The FTP client and server implementations simply agree in TENEX
>mode to treat the data in a certain way.
Yep. You won't find "TENEX mode" in UUOSYM; you'd find it in the sources
to FTP server. One way of accomplishing it is to adjust the byte pointer,
after the OPEN UUO but before the first IN or OUT UUO, to use 8-bit bytes.
JMFBAH
In article <ALDERSON.96...@netcom4.netcom.com>
alde...@netcom4.netcom.com (Richard M. Alderson III) wrote:
<"TENEX mode" was a Unixism, having to do with file transport of binaries
<between PDP-10 systems and your typical 8-bits/byte Unix box. It's the
moral
<equivalent of "Industry-Compatible" mode for magtapes (mode .TFM8B
<according to my Chapter 14 of my 7.04 UUO manual).
<
<It allowed an 8-bit file to be stored undisturbed on the -10.
The first I ever heard of "TENEX" was when Murphy started to take the KIs
stand-alone to work on the OS that was would be sold as TOPS20. Is there
a connection between Murphy's TENEX and the "TENEX mode" that you
described as an Unixism?
/BAH
Sam Weiner
of -10s running TENEX (later TOPS-20) to store binary 8 bits oriented
files. At one time, many of the systems connected to the ARPAnet were
running TENEX. In later days, SIMTEL-20.ARMY.MIL was a major repository
of micro computer (and other) files which was of course running TOPS-20.
Sam
Tim Shoppa
In article <4v7erk$6...@agate.berkeley.edu>,
Brian Harvey <b...@anarres.CS.Berkeley.EDU> wrote:
[Excellent answer to the question I posed in the subject line
deleted for brevity - TDS].
>See NIC 14333 for full info on the File Transfer Protocol at the
>relevant time.
Where would I find NIC 14333, or RFC 454 (which is often mentioned
along with NIC 14333) online? A quick check of the ftp sites in North
America that keep many of the RFC's didn't turn up
either of these. (which, apparently, come from around 1973 or so.)
Tim. (sho...@triumf.ca)
Smith and O'Halloran
In article <DwCFs...@world.std.com>, Sam Weiner <wei...@world.std.com> wrote:
>At one time, many of the systems connected to the ARPAnet were
>running TENEX. In later days, SIMTEL-20.ARMY.MIL was a major repository
>of micro computer (and other) files which was of course running TOPS-20.
For getting public-domain softeare for CP/M machines, the usual sequence
of events was:
1) Log into your local UNIX box.
2) Run 'ftp' and connect to SIMTEL-20.ARPA (aka SIMTEL-20.WSMR.ARMY.MIL).
3) Tell 'ftp' to use TENEX mode.
4) Get the files.
5) Use zmodem or kermit to download files to your CP/M microcomputer.
Step #3 was very important if the FTP site was running TOPS-10, TOPS-20 or
TENEX. If you forgot that step and used plain BINARY mode, the resulting
file would be unuseable. (Actually, the file TENEX.COM for CP/M was a
small program that fix the downloaded file by throwing out 1 out of every
9 nybbles.)
Summary: "TENEX mode" exists in the UNIX versions of the FTP program,
and allows 8-bit binary files to be transfered to/from 36-bit systems.
Brian Harvey
jmf...@aol.com (JMFBAH) writes:
>The first I ever heard of "TENEX" was when Murphy started to take the KIs
>stand-alone to work on the OS that was would be sold as TOPS20. Is there
>a connection between Murphy's TENEX and the "TENEX mode" that you
>described as an Unixism?
The Arpanet File Transfer Protocol supported five "representation types":
TYPE A ASCII
TYPE I image
TYPE L local byte
TYPE P print file
TYPE E EBCDIC
The first two of these are still in widespread use; most FTP programs
have "ascii" and "image" commands. For this discussion, what you have
to understand is the difference between types I and L.
Sending text was straightforward unless you were talking to an IBM machine.
You used TYPE A, which implied an 8-bit byte sent over the net. If you
were a PDP-10, you converted to/from a 7-bit byte for the local file,
packed in the usual five-per-word way.
Sending binary files was more problematic. Type I, image type, requires
that the bits be tightly packed at both sending and receiving ends of the
transfer. So, for example, if you send a 36-bit PDP-10 word to an 8-bit
machine, the latter machine must put the first 32 bits into four bytes, and
then the fifth byte of the destination file will contain the last four bits
of the first word and the first four bits of the second word! Image type was
intended for two similar machines, not for dissimilar ones.
Type L, local byte type, to the rescue. It allows each end of the
transfer to arrange the bit stream into bytes in a convenient way
for its particular architecture. In particular, it allows 36-bit
machines and 8-bit machines to communicate by using only 32 bits
out of each PDP-10 word, supposing that you say TYPE L and BYTE 8
or BYTE 32. (If you say TYPE L and BYTE 36, then you are using all
of the PDP-10 word, and telling the 8-bit end to use five bytes
for each PDP-10 word, or telling a 32-bit machine to use two of its
words for each PDP-10 word.)
There was never a TENEX type in the FTP spec. 8-bit Unix machines
had an FTP client program that accepted a TENEX command, which
caused it to send TYPE L and (I believe) BYTE 8. It was called
TENEX rather than PDP-10 because that FTP program was written at
a time when TOPS-10 didn't yet have virtual memory, and TOPS-20
didn't exist (that is, DEC hadn't yet bought TENEX from BBN), and
so almost all the PDP-10s on the Arpanet were running TENEX.
William
The first I ever heard of "TENEX" was when Murphy started to take the KIs
stand-alone to work on the OS that was would be sold as TOPS20. Is there
a connection between Murphy's TENEX and the "TENEX mode" that you
described as an Unixism?
Yes. TENEX was a paging OS for PDP-10s developed by BBN. With extensive
hacking by DEC, it became tops-20, eventually. I'm surprised that the unix
ftp command turned out to be "tenex" - by the time this became a widely
useful command (about the time WSMR put the entire CPM shareware libraries
on line at Simtel-20 (1980?)), tops20 existed and was pretty well
entrenched. Certainly by the time the net converted to TCP (1983) , TENEX
was no longer the dominant operating system for PDP-10 architecture
computers on the internet.
BillW
Carl R. Friend
Eric Werme wrote in post Nr. <werme.8...@alingo.zk3.dec.com>:
>
> alde...@netcom4.netcom.com (Richard M. Alderson III) writes:
>
> >"TENEX mode" was a Unixism, having to do with ....
> Uh, care to define "Unixism"? :-) The tenex mode I implemented in the
> CMU/Harvard FTP during my ARPAnet days had nothing to do with Unix!
Is it, perhaps, possible that "TENEX" was a contraction of "PDP-10
Exchange"? Admittedly, I was never involved directly with ARPAnet
connected -10s (I was with ADP Net. Services, which had its own "net"),
but dealt with enough systems of differing architectures that "exchange"
programs were required to communicate gracefully between them. -11s,
remember, were based upon the 8-bit byte rather than a "user-specified
group of contiguous bits".
--
______________________________________________________________________
| | |
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:carl....@cliff.swec.com | |
| http://www.ultranet.com/~engelbrt/carl/museum | ICBM: N42:22 W71:47 |
|________________________________________________|_____________________|
Eric Werme
alde...@netcom4.netcom.com (Richard M. Alderson III) writes:
>"TENEX mode" was a Unixism, having to do with ....
Uh, care to define "Unixism"? :-) The tenex mode I implemented in the
CMU/Harvard FTP during my ARPAnet days had nothing to do with Unix!
--
<> Eric (Ric) Werme <> Why Government Doesn't Work! For details <>
<> <we...@zk3.dec.com> <> visit http://www.HarryBrowne96.org/ <>
Scott Householder
Brian Harvey (b...@anarres.CS.Berkeley.EDU) wrote:
: jmf...@aol.com (JMFBAH) writes:
: >The first I ever heard of "TENEX" was when Murphy started to take the KIs
: >stand-alone to work on the OS that was would be sold as TOPS20. Is there
: >a connection between Murphy's TENEX and the "TENEX mode" that you
: >described as an Unixism?
: The Arpanet File Transfer Protocol supported five "representation types":
: TYPE A ASCII
: TYPE I image
: TYPE L local byte
: TYPE P print file
: TYPE E EBCDIC
: The first two of these are still in widespread use; most FTP programs
: have "ascii" and "image" commands. For this discussion, what you have
: to understand is the difference between types I and L.
[ deletia ]
: Type L, local byte type, to the rescue. It allows each end of the
: transfer to arrange the bit stream into bytes in a convenient way
: for its particular architecture. In particular, it allows 36-bit
: machines and 8-bit machines to communicate by using only 32 bits
: out of each PDP-10 word, supposing that you say TYPE L and BYTE 8
: or BYTE 32. (If you say TYPE L and BYTE 36, then you are using all
: of the PDP-10 word, and telling the 8-bit end to use five bytes
: for each PDP-10 word, or telling a 32-bit machine to use two of its
: words for each PDP-10 word.)
: There was never a TENEX type in the FTP spec. 8-bit Unix machines
: had an FTP client program that accepted a TENEX command, which
: caused it to send TYPE L and (I believe) BYTE 8. It was called
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes. Actcually , it sends "TYPE L 8". Thanks very much for jogging
my memory on this topic; I knew there was more to "Tenex mode" than
just another simple type, ala IMAGE (aka binary) and ASCII (aka text),
but I could not jog the dust off those old, (now) unused neurons ...
Thomas Spencer IV
sho...@alph02.triumf.ca (Tim Shoppa) writes:
>In article <4v7erk$6...@agate.berkeley.edu>,
>Brian Harvey <b...@anarres.CS.Berkeley.EDU> wrote:
>[Excellent answer to the question I posed in the subject line
> deleted for brevity - TDS].
>>See NIC 14333 for full info on the File Transfer Protocol at the
>>relevant time.
>Where would I find NIC 14333, or RFC 454 (which is often mentioned
>along with NIC 14333) online? A quick check of the ftp sites in North
>America that keep many of the RFC's didn't turn up
>either of these. (which, apparently, come from around 1973 or so.)
>Tim. (sho...@triumf.ca)
Hmmm, I'll have to hunt around for the old rfcs. I noticed that we
(one of the projects I work on is the D&D side of the internic) don't have
that one on the "official" rfc repository. Maybe on an old tape which I'll
dig through tomorrow.