Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  FTP incompatibility
Message-ID: <8904271501.AA13921@gateway.mitre.org>
Date: 27 Apr 89 15:01:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26

I had always thought it was specified that the server data port was to
be associated with the IP address of the control connection, except if
PASV came into play.  I made remarks in Host Requirements WG recently
which implicitly assumed this, and no one complained at the time.  It
looks like you're right, though, the RFC doesn't come out and say it in
so many words.  I would suggest that the second paragraph of section 5.2
when interpreted in the context of the first paragraph, takes on a rather
odd flavor if it is not assumed that the IP address is the same.  The
server is supposed to "initiate the data connection from his own default
data port (L-1)" and it seems rather tortured to interpret this as "L-1
at any address".  But yes, this should be clarified.  I'll mention it to
the WG (some have undoubtedly seen your message, too).  In my opinion,
machine B should be deemed broken and machine A is being reasonable, for
the reason you indicated.

In checking this, I noted an error in the last sentence of paragraph 2
of RFC 959 section 5.2.  The words "and the port used" should not
appear.  This is a mistaken holdover from NCP FTP, RFC 542, top of page
34, mechanically translated into TCP jargon.  The approximate
counterpart to a TCP port is a pair of NCP sockets, each of which is
unidirectional; so the socket used in NCP FTP depended on the direction
of transfer.  In TCP FTP the issue doesn't arise since TCP connections
are full-duplex.  The same correction is needed in MIL-STD-1780, last
sentence of section 5.9.2.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org