Summary

  • RFC 1096 defined Telnet option 35 so one peer could request and receive an X display location. WILL and DO merely granted permission for later discussion; the locator travelled only in a controlled SEND/IS subnegotiation.
  • The value followed the Unix DISPLAY form <host>:<dispnum>[.<screennum>]. A Telnet client had to turn a local shorthand such as :0 into something meaningful to the remote host, but that rewrite did not authenticate the host or prove the display was reachable.
  • X remained a separate protocol path. The remote application still had to connect to the X server and pass X-side access and authorization checks. A locator received over Telnet therefore proved neither permission nor window creation nor a user-visible result.

A remote command lacked one piece of local context

The problem begins with two machines and one person. The person runs a Telnet client under the X Window System, connects to a remote host and types a command that starts an X application. The process now exists on the remote host, while the display remains attached to the local workstation. The remote process needs a destination such as workstation.example:0.0, but the shell it inherited through Telnet may not know it.

RFC 1096 supplied that missing coordinate. Published in March 1989 as the Proposed Standard Telnet X Display Location Option, it assigned option code 35 and described how the Telnet server could ask the client for its X display location. The current IANA Telnet Options registry still records 35 as X Display Location.

The option is historically interesting because it does not attempt to carry X graphics inside Telnet. It carries enough information for a later connection to be attempted. The Telnet session transports a locator across a boundary of context; it does not erase the boundary between the protocols.

That restraint is easy to lose in modern language. “The remote application uses the local display” sounds like one continuous session. On the wire, there are at least two: the existing Telnet connection that delivers commands and the X client connection that the remote application may later open. RFC 1096 addresses the handoff between them.

WILL and DO opened a conversation, not a display

The default state is refusal: WON'T and DON'T. Nothing about a Telnet login automatically announces an X display. The peers must first negotiate option 35 using the command vocabulary defined by RFC 854.

WILL X-DISPLAY-LOCATION says that a peer is willing to send the location in a later subnegotiation. DO says that the other peer is willing to receive it. WON'T and DON'T decline those roles. RFC 1096 then makes the boundary unusually explicit: WILL and DO are used only to obtain and grant permission for future discussion.

That formulation follows the general architecture in RFC 855. Telnet option subnegotiation has two stages. First the parties agree that an option may be discussed; then the parameter itself travels between SB and SE. Either side can later end the permission with WON'T or DON'T.

The distinction matters beyond Telnet terminology. A positive negotiation is evidence about protocol state. It shows that one peer offered a role and the other accepted that role. It does not show that the display exists, belongs to the user, accepts a connection or authorizes the application. Permission to ask about an address is not permission to use the resource named by that address.

SEND and IS imposed a one-way request discipline

After negotiation, the display value still does not appear spontaneously. RFC 1096 assigns the initiative and response precisely. Only the peer that sent DO may issue the SEND subcommand. Only the peer that sent WILL may reply with IS. The willing supplier may not volunteer a location without that request.

This command rhythm was not invented for X. RFC 1096 says it closely follows RFC 1079, the Telnet Terminal Speed Option. That earlier option also distinguishes agreement to discuss a value from a requested SEND/IS exchange. Reusing the pattern reduced invention and made the state machine familiar to implementers.

The analogy has a limit. Terminal speed is a status string; an X display locator points toward another service with its own controls. Similar envelope mechanics do not give the enclosed values the same authority. The pattern answers who may ask and who may reply, not whether the value is trustworthy or sufficient for use.

RFC 1096's example makes the exchange tangible. A server sends SEND; the client responds with the NVT ASCII string SRI-NIC.ARPA:0.0. The example subcommand occupies 22 octets. When IS arrives, the server has evidence that its Telnet peer supplied that exact formatted claim. It has not yet observed an X connection.

Turning :0 into a remote locator

The value uses the Unix DISPLAY convention: <host>:<dispnum>[.<screennum>], with no spaces or other extra characters. The grammar joins three different selections. The host identifies a machine or network destination, the display number identifies an X server instance, and the optional screen number selects a screen within that display.

Local shorthand creates the option's most revealing implementation duty. On the user's workstation, :0 or unix:0.0 may be perfectly adequate. It tells a local program to use a local transport and display zero. Sent unchanged to the remote host, however, “local” would refer to the wrong machine. RFC 1096 therefore requires the Telnet client to modify such a value appropriately before transmission.

