The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1983)
DOCUMENT: TCP-IP Distribution List for January 1983 (33 messages, 9686 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1983/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:      15 Jan 1983 0438-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        tcp-ip
Cc:        Miller, roode
Subject:   SMTP test
THIS IS THE BEGINNING OF THE TEST...

	We are having a few problems debugging our SMTP mailer
and server.  Would you please send this message back to us,
along with any symptoms you might see.

	THIS IS GARBAGE TEXT TO TEST THE MAILER...

ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789

;TEST LOWER CASE

abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789


;THE FOLLOWING IS A TEST TO SEE WHAT HAPPENS IF THE SENDER
;SENDS A <CRLF>.<CRLF> SEQUENCE IN THE MIDDLE OF TEXT

BLAH,
BLAH,
.
BLAH,
BLAH...

.

	Your obedient serpent,

-HWM
-------
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1983 1053-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        ROODE, TCP-IP
Cc:        Postel at USC-ISIF, Taft%Parc at SANDIA, Miller
Subject:   Re: Telnet negotiations in SMTP
	As I read it, the SMTP spec had nothing to do with
telnet terminals.  When II was hacking it, I was just sending
data down via the JCN, and it seemed happy as a pig in mud.

	However, the document in the IPTW is incomplete:  t
does not include all possible telnet options as an earlier
one for NVT's did.

-HWM
-------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Sat 15 Jan 83 14:57:22-PST
From:      Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
To:        ROODE@SRI-NIC.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, Postel@USC-ISIF.ARPA, Taft%Parc@SANDIA.ARPA
Subject:   Re: Telnet negotiations in SMTP
     TELNET negotiations in SMTP are a bug.  There is a bug in my SMTP
in that when you send a QUIT command a Timing-Mark gets sent.  Also, I
think my SMTP answers TELNET negotiations if the user SMTP originates
them.  This is because there is no way to put a job on a TVT without
disabling protocol.  My SMTP carefully does not do anything to originate
protocol, but when you do a QUIT either DTACH% or LGOUT% do an internal
DOBE% which negotiates the Timing-Mark.

     My personal recommendation is to accept negotiations to the point
of ignoring them, and tell the SMTP implementor that his/her SMTP has
a bug.  In the case of my SMTP, I agree it's a bug, and I am committed
to fix it eventually.

-- Mark --
-------
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat 15 Jan 83 16:26:41-PST
From:      Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
To:        Taft@PARC-MAXC.ARPA
Cc:        ROODE@SRI-NIC.ARPA, TCP-IP@SRI-NIC.ARPA, Postel@USC-ISIF.ARPA
Subject:   Re: Telnet negotiations in SMTP
I agree with Ed.  My (minor) usage of TELNET protocol in the Score SMTP
server is a bug.  I hope that a single Timing-Mark while negotiating a
QUIT command does not seriously impact anybody (it really shouldn't,
since the message has already been delivered).
-------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1983 1815-PST
From:      HAGAN at USC-ISID
To:        Miller at SRI-NIC
Cc:        tcp-ip at SRI-NIC, roode at SRI-NIC
Subject:   Re: SMTP test
[ISID]<Hagan> found no problems.  Good luck!

Doug Hagan
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1983 1919-PST
From:      MILLS at USC-ISID
To:        ROODE at SRI-NIC, TCP-IP at SRI-NIC
Cc:        Postel at USC-ISIF, Taft%Parc at SANDIA, MILLS
Subject:   Re: Telnet negotiations in SMTP
In response to the message sent  15 Jan 1983 0706-PST from ROODE@SRI-NIC 

Folks,

Don't even think TELNET options in SMTP. If Jon doesn't beat you up
I'll send 5000 IACs to your FTP server. Think about that. I don't like
TELNET negotiations in FTP either, but at least there is some basis for
that in rescueing runaway data transfers with some servers.

Regards,
Dave
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 1983 2243-PST
From:      ROODE at SRI-NIC (David Roode)
To:        tcp-ip
Subject:   Postmaster mailing address
A useful new mail functionality is being overlooked at many sites.  In
section 6.3, RFC 822 (August 1982) specifies a reserved address of
Postmaster at each host that is supposed to accept general complaints
about problems with mail at that host.
-------
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      16-Jan-83 09:44:43-PST (Sun)
From:      mo@LBL-CSAM.ARPA (Mike O'Dell [system])
To:        cak@Purdue.ARPA
Cc:        tcp-ip@sri-nic.ARPA, mo@LBL-CSAM.ARPA
Subject:   Re: Telnet and SMTP
Yes indeed, poking a buggy server with Telnet is imminently useful,
in the absence of something else.  However, it is trivial to get
something else.  We have a programm named "mconnect" (named for
mail) which will make a bare connection to any specified remote port.
The terminal is run in cooked mode (local echos, local erase, line
kill, etc, processing...) but just copies lines too and from the
network connection.  This little tool is worth having, regardless
of name, on any machine with a network connection for the reasons
cited by Chris.

As an alternative, many user telnets have a mode where they don't
originate any negotiations (giving you pot-luck!).  This is probably
a reasonable substitute in a pinch.

There is another issue here - robustness.  I like this definition:
"A robust program is conservative in what it sends to others, but
is liberal in what it lets others get away with sending to it."
So, in principle, one could argue that a robust SMTP would ignore
all Telnet negotiations, or DONT them.  However, due to the complexity
of all the Telnet options, even parsing them is a pain because of
variable lengths and other stuff.  A non-trivial amount of mechanism has
to be present just to throw the options away.  Therefore, in spite
of how convenient or robust it might be, basing SMTP on Telnet
costs a great deal, and I think the cost clearly outweighs the
benefit, especially when the benefits are so easy to get other ways.

	-Mike

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1983 1756-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        DCP at MIT-MC, ROODE
Cc:        Hornig at MIT-MULTICS, mo at LBL-CSAM, cak at PURDUE, Postel at USC-ISIF, TCP-IP, Taft%Parc at SANDIA, Miller
Subject:   Re: Telnet negotiations in SMTP
	Might as well throw my two cents worth:  Telnet is good
for debugging, but it is just a trivial to to write a small
set of routines that will except text from you (or use pre-wired
strings), and force them down the SMTP port's throat.  This
is the procedure I used when hacking up an experimental SMTP
sender a few months back, and had about half of the send routines
written and debugged in a single morning.   Never even used TELNET.

-HWM
-------
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1983 1816-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        MILLS at USC-ISID, ROODE, TCP-IP
Cc:        Postel at USC-ISIF, Taft%Parc at SANDIA, Miller
Subject:   Re: Telnet negotiations in SMTP
	Speaking of Telnet negotiations, we saw this seqquence while
speaking to TOPS20 sites, which caused us to hang:

[TOPS20]	=>	<IAC><Do TimingMark>

	We had to respond with:


	<IAC><Will TimingMark>

to get anything to come thru, although Jon thinks

	<IAC><Won't TimingMark>

would work as well.  Alas, we never had time to try the latter.
KLH discovered this lossage.

-HWM
-------
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1983 1822-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        tcp-ip
Cc:        roode, Miller
Subject:   Re: SMTP test
	Your server died on the <CRLF>.<CRLF>

-HWM
-------
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 1983 2240-PST
From:      MOCKAPETRIS at USC-ISIF
To:        roode at SRI-NIC, tcp-ip at SRI-NIC, taft%parc at SANDIA, mills at ISID, admin.mrc at SU-SCORE, cak at PURDUE
Cc:        postel
Subject:   TELNET has no place in SMTP
There is no good reason to have TELNET negotiations in SMTP.  Mailers
that use them will either not work or degrade performance of the mail system.
(a la the MRC case of restricted TELNET pollution.)  

pvm
-------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1983 09:56:28-EST
From:      Christopher A Kent <cak@Purdue.ARPA>
To:        Miller@SRI-NIC
Cc:        Hornig@MIT-MULTICS, mo@LBL-CSAM, cak@PURDUE, Postel@USC-ISIF, TCP-IP@SRI-NIC, Taft@Parc, @, SANDIA@Purdue, Miller@SRI-NIC, DCP@MIT-MC, ROODE@SRI-NIC
Subject:   Re: Telnet negotiations in SMTP
Yup, I agree. I'm hacking up my own raw tty->net program today -- no
more Telnet to debug servers for me!

I think that we should follow Mark's suggestion -- swallow the options
and send back a message (would someone care to suggest a reply code?).

Cheers,
chris
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1983 1407-PST
From:      KLH at SRI-NIC
To:        MOCKAPETRIS at USC-ISIF, roode, tcp-ip, taft%parc at SANDIA, mills at USC-ISID, admin.mrc at SU-SCORE, cak at PURDUE
Cc:        postel at USC-ISIF
Subject:   Re: TELNET has no place in SMTP
I have been dealing with FTP and netmail for a long time, and
completely agree that TELNET negotiations don't belong in SMMTP.
I think the only reason it was mentioned at all was to grab onto
the existing TELNET-NVT definition of the ASCII char set; e.g. 
a bare CR should be sent as CR-NULL, etc.  However, only Postel
knows for sure what he had in mind at the time.  I would
be interested in hearing about any screw cases which TELNET
option negotiations are intended to handle...
-------
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1983 1518-PST
From:      KLH at SRI-NIC
To:        tcp-ip
Subject:   TOPS-20 TCP server bug?
At the Internet meeting a possible bug with TOPS-20 TCP was
mentioned; apparently if a SYN comes in for a port that is being
listened on (by a server), then things get into a state such that
if for some reason the synchronization does not proceed all the way
to OPEN, things will be hung; further SYNs from other remote sites
will not succeed, because only one process is LISTENing and the
state of that process is best described as wedged.  It is not clear
if there is any way for the server program itself to avoid this.
Any comments?  (Note, I have not looked at the code, being on a slow
terminal-- possibly this is a false alarm, but I'd like to find out).

--Ken
-------
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 1983 2157-PST
From:      POSTEL at USC-ISIF
To:        TCP-IP at SRI-NIC
Subject:   Telnet Signals & Options in SMTP

TELNET Signial and Options are explicitly forbidden on the SMTP connection.

--jon.
-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 1983 0034-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        tcp-ip
Cc:        roode, Miller
Subject:   Re: SMTP test
Lynn,
	You are dropping the "." between the <CRLF>'s.

-HWM
-------
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Fri Jan 21 15:52:45 1983
From:      lcg at MITRE-BEDFORD
To:        tcp-ip-request@sri-nic
Cc:        lcg
Subject:   TCP/IP
Louise Gilman
	    Mitre Corporation
	    Mail Stop J225
	    Box 208
	    Bedford, MA  01730

      Thank you.
				    Sincerely,
				    Louise Gilman


PS  If you would prefer to talk via phone
    my business Tel. # is (617)271-7678.
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 1983 2325-PST
From:      Joel Goldberger <JGoldberger@USC-ISIB>
To:        KLH at SRI-NIC
Cc:        tcp-ip at SRI-NIC
Subject:   Re: TOPS-20 TCP server bug?
To my knowledge there is no facility to "queue" SYNs as was possible with
NCP RFC's.  This does indeed result in the condition that was mentioned.  
We at ISI have changed our listeners to have an initial timeout of 30
seconds and then reset the timeout for the connection to 3 minutes.  This
means that at worst the listener will get wedged for 30 seconds.

- Joel -

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1983 0223-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        KLH, tcp-ip
Cc:        Miller
Subject:   Re: TOPS-20 TCP server bug?
	Hmm, it is possible, since the SYN response code is so scattered.
My main concern at the moment is the lack of timeout parameters in
RECV anc CLOSE, since if the distant host goes south of the border,
the listener mighht well hang until the sun novas, or until the next
crash waiting.  (Assuming, of course DATE48 doesn't happen.  Date 48
will happen in 2048, and is anologous to DATE75, when the 18 bit field
wiill be filled.)

-HWM
-------
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 1983 0230-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        JGoldberger at USC-ISIB, KLH
Cc:        tcp-ip, Miller
Subject:   Re: TOPS-20 TCP server bug?
	To my knowledge also (and II know that code well...) there
is no way to q SYN's.  Your suggestion sounds timely and is well taken.

-HWM
-------
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1983 1050-PST
From:      Mathis at SRI-KL
To:        KLH at SRI-NIC
Cc:        tcp-ip at SRI-NIC, Mathis at SRI-KL
Subject:   Re: TOPS-20 TCP server bug?
Ken,
   A solution would be to allow multiple listening connections for the
same local port.  Nothing in the spec would prohibit this.
-------
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 1983 1851-PST
From:      POSTEL at USC-ISIF
To:        TCP-IP at SRI-NIC
Subject:   TCP servers and Listening Ports

KLH raised a concern about application servers being locked up (i.e.,
not listening) while a connection is in the process of opening.  This
is a real possibility if the server is constructed in (as several are)
a way that does not start a new listen until the open negotiation is
completed or times out.  Joel Goldberger noted that one could (as ISI
TOPS20s now do) put a short time out on the open negotiation, and a longer
time out on the data transfer phase of the connection.  I would like
to point out that it is also possible to construct a server such that
it starts a new listen as just as the open negotiation is begun, and
thus nearly always have a listen pending independent of the outcome of
any specific open negotiation.  This generally takes a bit more planning
and control in the top level process, but it may be worth the effort if
non-listening servers become a significant complaint.

--jon.
-------

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      25 January 1983 07:48 est
From:      JSLove at MIT-MULTICS (J. Spencer Love)
To:        KLH at MIT-MC
Cc:        TCP-IP at SRI-NIC, JSLove.PDO at MIT-MULTICS
Subject:   TCP Services caught with their pants down
The Multics TCP implementation includes a type of connection called a
"template", which is a TCB in the listening state which spins off
"clones" whenever an attempt is made to connect to it.  The only
operations permitted on a template are creation (passive OPEN) and
destruction (ABORT).  The TCB sends messages to the owning process which
are the handles of the clones when they are created (actually, when they
enter the established state, since the TCP can handle that negotiation
without bothering the service process).

I realize that this is a lot of hair to go to, but it does guarantee
that there are no windows when a service request could get a RST instead
of a SYN.
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      25 January 1983 09:11 est
From:      Ata.SysMaint at RADC-MULTICS
To:        Mathis at SRI-KL
Cc:        KLH at SRI-NIC, tcp-ip at SRI-NIC
Subject:   Re: TOPS-20 TCP server bug?
You cannpt have 2 unrestricted listens on the same local port.  This is
because a unrestricted listen is defined to have a foreign port of 0.  2
Unrestricted listens on the same local port would result in 2 TCBS with
the same local/foreign port combination.  This is in violation of the
specs.
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1983 1318-PST
From:      Mathis at SRI-KL
To:        Ata.SysMaint at RADC-MULTICS
Cc:        KLH at SRI-NIC, tcp-ip at SRI-NIC, Mathis at SRI-KL
Subject:   Re: TOPS-20 TCP server bug?

The intent of the spec is to unambigiously define to which TCB an incoming
segment refers.  The issues of having multiple unspecified listens on the
same local port is primarily a local implementation detail since consistent 
external behavior to other TCPs can be achieved.  Multiple fully specified
connections on the same local/foreign port pairs are not allowed.

-------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 1983 1348-PST
From:      Henry W. Miller <Miller at SRI-NIC>
To:        POSTEL at USC-ISIF, TCP-IP
Cc:        Miller
Subject:   Re: TCP servers and Listening Ports
	Several of our servers do it that way, or simply fire
up a number of server sub-forks upon initializing.  The monitor,
if I am not mistaken, fires up listeners upon TVT initializatoin,
and hands them off to the TVT when a connect occurs.

-HWM
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1983 1054-PST
From:      MOCKAPETRIS at USC-ISIF
To:        KLH at SRI-NIC
Cc:        MOCKAPETRIS at USC-ISIF, postel at USC-ISIF, tcp-ip at SRI-NIC, mathis at SRI-KL
Subject:   Re: TOPS-20 TCP server bug?
In response to your message sent  17 Jan 1983 1518-PST

At ISI we have noted the hung listener problem (it does happen) and
reset the listening port if the connection doesn't go to established
within a minute.

If you use PSIs to detect a new connection on the listen port, you
should also protect against connection establishment between the time of
the OPEN and the CHANL for the state change.  Alas, this can also 
happen.

paul
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 83 08:21:36 CST
From:      schur at COMPION-VMS
To:        tcp-ip at sri-nic
Cc:        schur
Subject:   ftp multiple transfer problem
During the implementation of ftp we have noticed the following
problem with the interaction of the ftp and tcp protocols:

1. When a data transfer is started a connection is
opened between the user ftp port and the
server ftp port - 1.

2. In many cases the data connection must be closed
to indicate EOF. At this point, the connection
will start closing and eventually go into
the TIME-WAIT state (for an arbitrary period
of two minutes, as the protocol indicates).

3. If ftp wishes to open the data connection again during
this TIME-WAIT period, it will not be allowed to
do so, since it would be using the same local
and foreign ports, and foreign internet address.
The TCP protocol requires that we be able to receive
packets for the connection in the TIME-WAIT state,
so we can't reopen a new connection until it has
completely closed.

This scenario causes an unacceptable delay when using ftp for multiple
transfers requiring opening and closing of the data connection.

Do other implementors have this problem. If not, what fix did you apply or
is there something in the protocols that I have missed.

John Schur
<schur at compion-vms>
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 83 08:46:12 CST
From:      schur at DTI-VMS
To:        tcp-ip at sri-nic
Subject:   resending using old site name
I am resending this message using our old site name, since some sites
would not accept this mail because they did not know of our new name.
I apologize to anyone who is receiving this twice. Please send all
replies to <schur at compion-vms>.


During the implementation of ftp we have noticed the following
problem with the interaction of the ftp and tcp protocols:

1. When a data transfer is started a connection is
opened between the user ftp port and the
server ftp port - 1.

2. In many cases the data connection must be closed
to indicate EOF. At this point, the connection
will start closing and eventually go into
the TIME-WAIT state (for an arbitrary period
of two minutes, as the protocol indicates).

3. If ftp wishes to open the data connection again during
this TIME-WAIT period, it will not be allowed to
do so, since it would be using the same local
and foreign ports, and foreign internet address.
The TCP protocol requires that we be able to receive
packets for the connection in the TIME-WAIT state,
so we can't reopen a new connection until it has
completely closed.

This scenario causes an unacceptable delay when using ftp for multiple
transfers requiring opening and closing of the data connection.

Do other implementors have this problem. If not, what fix did you apply or
is there something in the protocols that I have missed.

John Schur
<schur at compion-vms>
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      27 January 1983 12:42 est
From:      Ata.SysMaint at RADC-MULTICS
To:        schur at COMPION-VMS
Cc:        tcp-ip at SRI-NIC
Subject:   Re: ftp multiple transfer problem
Yes, we have the same problem as other impelmentators do.  A bypass is
to use the port command specifying a different port for each file
transfer.
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Jan 83 16:20:49 CST
From:      schur at COMPION-VMS
To:        tcp-ip at sri-nic
Cc:        schur
Subject:   multiple ftp transfers
Other than using the port command to do multiple ftp transfers,
does anyone have another solution that doesn't violate any
protocols. Is there any consideration being given to changing
the protocols to fix this problem?

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 1983 1852-PST
From:      POSTEL at USC-ISIF
To:        tcp-ip at NIC
Subject:   FTP Clarifications

< INC-PROJECT, FTP-NOTE.NLS.3, >, 28-Jan-83 18:51 JBP ;;;;

There are several changes and clarifications needed in the File Transfer
specification (RFC-765 = IEN-149).  Here are two important points.

1.  Mail Commands:  The mail commands in the FTP are NOT to be 
implemented. Use the separate SMTP protocol instead.

2.  Data Connection Management:

   a.  Default Data Connection Ports:  All FTP implementations must 
   support use of the default data connection ports, and only the 
   User-PI may initiatate the use of non-default ports.

   b.  Negotiating Non-Default Data Ports:   The User-PI may specify a 
   non-default user side data port with the PORT command.  The User-PI 
   may request the server side to identify a non-default server side 
   data port with the PASV command.  Since a connection is defined by 
   the pair of addresses, either of these actions is enough to get a 
   different data connection, still it is permitted to do both commands 
   to use new ports on both ends of the data connection.

   c.  Reuse of the Data Connection:  When using the stream mode of data
   transfer the end of the file must be indicated by closing the 
   connection.  This causes a problem if multiple files are to be 
   transfered in the session, due to need for TCP to hold the connection
   record for a time out period to guarantee the reliable communication.
   Thus the connection can not be reopened at once.  

      There are two solutions to this problem.  The first is to 
      negotiate a non-default port (as in (b) above).  The second is to 
      use another transfer mode.

      A comment on transfer modes.  The stream transfer mode is 
      inherently unreliable, since one can not determine if the 
      connection closed prematurely or not.  The other transfer modes 
      (Block, Compressed) do not close the connection to indicate the 
      end of file.  They have enough FTP encoding that the data 
      connection can be parsed to determine the end of the file.  Thus 
      using these modes one can leave the data connection open for 
      multiple file transfers.

      Why this was not a problem with the old NCP FTP: 

         The NCP was designed with only the ARPANET in mind.  The 
         ARPANET provides very reliable service, and the NCP counted on 
         it.  If any packet of data from an NCP connection were lost or 
         damaged by the network the NCP could not recover.  It is a 
         tribute to the ARPANET designers that the NCP FTP worked so 
         well.

         The TCP is designed to provide reliable connections over many 
         different types of network and interconnections of networks.  
         TCP must cope with a set of networks that can not promise to 
         work as well as the ARPANET.  TCP must make its own provisions 
         for end-to-end recovery from lost or damaged packets.  This 
         leads to the need for the connection phase-down time-out.  The 
         NCP never had to deal with acknowledgements or retansmissions 
         or many other things the TCP must do to make connection 
         reliable in a more complex world.



--jon.
-------

END OF DOCUMENT