The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for January 1984 (19 messages, 10572 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Wed, 4 Jan 84  9:38:18 EST
From:      Mike Brescia <brescia@BBN-UNIX>
To:        hu@columbia-20
Cc:        mrc@su-score, brescia@BBN-UNIX
Subject:   bug associated with tops-20 release 5.3
There appears to be a bug in tops-20 release 5.3 which causes some bits to
be garbled in the IP leader of internet messages.  The possible effect is
that mail or connections to UCL-CS or NTA-VAX may fail.

Mark Crispin has sent some info to the tops-20 implementers mailing list
about a fix for this problem.  If you are having traffic failures, you
should look into the fix soon.

Mike Brescia (big gateway is watching you)

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Wed 4 Jan 84 16:40:08-PST
From:      Allan M. Schiffman <Schiffman at SRI-KL>
To:        tcp-ip at SRI-NIC
Subject:   The best way to use TCP with VMS?
	I would appreciate advice on what software I should get to run
TCP on VMS systems.

	I'm interested in connecting a bunch of Vaxen running VMS to a
bunch of Vaxen and Suns running 4.2 (and TCP, of course) with Ethernet
hardware. 

	I've heard that there is stuff available from Wollagong and
Compion (sp?).  How do I contract these companies?  Any experience
with either of these?  Are there other vendors?

	Please reply directly to me, I am not on the list.

Allan M. Schiffman
Fairchild AI Lab, Palo Alto
-------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 1984 1831 PST
From:      Eric P. Scott <EPS@JPL-VAX>
To:        TCP-IP@SRI-NIC
Cc:        Info-VAX@SRI-KL,TOPS-20@SU-SCORE
Subject:   Spreading the gospel
To them, TCP/IP is an "alternative network technology,"
"internet software" means IBM protocol emulator, X.25 is THE way
to achieve multi-vendor compatibility, and understanding of
networking internals is a black art.  We who (of course) know
better once again have the opportunity to liberate misguided
little minds from such nonsense.  Yes kids, I refer to none other
than the 1984 Spring DECUS U.S. Symposium!  Being the good (hah!)
volunteer that I am, I'll request a VAX/VMS ARPANET/DDN Users
session, try to schedule it early in the week, and not against
the TOPS-20 session.  I need additional speakers, so let me know
before the deadline if you're willing.

What I really want to see this time is some other sessions for
the benefit of those who don't know what TCP/IP is all about.
The deadline for abstracts is January 20, so let's try to develop
a workable plan of attack reasonably soon so we can submit
several together with appropriate scheduling constraints.  Am I
talking conspiracy here?  You bet.
					-=EPS=-
------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      18 January 1984 13:17 EST
From:      dca-pgs @ DDN1
To:        ddn-nl @ DDN1, feinler @ sri-nic, leiner @ sri-nic, tcp-ip @ sri-nic
Cc:        maybaum@dca-ems,mcduffie@dca-ems,dca-pgs
Subject:   Tymnet Hardware Product; DDN Host Interface; DCA/Tymnet Meeting Report


Date: January 18, 1984
Comment: 
As reported earlier, Tymnet has made a corporate decision and
commitment to produce and market a DDN interface product, which would
be offered to DoD DDN subscribers for the purpose of interfacing to DDN.
This interface product would have a Tymnet implementation of TCP/IP and
would be fully DDN compatible.

The undersigned hosted a meeting with Tymnet personnel on 17 Jan
at the DDN/PMO. Purpose was to obtain more details on the Tymnet product
concept and to provide informal public-domain information and public-
domain protocol spec documentation to Tymnet.

Besides offering their well-known packet-switched network services,
Tymnet has been independantly marketing interface hardware components
(the so-called Engine family) since summer 1983, offering Engines as
a stand-alone product separate from Tymnet networking services.
Tymnet plans to implement TCP/IP and make it available as an option
in the Engine line. 

Two types of host interfaces will be offered:
  
  (1)Network Front-End Processor - This would provide a host with
     a TCP/IP+X.25 interface to DDN.
  (2)Terminal Emulation Processor - In this approach, the host would
     interface DDN in a "dumb-TTY" mode; the Tymnet interface would
     present the host with a field of TTY ports. Host-host connections
     would not be supported under this arrangement.

Terminal interface products would also be available. The Terminal
Emulation Processor mentioned above would necessarily function as an
inverse Terminal Access Processor. Both devices would need to
incorporate the Telnet Network Virtual Terminal protocol.

The Tymnet network supports synchronous terminals at this time.
(IBM 3270 Bisync & SNA, Honeywell VIP 7705)
It is thought that Tymnet's work in this area may be of value in
developing synchronous terminal interfaces for DDN.

A question was also raised concerning the following scenario:
Would it be desirable for a capability to exist whereby a terminal
could access Tymnet via a local Tymnet X.25 network facility, then
would pass through a Tymnet/DDN X.75 gateway and access DDN?
The payoff of this capability is that this would greatly expand
local terminal access capability to DDN in a short time, since Tymnet
local terminal access facilities are already in operation.

Issues:
  (1) Should this be done?
  (2) What initiatives would DDN undertake in the development of
      Tymnet (or VAN) terminal gateways?
  (3) What should such a VAN terminal gateway look like, besides
      X.75? Probably TCP/IP and Telnet would be introduced at this
      point.
  (4) What about TACACS? Likeliest approach would be to
      put it in the VAN terminal gateway. Access control is seen
      to be the most sensitive issue arising from the VAN terminal
      gateway concept; of course, it is well known that host security
      must be implemented at the host level. Putting TACACS in
      the VAN terminal gateway would provide the same level of
      protection that TACACS in the TAC's provides; only difference
      is that the terminal accessor would reach TACACS via VAN instead
      of via dial-up phone circuit.


Tymnet was supplied at subject meeting with a full set of public-domain
DDN specs (X.25, IP, ICMP, TCP, SMTP, FTP, Telnet). It was also strongly
recommended that Tymnet pursue getting an Arpanet electronic mail account,
such as that available to DoD-sponsored customers from Tymshare. A follow-up
meeting was tentatively scheduled for the second week in February.

The undersigned wishes to thank Mr. Rod Richardson and MAJ Mike Allen of
the DDN/PMO, and Messrs. Len Ghiorsi and Pat Plunkett of Network Strategies,
Inc. for their valuable participation at the meeting. The undersigned also
would like to commend Tymnet, for their initiative in pursuing this venture.


Sincerely,
Pat Sullivan
DCA/DDN/PMO
<dca-pgs@ddn1>
Forwarded message(s):  
-----------------------------------------------------
Date:  Tue, 17 Jan 84 16:12:00 EST
From: dca-pgs @ ddn1
Subject:  Attendance List for Tymnet/DCA Meeting, 17 Jan 1984, DDN/PMO
To: dca-pgs @ ddn1
Text: 

NAME                  ORG'N                   PHONE

Pat Sullivan          DCA/B616                (703)285-5036

Linda Berdine         Tech. Mgr., Tymnet      (703)827-9110

Jerry Edgerton        Tymnet Federal Mgr.     (703)827-9110

Frank Tapsell         Tymnet Federal
                        Marketing Staff       (703)827-9110

Rod Richardson        DCA/B616                (703)285-5137
 
Len Ghiorso           NSI                     (703)425-7440

Pat Plunkett          NSI                     (703)425-7440

MAJ M. Allen          DCA/B616                (703)285-5025



 
-------------END OF FORWARDED MESSAGE(S)-------------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      19 January 1984 08:16 EST
From:      mundy @ DDN1
To:        dca-pgs @ DDN1
Cc:        ddn-nl @ DDN1, feinler @ sri-nic, leiner @ sri-nic, tcp-ip @ sri-nic, maybaum@dca-ems,mcduffie@dca-ems,dca-pgs
Subject:   Re: Tymnet Hardware Product; DDN Host Interface: DCA/Tymnet Meeting Report


Date: January 19, 1984
Text: Pat,
The Tymenet development has lots of potential (mostly good, some not so
good) and I thank you for the good summary.  As the JCS guy who is 
supposed to be tracking our future data communications systems, I would 
like to participate in future meetings on this subject if I can.  If
possible I'd like to get some advance notice to fit them into my 
schedule.

Thanks,

Russ Mundy


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 1984 1636 PST
From:      Eric P. Scott <EPS@JPL-VAX>
To:        TCP-IP@SRI-NIC
Cc:        Info-VAX@SRI-KL,TOPS-20@SU-SCORE
Subject:   ARPAnet/DDN Session at Spring DECUS
I received quite a bit of positive feedback (from DEC even!) to
my "Spreading the gospel" query, but alas no one seems prepared
this early in the game to make firm commitments.  Unless I hear
a bunch of "I'll help!"'s by tomorrow afternoon, I will request
2 hours for "Internetworking the ARPA way," a series of mini-
sessions tied together by a common theme.  Some of these will
be geared toward the pagan masses, some will be presentations on
work done and in progress (using DEC computers), and somewhere
in there will be a users panel.  I expect representatives from
the DDN-PMO and Digital to be in attendance.  I need volunteers,
I need volunteers, I need volunteers...

					-=EPS=-
------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 84 07:13:37 EST
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        EPS@JPL-VAX.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, Info-VAX@SRI-KL.ARPA, TOPS-20@SU-SCORE.ARPA
Subject:   Re: ARPAnet/DDN Session at Spring DECUS
I would certainly be happy to help.  I will definitely be at DECUS,
since it is in my home town!  [You will finally get a list of good
restaurants.]  Anything in particular you would like from me.  I
know, or can find out by then, about most of the software and
protocols commonly used on the 20.  I don't know as much as some
of the folks at Stanford, BBN, and ISI, and I use only DDN itself,
I don't use TCP for local networking [yet].
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 1984 1727 PST
From:      Eric P. Scott <EPS@JPL-VAX>
To:        TCP-IP@SRI-NIC
Cc:        TOPS-20@SU-SCORE,Info-VAX@SRI-KL
Subject:   "Internetworking the ARPA Way" at Spring DECUS
I have requested two hours sponsored by the Networks SIG for
"Internetworking The ARPA Way" with the following abstract:

Originally designed to replace the traditional Host-to-Host
protocol used on the ARPAnet until 1983, TCP/IP is rapidly
gaining acceptance outside the ARPA community due to its
inherent suitability to local area networks and independence
from any particular manufacturer, machine architecture, or
operating system, as well as bundled support in Berkeley's
4.2 VAX Unix distribution.  The specifications for the DoD
Standard Protocol Suite of which TCP/IP is the most well-known
are in the public domain; implementations for various systems
are available from several vendors.

This session will consist of several back-to-back subsessions
intended to introduce newcomers to the ARPA philosophy, current
R&D in the field, current concerns and future directions, and
Digital's commitments to support this technology.  Time will
be provided for questions and general discussion, but it is
suggested that experiences with particular hardware/software
combinations be the subject of Birds-of-a-Feather sessions.


Listed speakers are myself, Mark Crispin of Stanford University,
Charles Hedrick of Rutgers University, an unnamed representative
of the DDN Program Management Office, and an unnamed Digital
Person.  All that has been accomplished is that a block of time
has been requested for scheduling.  Between now and June we have
to work out the details of how that time will be used.

					Eric P. Scott
			      Networked Computer Systems Group
			  Computer Science and Applications Section
				  Jet Propulsion Laboratory
------
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1984 11:48:16 PST
From:      POSTEL@USC-ISIF
To:        dewolf@COMPION-VMS, tcp-ip@SRI-NIC
Cc:        POSTEL@USC-ISIF
Subject:   Re: IP options and gateways
In response to the message sent  Mon, 23 Jan 84 12:14:11 CST from dewolf@compion-vms


Peter DeWolf:

Hi:

We have done some source route testing from a Perq at ISI and found that
most of the BBN operated Gateways did perform the source routing correctly.
Also many of the TOPS20 hosts will do source routing.  If you want to
arrange a joint testing session send a note to Alan Katz (KATZ@USC-ISIF).

--jon.
-------
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jan 84 12:14:11 CST
From:      dewolf@compion-vms
To:        tcp-ip@sri-nic
Cc:        dewolf@compion-vms
Subject:   IP options and gateways
I am looking for a gateway that is known to properly implement IP route options.

I am trying to test our implementation of such options.  I have a test program
which tells our IP to send packets with specified (loose or strict) routes.
I have verified that our IP handles such packets properly itself -- it will
forward such packets among out locally connected networks just fine, advancing
the route pointer, decrementing TTL.  In other words, behaving as one would
expect a gateway to act.

I examined the bytes being sent out, and all looks to be in the proper order.
I then decided to see if my implementation agrees with the rest of the world's
interpretation by sending packets to other gateways with source routing that
specifies that the packet be sent back to compion-vms.  I sent to the
following gateways:

26.0.0.29	26.0.0.58	26.0.0.81	26.0.0.103
26.0.0.104	26.0.0.105	26.0.0.106	26.1.0.40
26.2.0.49	26.2.0.57	26.2.0.73	26.3.0.29
26.3.0.75	26.3.0.81	26.7.0.8	26.8.0.65

I never received anything back from any of the gateways.  My packets were
never routed back to me.  No ICMP messages (parameter problem, whatever)
were returned to me.

Does anybody know if any of these gateways are supposed to process IP loose
source route or strict source route options?
Does anybody know of ANY gateway that supposedly processes such options?

Thank you!


					Peter DeWolf
					Compion Corporation
					dewolf@compion-vms
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Jan 84 14:57:22 EST
From:      Mike Brescia <brescia@BBN-UNIX>
To:        dewolf@compion-vms
Cc:        tcp-ip@sri-nic, brescia@BBN-UNIX
Subject:   Re: IP options and gateways
P. DeWolf,

The following gateways from your list are claimed to implement source route
options, both strict and loose.  We have run a test program against the
gateway implementation, and the same test program works against the
independent implemention on the BBNF tops20.

    aerospace milarpa milbbn mildcec milisi milsac milsri minet yuma

The same code also runs in the rest of the gateways listed in the NIC
data base as "IP/PRIME".

The one problem you will find is that the record route stored by these
gateways is incorrectly marked as the address on which the gateway received
the packet rather than the address which the gateway uses for output.

Mike Brescia

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 1984 23:26:06 PST
From:      MILLS@USC-ISID
To:        brescia@BBN-UNIX, dewolf@COMPION-VMS
Cc:        tcp-ip@SRI-NIC, MILLS@USC-ISID
Subject:   Re: IP options and gateways
In response to the message sent  Mon, 23 Jan 84 14:57:22 EST from brescia@BBN-UNIX

Peter,

DCN-GATEWAY (10.3.0.17, 128.4.0.1, 128.5.0.1, 128.8.0.1) shares the smae
attributes with the gateways Mike mentions. In addition, all the DCN
fuzzballs scattered over the globe implement source route along with
the record-route limitation Mike mentions.

Dave
-------
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri 27 Jan 84 20:44:00-PST
From:      Mark Crispin <MRC@SU-SCORE.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   FTP implementation questions
     I have the following questions for the Internet community regarding
FTP.  Instead of hearing a chorus of "no"s I would rather just hear from
those who can answer "yes" to any or all of the following questions:

. Does your FTP implementation implement TYPE L with bytesizes OTHER than
  8, 32, or 36?  If so, is it useful or necessary to transfer with such a
  bytesize?

. Would you consider as deficient an FTP implementation which did not
  support a TYPE L bytesize other than 8, 32, or 36?  Would a useful data
  transfer be prevented by this deficiency?  Give examples.

. Considering that PDP-10's store ASCII text as 5 7-bit bytes packed from
  MSB in a 36-bit word, would you consider it incorrect for a PDP-10 FTP
  implementation to treat TYPE L 7 as TYPE A?  Remember that while purists
  will argue that TYPE A should be more or less equivalent to TYPE L 8,
  such a transfer would not produce a meaningful "ASCII text file" on a
  PDP-10.  If you disagree, please give examples.  [Note that this is the
  way the present Tenex/TOPS-20 FTP software works!]

. The current FTP standard does not define the 0xx FTP reply codes the way
  the previous one did.  Do you feel that an FTP server should be prevented
  from issuing any unsolicited or "irrelevant" replies, or that it is
  alright to continue to use a 0xx FTP reply code?  What will your FTP user
  software do when it encounters a 0xx reply code (I feel that the "right
  thing" is to ignore it, optionally printing it on the user's terminal).

. Consider an FTP implementation where the REIN command is not implemented
  and you cannot change your USER once you have logged in.  Suppose this
  implementation allows an unlogged-in RETR by doing an implicit login of
  ANONYMOUS (the special account which allows retrieval of public-access
  files).  Should the FTP implementation announce the auto-login?  If 0xx
  codes are allowed, 030 is the obvious code.  If 0xx is not allowed, what
  would you consider valid for it to use to announce the auto-login
  (remember, this will prevent a login as something else).

. Does your FTP user process change the port after each data transfer in
  Stream mode?

. Does your FTP user process implement a mode other than Stream mode?  If
  so, which?
-------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      28-Jan-84 02:21:38-UT
From:      mills@dcn6
To:        saltzer@multics
Cc:        tcp-ip@nic
Subject:   DCN time server ticks again
For Jerry and the rest of you pinging the DCN1 (128.4.0.1) time server: that
clock is once again ticking to the WWVB tocks following our move to a new
office location. The precision should be within a couple of milliseconds
relative to NBS time when the 'gram leaves our shop.

I encourage our clock watchers, in particular the horde at BBN, to use UDP
in preference to TCP, since the former are faster, more accurate and use
fewer fuzzball resources.

Dave
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 84  1040 PST
From:      Joe Weening <JJW@SU-AI>
To:        Hornig%SCRC-QUABBIN@MIT-MC
Cc:        MRC@SU-SCORE, TCP-IP@SRI-NIC
Subject:   Re: FTP implementation questions
I am interested to hear how you implement TYPE L for various byte sizes
other than multiples of 8 bits.  My interpretation of "TYPE L n" is that
you read or write n-bit bytes from the host file system in whatever way is
standard, and transmit them packed as tightly as possible in the 8-bit TCP
transmission bytes.  Certainly this is what most PDP-10 implementations do
for TYPE L 36, making it equivalent to TYPE I (at the PDP-10 end).  When
the byte size is not a multiple of 8, the packing and unpacking of the
transmission bytes requires extra work in most machines.

On the other hand, Mark Crispin has proposed that TYPE L 7 imply the
transmission of each 7-bit byte in an 8-bit byte.  This can be generalized
to using the least multiple of 8 bits greater than or equal to the byte
size.  This avoids the packing/unpacking overhead, but it requires a
larger number of transmission bits to send the same information.  If this
interpretation is adopted, is there agreement on whether the unused
transmission bits are placed to the left or the right of the data bytes?
A further question arises for bytes sizes of 4 or less: Should as many
data bytes as possible be packed into each 8-bit transmission byte?

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jan 84 11:05 EST
From:      Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA>
To:        Mark Crispin <MRC@SU-SCORE.ARPA>, TCP-IP@SRI-NIC.ARPA
Subject:   FTP implementation questions
    Date: Fri 27 Jan 84 20:44:00-PST
    From: Mark Crispin <MRC@SU-SCORE.ARPA>

	 I have the following questions for the Internet community regarding
    FTP.  Instead of hearing a chorus of "no"s I would rather just hear from
    those who can answer "yes" to any or all of the following questions:

Answers are for the Symbolics Lisp Machine FTP server.

    . Does your FTP implementation implement TYPE L with bytesizes OTHER than
      8, 32, or 36?  If so, is it useful or necessary to transfer with such a
      bytesize?

We implement byte all byte sizes between 1 and 16 bits.  We do NOT
implement 32 or 36.  We use TYPE L 16 for our executable code files,
which have a natural byte size of 16 bits.  (Our user end falls back to
TYPE I when storing such a file somewhere which doesn't support TYPE L
16, but that leads to byte-swapping problems in some cases.)

    . Would you consider as deficient an FTP implementation which did not
      support a TYPE L bytesize other than 8, 32, or 36?  Would a useful data
      transfer be prevented by this deficiency?  Give examples.

Yes.  If our byte size above hadn't happened to be a multiple of 8 bits,
we wouldn't be able to fall back to TYPE I without possibly losing
information when the length of the file is rounded in the image transfer
process.  As it is, when you look at our executable file transferred in
TYPE I to a big-ender machine the 16-bit bytes appear with their 8-bit
bytes reversed.

    . Considering that PDP-10's store ASCII text as 5 7-bit bytes packed from
      MSB in a 36-bit word, would you consider it incorrect for a PDP-10 FTP
      implementation to treat TYPE L 7 as TYPE A?  Remember that while purists
      will argue that TYPE A should be more or less equivalent to TYPE L 8,
      such a transfer would not produce a meaningful "ASCII text file" on a
      PDP-10.  If you disagree, please give examples.  [Note that this is the
      way the present Tenex/TOPS-20 FTP software works!]

Assuming that the PDP-10 uses NVT ASCII to store files internally, this
is correct.  PDP-10's should always use the format produced by DPB for
odd byte sizes.

    . Does your FTP user process change the port after each data transfer in
      Stream mode?

Yes.  Otherwise you lose big with TCP.

    . Does your FTP user process implement a mode other than Stream mode?  If
      so, which?

Yes, Block mode.  Much good it does us, as the only only other Block
mode implementation I have found is on Multics, and it is broken.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Jan 84 14:14 EST
From:      Charles Hornig <Hornig%SCRC-QUABBIN@MIT-MC.ARPA>
To:        Joe Weening <JJW@SU-AI.ARPA>
Cc:        MRC@SU-SCORE.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: FTP implementation questions
    Date: 30 Jan 84  1040 PST
    From: Joe Weening <JJW@SU-AI>

    I am interested to hear how you implement TYPE L for various byte sizes
    other than multiples of 8 bits.  My interpretation of "TYPE L n" is that
    you read or write n-bit bytes from the host file system in whatever way is
    standard, and transmit them packed as tightly as possible in the 8-bit TCP
    transmission bytes.  Certainly this is what most PDP-10 implementations do
    for TYPE L 36, making it equivalent to TYPE I (at the PDP-10 end).  When
    the byte size is not a multiple of 8, the packing and unpacking of the
    transmission bytes requires extra work in most machines.

This is the interpretation we use.  Due to the tagged machine
architecture, we have to do the packing/unpacking for any byte size
other than 8.

    On the other hand, Mark Crispin has proposed that TYPE L 7 imply the
    transmission of each 7-bit byte in an 8-bit byte.  This can be generalized
    to using the least multiple of 8 bits greater than or equal to the byte
    size.  This avoids the packing/unpacking overhead, but it requires a
    larger number of transmission bits to send the same information.  If this
    interpretation is adopted, is there agreement on whether the unused
    transmission bits are placed to the left or the right of the data bytes?
    A further question arises for bytes sizes of 4 or less: Should as many
    data bytes as possible be packed into each 8-bit transmission byte?

This is not a change in interpretation, it is an incompatible change in
the specification.  The existing document states quite clearly that the
data bytes are packed without regard to the transfer byte boundaries.
If you want to add it to FTP, I suggest that you add a new type rather
than trying to redefine TYPE L.

Also, this change does not avoid the packing/unpacking overhead, it
merely changes the algorithm to be used to one which is supposedly
easier to implement on some computers.  I would have to be convinced
that itis worth changing this at this point in the life of FTP.  The
effort would better be invested in designing a good file access
protocol.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 1984 17:38-PST
From:      LEINER@USC-ISI
To:        EPS@JPL-VAX
Cc:        TCP-IP@SRI-NIC, TOPS-20@SU-SCORE, Info-VAX@SRI-KL
Subject:   Re: "Internetworking the ARPA Way" at Spring DECUS
Eric,

Small  but not minor correction.  TCP/IP was not designed for the
purpose  of  replacing  NCP  but  was  designed  to  support   an
environment  consisting  of  multiple heterogeneous networks each
capable of providing datagram service at a minimum.  IP  provides
the  means  for interconnecting the networks and TCP provides the
means  for  providing  a  virtual  circuit  using  that  datagram
service.

Barry
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 1984 17:40-PST
From:      LEINER@USC-ISI
To:        EPS@JPL-VAX
Cc:        TCP-IP@SRI-NIC, TOPS-20@SU-SCORE, Info-VAX@SRI-KL
Subject:   Re: "Internetworking the ARPA Way" at Spring DECUS
Eric,

I'd  like  to  ask  you to provide a pre-pub copy of what you are
planning on presenting if you  intend  (as  it  sounds  from  the
aabstract) to represent the ARPA philosphy, approach, etc.

Thanks much.

Barry

END OF DOCUMENT