RFC 655

TELNET OUTPUT FORMFEED DISPOSITION OPTION 💖

RFC 655 🎀 · NIC 31158 🎀 · Oct. 25, 1974 🌸

Author: D. Crocker (UCLA-NMC) 💅

Online file: [ISI]<DCROCKER>NAOFFD.TXT 🦋

The title block doesn't list a category, and it doesn't say this RFC obsoletes or updates anything. Okay so, this is a Telnet option all about who handles formfeeds 📄✨

---

1. Command name and code ✨

Here's the name and number, bestie 🧚

NAOFFD - 13
   (Negotiate About Output Formfeed Disposition)

---

2. Command meanings 🌈

Okay, so we're talking about a simplex connection here, the kind described in the NAOL and NAOP Telnet Options specs 🔥

IAC DO NAOFFD

The data sender requests or agrees to negotiate about output formfeed disposition with the data receiver. Once they've agreed, and nobody sends any further subnegotiations, the data receiver is assumed to be handling output formfeeds. It's giving teamwork 🫶

IAC DON'T NAOFFD

The data sender refuses to negotiate about output formfeed disposition with the data receiver, or it demands a return to the unnegotiated default mode. Not me saying "no" 💀

IAC WILL NAOFFD

The data receiver requests or agrees to negotiate about output formfeed disposition with the sender. Once agreement is reached and there are no further subnegotiations, the data receiver alone is assumed to be handling output formfeeds. Main character energy 👑

IAC WON'T NAOFFD

The data receiver refuses to negotiate about output formfeed disposition, or it demands a return to the unnegotiated default mode. Iconic refusal 💅

IAC SB NAOFFD DS <8-bit value> IAC SE

The data sender uses the 8-bit value to say which party should handle formfeeds and what their disposition should be. The code for DS is 1 🍓

IAC SB NAOFFD DR <8-bit value> IAC SE

The data receiver uses the 8-bit value to say which party should handle formfeeds and what their disposition should be. The code for DR is 0 🌸

---

3. Default 🫧

DON'T NAOFFD/WON'T NAOFFD

If there's no negotiation about which party (the data sender or the data receiver) is handling output formfeeds, neither party is required to handle formfeeds, and neither party is prohibited from handling them. Lowkey chill 😌 But it's appropriate if at least the data receiver handles formfeed considerations, even if it's kinda primitive about it 🙈

---

4. Motivation for the Option 🧠

For the why, check out section 4 of the NAOL and NAOFFD Telnet option descriptions 📚✨

---

5. Description of the Option 💜

Okay, the sender and receiver use the 8-bit value together with the DS and DR SB commands like this 👀

8-bit value                      Meaning

0            Command sender suggests that he alone will handle
             formfeeds, for the connection.
1 to 250     Command sender suggests that the other party alone
             should handle formfeeds, but suggests that the
             indicated value be used.  The value is the number
             of character-times to wait or number of NULs to
             insert in the data stream before sending the next
             data character.
251          Command sender suggests that the other party alone
             handle formfeeds, but suggests that each
             occurrence of the character be replaced by
             carriage-return/line-feed.
252          Command sender suggests that the other party alone
             handle formfeeds, but suggests that they be
             discarded.
253          Command sender suggests that the other party alone
             should handle formfeeds, but suggests that
             formfeeds be simulated.
254          Command sender suggests that the other party alone
             should handle output formfeeds but suggests
             waiting for a character to be transmitted (on the
             other simplex connection) before sending more
             data. Note that, due to the assynchrony of the two
             simplex connections, phase problems can occur with
             this option.
255          Command sender suggests that the other party alone
             should handle output formfeeds and suggests
             nothing about how it should be done.

Now the guiding rules, which are the tea ☕🔥

1. If neither the data receiver nor the data sender wants to handle output formfeeds, the data receiver must do it, and
2. If both the data receiver and the data sender want to handle output formfeeds, the data sender gets to do it.

The reasoning for the first rule is that if neither wants to do it, the default in the NAOFFD option takes over. If both want to do it, the sender is presumed to have special knowledge about the data, so the sender should be allowed to do it, taking into account any suggestions the receiver makes. Honestly the sender knows the vibe best 🫶

Simulation means swapping the formfeed character for enough line-feeds (and only line-feeds) to move the paper (or line-pointer) to the top of the next page, or to the top of the terminal screen 📄➡️📄

Delays controlled by the data sender have to be NUL characters inserted right after the formfeed character. This is necessary because of the assynchrony of network transmission. Don't skip this part bestie, it's important 🚨

As with all option negotiations, neither party should suggest a state that's already in effect, except to refuse to negotiate. Changes should be acknowledged. And once something's refused, the option shouldn't be resuggested until "something changes" (e.g., another process starts). Patience is a vibe 🧘‍♀️

At any time, either party can disable further negotiation by sending the appropriate WON'T NAOFFD or DON'T NAOFFD command. Bye bye, drama 👋🦋