Telnet logout option
A TELNET option that lets one side request a forced logout of the remote user process.
Crispin, M.R., "Telnet logout option", RFC 727, DOI 10.17487/RFC0727, April 1977, <https://www.rfc-editor.org/info/rfc727>.
@misc{rfc727,
series = {Request for Comments},
number = 727,
howpublished = {RFC 727},
publisher = {RFC Editor},
doi = {10.17487/RFC0727},
url = {https://www.rfc-editor.org/info/rfc727},
author = {M.R. Crispin},
title = {{Telnet logout option}},
pagetotal = 3,
year = 1977,
month = apr,
} RFC text
NWG/RFC# 727 MRC 26-APR-77 18:24 40025
Telnet Logout Option
Network Working Group Mark Crispin
Request for Comments 727 MIT-AI
NIC 40025 27 April 1977
TELNET Logout Option
1. Command name and code.
LOGOUT 18
2. Command meanings.
IAC WILL LOGOUT
The sender of this command REQUESTS permission to, or confirms
that it will, forcibly log off the user process at its end.
IAC WON'T LOGOUT
The sender of this command REFUSES to forcibly log off the user
process at its end.
IAC DO LOGOUT
The sender of this command REQUESTS that the receiver forcibly log
off the user process at the receiver's end, or confirms that the
receiver has its permission to do so.
IAC DON'T LOGOUT
The sender of this command DEMANDS that the receiver not forcibly
log off the user process at the receiver's end.
3. Default.
WON'T LOGOUT
DON'T LOGOUT
i.e., no forcible logging off of the server's user process.
4. Motivation for the option.
Often, a runaway user process could be hung in such a state that it
cannot be interrupted by normal means. Conversely, the system itself
could be bottlenecked so that response delays are intolerable. A
user (human or otherwise) eventually will time out out of frustration
NWG/RFC# 727 MRC 26-APR-77 18:24 40025
Telnet Logout Option
and take the drastic means of closing the connection to free itself
from the hung process. In some situations, even the simple operation
of logging out can take a long time.
Some systems treat a close to mean that it should log out its user
process under it. However, many hosts merely "detach" the process so
that an accidental close due to a user or temporary hardware error
will not cause all work done on that job to be lost; when the
connection is re-established, the user may "attach" back to its
process. While this protection is often valuable, if the user is
giving up completely on the host, it can cause this hung job to
continue to load the system.
This option allows a process to instruct the server that the user
process at the server's end should be forcibly logged out instead of
detached. A secondary usage of this option might be for a server to
warn of impending auto-logout of its user process due to inactivity.
5. Description of the option.
When a user decides that it no longer wants its process on the server
host and decides that it does not want to wait until the host's
normal log out protocol has been gone through, it sends IAC DO
LOGOUT. The receiver of the command may respond with IAC WILL
LOGOUT, in which case it will then forcibly log off the user process
at its end. If it responds with IAC WON'T LOGOUT, then it indicates
that it has not logged off the user process at its end, and if the
connection is broken, the process very possibly will be detached.
A truly impatient user that feels that it must break away from the
server immediately could even send IAC DO LOGOUT and then close. At
the worst, the server would only ignore the request and detach the
user process. A server that implements the LOGOUT option should know
to log out the user process despite the sudden close and even an
inability to confirm the LOGOUT request!
6. A sample implementation of the option.
The server implements the LOGOUT option both for accepting LOGOUT
requests and for auto-logout warning.
Case 1:
The user connects to the server, and starts interacting with the
server. For some reason, the user wishes to terminate interaction
with the server, and is reluctant to go through the normal log out
procedure, or perhaps the user is unable to go through the normal
NWG/RFC# 727 MRC 26-APR-77 18:24 40025
Telnet Logout Option
log out procedure. It does not want the process at the server any
more, so it sends IAC DO LOGOUT. The server verifies the request
with IAC WILL LOGOUT, and then forcibly logs off the user process
(perhaps by using a system call that causes another process to be
logged out). It does not have to close the connection unless the
user closes or it wants to close. Neither does it wait until the
user has received its confirmation--it starts the log out
immediately so if the user has in the mean time closed the
connection without waiting for confirmation, its logout request
still is performed.
Case 2:
The user connects to the server, and after logging in, is idle for
a while, long enough to approach the server's autologout time.
The server shortly before the autologout sends IAC WILL LOGOUT;
the user sees this and sends IAC DON'T LOGOUT, and continues work
on the host. Nothing prevents the server from logging out the
user process if inactivity continues; this can be used to prevent
a malicious user from locking up a process on the server host by
the simple expedient of sending IAC DON'T LOGOUT every time it
sees IAC WILL LOGOUT but doing nothing else.
ISO Plain Language
On this page
§1Why Ask for a Forced Logout
A user process may hang so it cannot be interrupted, or the host may respond so slowly that the user wants to leave. Closing the connection does not always end the process: many hosts detach it so the user can reconnect without losing work after an accidental close.
If the user is giving up on the host, a detached hung process may continue to consume resources. The LOGOUT option provides a way to request that the server forcibly log out the process instead of detaching it.
Closing a connection can leave the user's process running on the host. The option lets the user ask the host to end that process instead.
§2LOGOUT Commands and Default
The option is named LOGOUT and has code 18. IAC DO LOGOUT asks the receiver to forcibly log out the user process at its end, while IAC WILL LOGOUT requests or confirms permission for the sender to do so at its end.
IAC DON'T LOGOUT demands that the receiver not forcibly log out its process, and IAC WON'T LOGOUT refuses to do so. The default is WON'T LOGOUT and DON'T LOGOUT, meaning no forcible logout.
DO asks the other side to log out its process; WILL agrees to a logout request. DON'T and WON'T refuse or prevent forced logout.
§3Logging Out Without Waiting
A user who does not want to wait for the normal logout procedure sends IAC DO LOGOUT. The server may reply IAC WILL LOGOUT and begin logging out the process immediately. It need not wait for the user to receive confirmation or close the connection itself.
The RFC says an impatient user may send the request and then close the connection; a server that implements the option should still process the request. If the server refuses with WON'T LOGOUT, a later connection break may leave the process detached.
The server can start the logout as soon as it agrees, even if the user closes the connection before seeing the reply. If it refuses, the process may be detached instead.
§4Warning About Automatic Logout
A server may use IAC WILL LOGOUT to warn that it is approaching its automatic logout time for an inactive user. The user can respond with IAC DON'T LOGOUT and continue working.
The RFC also says this warning does not prevent the server from logging out the process if inactivity continues. This prevents a user from keeping a process indefinitely by repeatedly refusing a warning without resuming work.
A server can warn an inactive user that logout is near. The user can continue working, but simply refusing the warning does not prevent logout if inactivity continues.