Telnet and FTP implementation schedule change
A revised schedule for switching to a new version of the remote-login protocol.
McKenzie, A.M. and J. Postel, "Telnet and FTP implementation schedule change", RFC 593, DOI 10.17487/RFC0593, November 1973, <https://www.rfc-editor.org/info/rfc593>.
@misc{rfc593,
series = {Request for Comments},
number = 593,
howpublished = {RFC 593},
publisher = {RFC Editor},
doi = {10.17487/RFC0593},
url = {https://www.rfc-editor.org/info/rfc593},
author = {A.M. McKenzie and J. Postel},
title = {{Telnet and FTP implementation schedule change}},
pagetotal = 1,
year = 1973,
month = nov,
} RFC text
Contents
Network Working Group Alex McKenzie
Request for Comments: 593 BBN
Jon Postel
MITRE
Telnet and FTP Implementation Schedule Change
Telnet and FTP Implementation Schedule Change
We have been contacted by several Telnet implementers and concerned
users regarding the scheduled changeover from old to new Telnet.
There is a good deal of concern about accomplishing a coordinated
changeover especially in light of the potential incompatibilities
(RFC 559, NIC18482). Therefore the changeover is reformulated as
follows.
New Telnet implementations are to be ready 1 Jan 74 (as before), but
are to use ICP socket 23 (decimal). That is the server Telnet will
listen on socket 23, and user Telnet programs will connect to socket
23. It will also be useful for the user program to let the user
optionally select the server socket, as many user Telnet programs
currently do. It will also be useful for implementers to consider a
server Telnet program capable of dealing with both protocols as MIT-
DMCG has done (RFC 559). This will provide an opportunity for
testing and debugging the new programs in a way that does not
interfere with normal use.
During January we will survey the technical liaisons to determine the
status of the Telnet implementations. As soon as we determine that
the Telnet implementations have reached a point where the changeover
can be made without disruption of user services the technical
liaisons will be notified.
In light of this change in the Telnet implementation schedule, the
FTP schedule is also modified. New FTP implementations are to be
ready by 1 Feb 74 (as before), but will continue to use ICP socket 21
(decimal) until we can determine that a changeover is appropriate.
References
Telnet Protocol NIC 18639
File Transfer Protocol NIC 17759
[This RFC was put into machine readable form for entry ]
[into the online RFC archives by Mirsad Todorovac 5/98 ]
AI ELI5
On this page
§1The Telnet Transition Problem
By late 1973, the ARPANET was preparing a major upgrade to the Telnet protocol, the tool for remote login across the network. A coordinated switchover date had been set, but implementers and users worried about incompatibilities that could break services if the transition was too abrupt.
RFC 593 announces a revised schedule that allows the new and old Telnet systems to coexist during a transition period.
A new remote-login system was ready, but forcing everyone to switch the same day could break things. Instead, both versions could run side by side.
§2The New Arrangement
New Telnet implementations were still due by 1 January 1974, but instead of replacing the old system immediately, they would use ICP socket 23 (the decimal port number). This allowed the old Telnet to keep running on its original socket while new implementations listened on socket 23.
User Telnet programs could optionally select which socket to connect to, and some implementations (like MIT-DMCG) were dual-stack—able to handle both old and new protocols—enabling testing without disruption.
The new Telnet would listen at address 23, the old one at its old address. Systems could try the new one when they were ready.
§3FTP and Follow-up
The RFC also adjusts the File Transfer Protocol schedule: new FTP implementations were due by 1 February 1974 but would continue using ICP socket 21 until a separate switchover decision could be made.
During January 1974, the network liaisons would survey the status of implementations and determine when a full switchover could happen without disrupting service.
File transfer got the same deal: the new version could be ready, but the old address stayed in use until everyone was confident.