RFC 728

Minor pitfall in the Telnet Protocol

πŸ“… published April 1977, from ietf

RFC 728: A Minor Pitfall in the Telnet Protocol πŸŽ€

okay bestie, this is RFC 728 πŸ¦‹ written by John Day in Apr 1977 as NIC #40036. it's giving early-ARPANET energy πŸ’… the doc doesn't say what category or status it has, and it doesn't say it obsoletes or updates anything, so i'm not gonna guess πŸ™ˆ

Telnet option designers, listen up πŸ‘‘ there's a possible case in the Telnet protocol that can cause unexpected behavior on either end of the connection. rn none of the existing options are affected, but it could totally happen in the future ✨

The Problem πŸ’€

so the Telnet sync sequence deletes all data from the data stream until a Data Mark shows up 🧹 but control functions are not affected by sync (see page 9 of the protocol specification) πŸ“„

now picture a Telnet option subnegotiation that has an effect on the data right after it in the stream 🫠 for example, a subnegotiation might tell the terminal to display the following data in a particular font, or give it other special treatment 🌸 if a sync sequence gets sent after that subnegotiation and its data, but before the subnegotiation has been processed, the subnegotiation could end up affecting data that wasn't meant for it 😭

Two Possible Solutions 🫢

Solution one came to mind right away. put the affected data in as a parameter of the subnegotiation, so the data goes into the data stream before the IAC SE that ends the subnegotiation. the downsides are both theoretical and practical πŸ€“

  • theoretically, sending data as subnegotiation parameters is improper and not really in the spirit of the Telnet protocol design πŸ™…β€β™€οΈ
  • practically, in this exact situation, flushing everything except the data the subnegotiation affects would be just as unexpected, and maybe confusing if a human was on the other end πŸ’€

Solution two is for designers of options that have these subnegotiations to define a subnegotiation or other mechanism that follows immediately after the Data Mark and nullifies the effects of any offending subnegotiation 🧚 the exact semantics would probably be super specific to the option itself πŸ’œ

not an emergency today, since none of the existing options are susceptible, but if you're designing a new option, keep this pitfall in mind πŸ‘€πŸŽ€
πŸ“¦ where this page comes from