Browse Prior Art Database

Telnet Environment Option Interoperability Issues (RFC1571)

IP.com Disclosure Number: IPCOM000002405D
Original Publication Date: 1994-Jan-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 4 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Borman: AUTHOR

Related Documents

10.17487/RFC1571: DOI

Abstract

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Network Working Group D. Borman Request for Comments: 1571 Cray Research, Inc. Updates: 1408 January 1994 Category: Informational

Telnet Environment Option Interoperability Issues

Status of this Memo

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

1. Overview

RFC 1408 [1], the specification for the Telnet Environment Option, specifies definitions for VAR and VALUE that are reversed from the BSD implementation of the Telnet Environment option. Since the BSD implementation was the reference implementation that the RFC was supposed to document, and is the base for many existing implementations, there exists an interoperability problem between implementations with conflicting definitions for VAR and VALUE.

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection.

2. Client Telnet: Parsing a SEND

The SEND suboption should only contain VAR and USERVAR commands. It should never contain a VALUE. If while parsing a SEND suboption, a VALUE is encountered, the client should assume that the server has reversed values for VAR and VALUE, and from that point on the client should reverse those values, both in parsing the rest of the SEND suboption, and when generating an IS or INFO suboption. If both VALUE and VAR commands are encountered, the SEND command is not well formed, and it is implementation dependent as to what will happen.

If there are not VAR or VALUE commands in the SEND suboption, then the client cannot know what values the server is expecting for VAR and VALUE. In this case, it should just assume that the server has the correct definitions, and use the correct values for VAR and VALUE.

Telnet Working Group [Page 1]

RFC 1571 Environment Option Interoperability January 1994

3. Server Telnet: Parsing an IS or INFO

The IS or INFO in a suboption can only be legally 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 the IS or INFO is immediately followed by a VALUE, then it can be assumed that the client has reversed definitions for VAR and VALUE, and from that point on the server should assume that the VALUE and VAR definitions are reversed.

If the IS or INFO is immediately followed by a USERVAR, further hueristics must be applied to determine what are the client definitions for VAR and VALUE. This is because it is legal for a USERVAR to be followed by either a VAR or a VALUE. A VALUE after a USERVAR gives the value for the USERVER. A VAR after a USERVAR implies that the USERVAR is undefined.

The next thing to do is to scan the en...

Processing...
Loading...