Re: [idn] FTP history

[Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>]

-- lundi, mai 27, 2002 16:54:26 -0400 vint cerf <vinton.g.cerf@wcom.com> 
wrote/a écrit:

> Dave,
>
> isn't there a distinction to be made between the client and the server
> here? The results of the user interaction were exchanges over a TCP
> connection distinct from the control connection - that was so even before
> TCP/IP (with NCP).  The fact that we used TELNET to drive the FTP control
> doesn't make the design any less a protocol. TELNET was a convenient way
> of implementing the text-based exchanges - but they had formats that
> included error numbers as well as text in the expectation that some
> implementations of the the client would be machine driven, I thought.
>
> The server side plainly had to deal with protocol exchanges between the
> ftp data transfer servers on source and sink machines, in addition to the
> control server exchanges carried over the TELNET protocol.
>
> I'm not sure whether this thread/debate is necessarily useful, is it??

While I found this thread very informative of design considerations at that 
time, I agree with Vint about the not clear usefulness of this thread for 
this wg. The internet history mailing list might be more appropriate for 
this thread.

Marc.


>
> vint
>
> At 09:58 AM 5/27/2002 -0700, Dave Crocker wrote:
>> At 12:43 PM 5/27/2002 -0400, John C Klensin wrote:
>>>  While FTP apparently lends itself to "direct UI", it
>>> was never intended that way.
>>
>> John,
>>
>> I have a pretty clear recollection that when FTP first came out the
>> folks who wrote the spec honestly expected to be able to sit at a TIP,
>> telnet over to an FTP server, and type commands that would effect file
>> transfers.
>>
>> I even have a vague recollection that this was used to send data to a
>> printer attached to the TIP on another port.
>>
>>
>>> For example, use of "TYPE ASCII" transfers requires translation
>>> between the character set of the sender and network ASCII and
>>> translation by the receiver from network ASCII to local
>>> character set and formats.
>>
>> Not if the receiver can process network ASCII directly, as some did.
>>
>>
>>>  Even when those hosts use ASCII, the
>>> translations must accomodate, e.g., conversion of end of line
>>> conventions.
>>
>> Not if they supported CRLF directly, as some did.  In fact, that was why
>> CRLF was chosen and end of line, rather than a single character.  A
>> single character would have made lexical analysis notably simpler.
>>
>>
>>> But the protocol is no more designed as a "direct UI" than SMTP
>>
>> SMTP came around 10 years later.
>>
>> However, the original MAIL command in FTP was explicitly intended to
>> permit direct typing over a telnet connection.  And it was in fact used
>> that way.  (That was why there was a distinction between MAIL and MLFL
>> which did the data transfer over a separate FTP data connection.)
>>
>> d/
>>
>> ----------
>> Dave Crocker <mailto:dave@tribalwise.com>
>> TribalWise, Inc. <http://www.tribalwise.com>
>> tel +1.408.246.8253; fax +1.408.850.1850
>>
>



------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------