RFC 652

RFC 652: Telnet Output Carriage-Return Disposition Option 💖

Okay bestie, the title block first 🎀 This is RFC 652, written by D. Crocker (UCLA-NMC) and dated 25 Oct. 74. It also has NIC #31155 and lives in the online file [ISI]<DCROCKER>NAOCRD.TXT. The original doesn't state a category or status, and it doesn't say it obsoletes or updates anything, so I'm not adding any of that 🙈

1. Command name and code ✨

The command is NAOCRD, code 10. It stands for Negotiate About Output Carriage-Return Disposition 🦋

NAOCRD     10   (Negotiate About Output Carriage-Return Disposition)

2. Command meanings 🔥

Okay so we're talking about a simplex connection here, same as in the NAOL and NAOP Telnet options. Each command below is the message, then what it means ✨

IAC DO NAOCRD

The data sender requests or agrees to negotiate about who handles output carriage-return characters with the data receiver. Once they agree and there are no more subnegotiations, the data receiver is assumed to be handling output carriage-returns 💅

IAC DON'T NAOCRD

The data sender refuses to negotiate about output carriage-return disposition with the data receiver, or demands a return to the unnegotiated default mode. Not me, not negotiating 🙅‍♀️

IAC WILL NAOCRD

The data receiver requests or agrees to negotiate about output carriage-return disposition with the sender. Once they agree and there are no more subnegotiations, the data receiver alone is assumed to be handling output carriage-returns 🌸

IAC WON'T NAOCRD

The data receiver refuses to negotiate about output carriage-return disposition, or demands a return to the unnegotiated default mode. Same energy as the sender, bestie 💀

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

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

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

The data receiver uses the 8-bit value to specify which party should handle carriage-returns and what their disposition should be. The code for DR is 0 🧚

3. Default 🌈

So when nobody has negotiated who's handling output carriage-returns, which is the default, DON'T NAOCRD and WON'T NAOCRD apply. In that case neither party is required to handle carriage-returns, and neither party is prohibited from handling them. But it is appropriate if at least the data receiver handles carriage-returns, even if it does so primitively 🫶

4. Motivation for the Option 💜

For the reasons behind this option, please refer to section 4 of the NAOL and of the NAOP Telnet option descriptions 📚

5. Description of the Option 👑

The data sender and the data receiver use the 8-bit value along with the NAOCRD SB commands, and the value means the following 🎀

8-bit value          Meaning

0                    Command sender  suggests  that  he  alone  will
                     handle carriage-returns, for the connection.
1 to 250             Command sender suggests that  the  other  party
                     alone   should   handle  carriage-returns,  but
                     suggests that a delay of 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.    (See   qualification,
                     below.)
251                  Not allowed, in order  to  be  compatible  with
                     related Telnet options.
252                  Command sender suggests that  the  other  party
                     alone  handle  carriage-returns,  but  suggests
                     that they be discarded.
253                  Not allowed, in order  to  be  compatible  with
                     related Telnet options.
254                  Command sender suggests that  the  other  party
                     alone   should   handle   carriage-returns  but
                     suggests  waiting  for  a   character   to   be
                     transmitted  (on  the other simplex connection)
                     before sending more data.  (See  qualification,
                     below.)   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   carriage-returns  and
                     suggests nothing about how it should be done.

Now the guiding rules, which are the important bit 🔥 They are:

1. if neither data receiver nor data sender wants to handle carriage-returns, the data receiver must do it, and
2. if both data receiver and data sender want to handle carriage-returns, the data sender gets to do it.

Why rule (1)? If neither one wants the job, then the default in the NAOCRD option takes over. Why rule (2)? The sender is presumed to have special knowledge about the data, so it should be allowed to do it, while taking into account any suggestions the receiver makes. Iconic logic, fr fr ✨

Now the delays 🕰️ Carriage-return delays are controlled by the data sender, and they must consist of NUL characters inserted immediately after the character in question. This is necessary because of the assynchrony of network transmissions. Because of the Telnet end-of-line convention (carriage-return followed by a linefeed), any NULs that would otherwise go after the carriage-return must go after the linefeed instead. That's true no matter what changes are made to the linefeed (see NAOLFD Telnet option) 💅

And the etiquette, bestie 🌸 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 an option has been refused, it should not be resuggested until "something changes" (for example, another process starts) 🙈

Finally, at any time, either party can turn off further negotiation by sending the appropriate WON'T NAOCRD or DON'T NAOCRD command 🫶💖