Leaving well enough alone (RFC0686)
Original Publication Date: 1975-May-01
Included in the Prior Art Database: 2019-Feb-14
Internet Society Requests For Comment (RFCs)
Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.
Network Working Group Brian Harvey Request for Comments: 686 SU-AI NIC 32481 10 May 1975 References: 354, 385, 630, 542, 640.
Leaving Well Enough Alone
I recently decided it was time for an overhaul of our FTP user and server programs. This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong -- and a few things that everyone seemed to be doing differently from each other. When I enquired about this, the response from some quarters was "Oh, you’re running version 1!"
Since, as far as I can tell, all but one network host are running version 1, and basically transferring files OK, it seems to me that the existence on paper of an unused protocol should not stand in the way of maintaining the current one unless there is a good reason to believe that the new one is either imminent or strongly superior or both. (I understand, by the way, that FTP-2 represents a lot of thought and effort by several people who are greater network experts than I, and that it isn’t nice of me to propose junking all that work, and I hereby apologize for it.) Let me list what strike me as the main differences in FTP-2 and examine their potential impact on the world.
1. FTP-2 uses TELNET-2. The main advantage of the new Telnet protocol is that it allows flexible negotiation about things like echoing. But the communicators in the case of FTP are computer programs, not people, and don’t want any echoing anyway. The argument that new hosts might not know about old Telnet seems an unlikely one for quite some time to come if TELNET-2 ever does really take over the world, FTP-1 could be implemented in it.
2. FTP-2 straightens out the "print file" mess. This is more of a mess on paper than in practice, I think. Although the protocol document is confusing on the subject, I think it is perfectly obvious what to do: if the user specifies, and the server accepts, TYPE P (ASCII print file) or TYPE F (EBCDIC print file), then the data sent over the network should contain Fortran control characters. That is, the source file should contain Fortran controls, and should be sent over the net as is, and reformatted if necessary not by the SERVER as the protocol says but by the RECIPIENT (server for STOR, user for RETR). As a non-Fortran-user I may be missing something here but I don’t think so; it is just like the well-understood TYPE E in which the data is sent in EBCDIC and the recipient can format it for local use as desired.
Harvey [Page 1]
RFC 686 Leaving Well Enough Alone May 1975
One never reformats a file from ASCII to EBCDIC at the sending end. Perhaps the confusion happened because the protocol authors had in mind using these types to send files directly to a line printer at the server end, and indeed maybe that’s all it’s good for and nobody’s user program will implement TYPE P RETR. In any event, using a two-dimensional scheme to specify the combinations of ASCII/EBCDIC and ASA/normal conveys no more information...