RFC 727

RFC 727: TELNET Logout Option 💖

Okay bestie, the paperwork first 🎀 This is RFC 727 (also filed as NIC 40025), written by Mark Crispin of MIT-AI on 27 April 1977, from the Network Working Group. It doesn't list anything it obsoletes or updates, so there's no old drama to catch up on ✨

---

1. Command name and code 🍓

Here's the command and its number:

LOGOUT               18

---

2. Command meanings 🦋

2.1. The four vibes

Okay so TELNET has four messages for this option, and each one has its own energy 💅

IAC WILL LOGOUT

IAC WILL LOGOUT

The sender is asking for permission to, or confirming it will, forcibly log off the user process on its end. It's basically saying "I'm about to do this, or I'm allowed to" 🌸

IAC WON'T LOGOUT

IAC WON'T LOGOUT

The sender is refusing to forcibly log off the user process on its end. Not it 🙅‍♀️

IAC DO LOGOUT

IAC DO LOGOUT

The sender is asking the receiver to forcibly log off the user process on the receiver's end, or confirming that the receiver already has permission to do it 🫶

IAC DON'T LOGOUT

IAC DON'T LOGOUT

The sender is demanding that the receiver not forcibly log off the user process on the receiver's end. This one is a hard no, bestie 😤

---

3. Default 🌈

By default, both sides are in the "nope, don't log anyone out" mode:

WON'T LOGOUT
DON'T LOGOUT

Which just means no forcible logging off of the server's user process. Chill 🧚

---

4. Motivation for the option 💜

Okay, real talk, this is the why 🥺 Sometimes a runaway user process gets stuck in such a state that normal stuff can't interrupt it. Or the whole system is so bogged down that responses take forever and it's unbearable. Eventually a user (human or otherwise) gets so frustrated that they just close the connection to escape the hung process. Sometimes even a normal logout takes ages 😭

Some systems treat a close like a logout, so the user process underneath gets logged out too. But lots of hosts just "detach" the process instead 🛟 That way an accidental close, whether from a user mistake or a flaky hardware glitch, doesn't wipe out all the work on that job. When the connection comes back, the user can "attach" back to the process. This protection is genuinely valuable! The catch is that if the user is totally done with the host, that detached job can keep hogging the system 💀

So this option lets a process tell the server that the user process on the server's end should be forcibly logged out instead of detached ✨ There's also a secondary use: a server can give a heads-up that it's about to auto-logout the user process because of inactivity ⭐

---

5. Description of the option 🎀

So here's the flow. When a user decides it doesn't want its process on the server anymore, and doesn't want to wait for the host's normal logout process to finish, it sends IAC DO LOGOUT 🏃‍♀️

The receiver can reply IAC WILL LOGOUT, which means it will then forcibly log off the user process on its end. If it replies IAC WON'T LOGOUT instead, it hasn't logged off the user process on its end. And if the connection breaks, that process will very likely get detached 🫠

Impatient users are real. Someone who needs out right now could send IAC DO LOGOUT and then just close the connection. The worst case is that the server ignores the request and detaches the user process. But a server that implements the LOGOUT option should still know to log out the user process despite the sudden close, and even when it can't confirm the LOGOUT request! 🔥

---

6. A sample implementation of the option 🧚‍♀️

The server implements LOGOUT for two things: accepting LOGOUT requests, and sending auto-logout warnings 👑

Case 1

The user connects and starts interacting with the server. At some point they want to end things, but they don't want to deal with the normal logout procedure, or maybe they can't. They don't want the process on the server anymore, so they send IAC DO LOGOUT 🙈

The server confirms with IAC WILL LOGOUT, then forcibly logs off the user process. It might do this with a system call that causes another process to be logged out. The server doesn't have to close the connection unless the user closes it or the server wants to. It also doesn't wait for the user to receive the confirmation. It starts the logout immediately, so if the user already closed the connection without waiting, the logout request still gets carried out ✨

Case 2

The user connects, logs in, and then sits idle for a while, long enough to get close to the server's autologout time. Shortly before the autologout, the server sends IAC WILL LOGOUT. The user sees it, sends IAC DON'T LOGOUT, and keeps working on the host 🙃

Nothing stops the server from logging out the user process if the inactivity keeps going. This matters because otherwise a malicious user could lock up a process on the server host just by sending IAC DON'T LOGOUT every time they see IAC WILL LOGOUT and doing nothing else. That's a whole lot of main-character energy for a "do nothing" move, and the server is not having it 💅