The client is translating scope. It takes a locator meaningful only inside one host and constructs a locator intended to be meaningful from another. That act can be operationally useful and still remain epistemically modest. The document does not say the rewrite authenticates the hostname, confirms DNS, tests a route, opens a port or proves that the user owns the display.

A correctly shaped string can be false, stale or unreachable. Even an accurate locator can name a server whose policy refuses the remote application. Syntax is the first validation layer, not the last.

The X connection began after the Telnet option ended

RFC 1013, the 1987 X Window System Protocol Version 11 document, describes the next path. An X client establishes its own IPC connection to the X server. For TCP, display number N is associated with port 6000+N. The locator supplied through Telnet can therefore help a remotely started process choose a host, display and endpoint.

But the Telnet TCP stream does not turn into that X connection. Option 35 carries neither X requests nor window contents. It is not a tunnel, proxy or forwarding channel. The remote application becomes an X client and attempts another connection whose route, transport and failure modes are distinct.

This separation clarifies troubleshooting. Receipt of IS means the locator reached the Telnet server. A subsequent TCP failure belongs to addressing, routing, filtering, listening state or another network condition. An X setup rejection belongs later still. Folding all of those into “the Telnet option failed” destroys the evidence needed to locate the boundary.

It also clarifies exposure. Rewriting :0 to a network-visible host can change the surface on which an X server is addressed. RFC 1096 describes the format transfer, not the policy for deciding whether such remote use is appropriate. The local operator and X server retain that decision.

X asked its own authorization question

The X protocol's connection setup includes the byte order, protocol version, an authorization-protocol name and authorization data. A server can reject setup and return a reason, or accept it and return information about the vendor, formats, screens and resource identifiers. The core document deliberately leaves the choice of valid authorization mechanism outside the core protocol.

RFC 1013 also describes a host access-control list. The list begins with the local host and configured hosts, can be changed by authorized clients and may cause the server to refuse a connection. Host admission and setup authorization are therefore X-side controls, not permissions silently inherited from Telnet negotiation.

The current IANA registry sharpens the classification without rewriting history. X Display Location is option 35. Telnet Authentication is separately registered as option 37. That present registry separation helps prevent option 35 from being mistaken for an authentication mechanism; it does not establish that any 1989 deployment used the later option or any particular security combination.

An operator should preserve the order of evidence. DO/WILL shows permission to conduct the option exchange. SEND/IS shows that a peer supplied a locator. A reachable TCP endpoint shows a network path and listener response. Accepted X setup shows that the X server admitted the connection under the controls it applied. These are cumulative observations, not interchangeable verdicts.

Even accepted X setup stopped short of the result

Suppose every earlier step succeeds. The remote process receives a plausible locator, reaches port 6000 plus the display number and passes X setup. It has crossed more gates, but the user's intended result is not yet proven.

The application must create resources and issue requests. The X server must process them. A window may need to be mapped, remain available and contain the intended output. The user must be looking at the relevant screen and be able to interact with it. Accepted setup is strong evidence about the connection; it is not an observation of the final human outcome.

This is not pedantry. Automation often promotes the earliest available success into the conclusion it wants. A command returned zero, so a service must be healthy. A locator was returned, so a resource must be usable. A connection was accepted, so the user must have seen the window. RFC 1096 is a compact case study in why those promotions require new evidence.

The document's modesty is part of its design quality. It solves one coordination problem without claiming to solve address truth, routing, authentication, authorization, application correctness or perception. The narrow contract makes each later failure attributable.

The registry preserves a mechanism, not an outcome

Option 35 remains in the IANA table, but a registry entry is not a deployment census. It tells us the assigned code and its defining reference. It does not show how widely the option was implemented, how long a particular system used it or whether a named user ever obtained a window through it.

The source packet supports a precise historical account: Telnet had an option for requested delivery of an X display locator; the option inherited a familiar SEND/IS pattern; a local-only value had to be rewritten; X then used a separate connection and separate controls. It does not support stories about an incident, a specific host's policy or a universal security posture.

RFC 1096's durable lesson is therefore smaller and more useful than a claim of integration. Systems can pass context across a protocol boundary without transferring authority across it. The locator crossed Telnet. Access still belonged to X.

Sources