RFC 1571

RFC 1571: Telnet Environment Option Interoperability Issues 🎀

Okay bestie, the header first 📋. This one comes from the Network Working Group 🌸 and is Request for Comments: 1571. D. Borman wrote it at Cray Research, Inc. 💅 It's dated January 1994 📅 and the category is Informational, so it's giving "here's some info" rather than a standard 🧚. It updates RFC 1408 ✨ and doesn't list anything it obsoletes.

Status of This Memo ✨

Quick legal-ish bit 🫶: this memo is here to provide information for the Internet community. It does not specify an Internet standard of any kind, so don't treat it like one 💀. Distribution is unlimited, so share it with everyone 🦋.

1. Overview 🌈

So RFC 1408 [1] is the spec for the Telnet Environment Option, and it defines VAR and VALUE the opposite way from the BSD implementation 🙃. The BSD one was the reference implementation the RFC was supposed to document, and it's the base for lots of existing implementations 👑. So now we've got a real interop problem: implementations with conflicting definitions for VAR and VALUE just don't vibe together 😭.

This doc is here to help implementors make their Environment option work with as many other implementations as possible 💖. It gives you a set of heuristics (basically clues 🕵️‍♀️) to figure out which definitions for VAR and VALUE the other side of the connection is using.

2. Client Telnet: Parsing a SEND 📥

Okay, so the SEND suboption should only contain VAR and USERVAR commands. It should never contain a VALUE 🙅‍♀️. If you're parsing a SEND suboption and you run into a VALUE, the client should assume the server has reversed the values for VAR and VALUE. From that point on, the client should reverse them too, both when parsing the rest of the SEND suboption and when generating an IS or INFO suboption ✨.

If you find both VALUE and VAR commands in there, the SEND command isn't well formed, and what happens next is implementation dependent 💀.

If there are no VAR or VALUE commands in the SEND suboption at all, the client has no way to know what the server expects for VAR and VALUE. So it should just assume the server has the correct definitions and use the correct values 🫶.

3. Server Telnet: Parsing an IS or INFO 🔍

This is the detective section, bestie 🕵️‍♀️. An IS or INFO in a suboption can only legally be followed by either a VAR or a USERVAR. If an IS or INFO is immediately followed by a VAR, then it can be assumed that the client has the correct definitions for VAR and VALUE. If it's immediately followed by a VALUE, then it can be assumed that the client has reversed definitions, and from that point on the server should assume that VALUE and VAR are reversed 🔄.

If the IS or INFO is immediately followed by a USERVAR, things get messier 😵‍💫, and further heuristics must be applied to figure out what the client's definitions for VAR and VALUE are. That's because it's legal for a USERVAR to be followed by either a VAR or a VALUE. A VALUE after a USERVAR gives the value for that USERVAR. A VAR after a USERVAR implies the USERVAR is undefined.

Next up, scan the entire suboption looking for two consecutive instances of VAR or VALUE, or a VAR or VALUE that's empty 👀. A suboption isn't allowed to contain two VALUEs without an intervening VAR or USERVAR, and it's also not allowed to contain an empty VAR. So if you find two consecutive VARs or an empty VALUE, the client that generated the suboption uses the correct definitions. If you find two consecutive VALUEs or an empty VAR, the client has reversed definitions, and from that point on the server should assume VAR and VALUE are reversed 🙃.

If you're still in doubt, count up how many VARs, USERVARs and VALUEs were received 🔢. (Consecutive USERVARs without an intervening VALUE or VAR only count as one.) A VALUE can only follow a VAR or a USERVAR, so there can never be more VALUEs than the sum of VARs and USERVARs. And if all the VARs and USERVARs have values, there will be exactly as many VALUEs as there are VARs and USERVARs. So if the number of VARs and USERVARs equals the total number of VALUEs, the client has correct definitions. If the number of VALUEs and USERVARs equals the total number of VARs, the client has reversed definitions 💖.

Now here's a twist 🌀. If the number of VALUEs is more than the sum of VARs and USERVARs, it can be assumed the client has reversed definitions. And if there are more VARs than USERVARs and VALUEs, it can be assumed the client has the correct definitions. BUT to even get to this step, we already know there are no consecutive VARs and VALUEs. Some quick math shows that the number of VALUEs will never exceed the sum of VARs and USERVARs, and the number of VARs will never exceed the sum of VALUEs and USERVARs. So this check is redundant and can be skipped 🙈.

Still unsure? Check the values of the VAR commands to see if they actually name well known variables 🔍. If any of them do, the client is probably using the correct definitions. Otherwise, if any of the VALUEs contain well known variable names, the client probably has reversed definitions 🔄.

And if every single one of the above heuristics fails 😩, the server has done all it can to figure out what kind of client it's talking to. At that point, it should just be assumed the client is using the correct definitions for VAR and VALUE 🫶.

4. Client Summary 📝

Here's the cheat sheet for the client side 💅:

    The SEND suboption contains only VAR and USERVAR commands.
        The server is ok.
    The SEND suboption contains VALUE commands.
        The server is reversed.
    No VAR or VALUE commands are found.
        Assume the server is ok.

5. Server Summary 📝

And here's the server-side cheat sheet, fully sorted 🧚:

    IS/INFO is followed by VAR.
        The client is ok.
    IS/INFO is followed by VALUE.
        The client is reversed.
    There are two consecutive VARs.
        The client is ok.
    There are consecutive VALUEs.
        The client is reversed.
    There is an empty VALUE.
        The client is ok.
    There is an empty VAR.
        The client is reversed.
    The number of USERVARs and VARs is equal to the number of VALUEs.
        Assume the client is ok.
    The number of USERVARs and VALUEs is equal to the number of VARs.
        Assume the client is reversed.
    There are VARs with names that are well known.
        Assume the client is ok.
    There are VALUEs with names that are well known.
        Assume the client is reversed.
    Anything else.
        Assume the client is ok.

References 📚

[1] Borman, D., Editor, "Telnet Environment Option", RFC 1408, Cray
    Research, Inc., January 1993.

Security Considerations 🚨

Security issues are not discussed in this memo. 💀 Plot twist: that's the whole security section, so go in with your eyes open 👀.

Author's Address 💌

David A. Borman
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55123

Phone: (612) 452-6650
EMail: dab@CRAY.COM

Telnet Working Group Mailing List: telnet-ietf@CRAY.COM