Summary

  • RFC 1921 divided a Bull VIP terminal session into screen, printer and screen-copy flows, each with its own address and at most one outstanding request.
  • A second request on the same address was deleted, but its PROTOCOL-VIOLATION response had to follow the response to the first request; order substituted for a transaction identifier.
  • Telnet negotiation and EOR established a common grammar. ACK, BUSY, PURGED or READY still described only a bounded flow state, not user authority, host outcome or a printed page.

The error could not speak first

Picture two printer envelopes entering the same slot. The first is being processed. The second arrives too soon. A system concerned only with throughput might buffer it. One concerned only with punishment might reject it immediately. TNVIP chose a more exact sequence: discard the second envelope, finish the first exchange, and only then report that the second violated the protocol.

That sequence in RFC 1921, published as an Informational document in March 1996, was not etiquette. It protected the meaning of the next response. A TNVIP request carried no general transaction number. The sender knew which operation a response answered because each device address could have only one current request. If the error for request two jumped ahead of the result for request one, the receiver would preserve honesty about rejection while destroying the association that made either answer useful.

The protocol therefore made a curious promise: bad input would be reported, but not at the cost of corrupting the evidence already in flight.

One Telnet connection contained three ledgers

TNVIP was a Telnet profile for Bull Visual Information Projection terminals. Those terminals differed from the ordinary Network Virtual Terminal model. They worked in blocks and could combine a screen with an associated printer. A Terminal Manager could present physical devices to host applications through logical stations and logical devices; one printer could even be shared across logical stations.

RFC 1921 did not flatten that arrangement into one stream of interchangeable messages. Its two-byte TNVIP header began with an address. 0x60 named the screen flow, 0x68 the printer flow and 0x69 the screen-copy printing flow. The next byte named a command and, in its two low bits, whether the message was an indication, request, response, or response-and-request.

The one-outstanding rule was scoped to a given address. A pending screen request occupied the screen ledger; a printer request belonged to the printer ledger. A correct trace therefore needed more than connection order. It needed the address, the current request on that address and the message type. The same byte stream carried several local conversations without pretending they were one global queue.

That is the opposite of a protocol such as LDAP, which later let several operations interleave and used Message IDs to reunite replies with operations. TNVIP spent less identifier space and accepted a stricter scheduling rule. Its common state was small because concurrency remained bounded.

Negotiation created grammar, not entitlement

Before TNVIP messages could mean anything, the peers had to negotiate a terminal type and Telnet's End-of-Record option. The terminal string named a supported model and could append @Mailbox-name. In a DSA gateway, that optional Mailbox selected a particular access point; without it, the server could use generic access. The field was limited and case-normalized. It was a routing instruction inside the server's terminal world, not authentication.

Binary Transmission was optional when the emulation needed eight-bit values. Suppress-Go-Ahead was optional when the client did not need Telnet GA to synchronize transmission with a DSA turn or ISO session token. These choices changed how bytes and turns travelled. They did not prove which person sat at the terminal or whether that person was allowed to use the Mailbox. RFC 1921's Security Considerations said security was not addressed and anticipated later authentication for precisely that question.

EOR supplied another narrow fact. VIP communication was block-oriented, so an IAC EOR closed every TNVIP message. The receiver could locate a complete record. It still needed the TNVIP response vocabulary to say what happened to that record. Framing was not processing.

The RFC exposed this boundary again when it discouraged Telnet commands inside a TNVIP message. Apart from escaped IAC IAC, an embedded command had to be processed, but an implementation could handle it immediately or defer it until after the current message. Identical octet order could therefore produce a different control/data ordering. Keeping commands between records removed an ambiguity that EOR alone could not solve.

Four message types replaced a universal receipt

An indication expected no response. A request opened one response slot on its address. A response closed that slot and let the peer send another request. The fourth type, response-and-request, performed both transitions at once: it positively answered the current request and created a new request in the opposite direction.

This grammar matters because familiar words did not have universal meanings. ACK on the screen could say that screen data had been processed or that a LOCAL-state request had been accepted. BUSY on the screen said data had been deleted because the terminal was local. BUSY on the printer said a new printer request had been deleted while the preceding printing operation remained unfinished. READY answered a printer-state query; it was not an acknowledgement of printer data.

Other replies kept other failures separate: ERROR for unsuccessful processing, ABORTED for operator or reset interruption, PURGED for a request stopped by a purge indication, NOT-AVAILABLE for an unsupported device, UNKNOWN-COMMAND for an unknown operation and PROTOCOL-VIOLATION for illegal sequencing. An unknown indication could simply be deleted and ignored, while an unknown request demanded a bounded answer.

A log that retains only ACK or BUSY destroys the protocol's own distinctions. The address and pending request are part of the fact.

Deletion was not a queue

The second-request rule is easy to soften in retelling. It is tempting to say the request was “held” while the device was busy. RFC 1921 said it was deleted. On the printer flow, a sender was supposed to wait because the client transferred data to its printer buffer and could not accept another printer-data request while the previous printing remained unfinished. A premature request did not acquire a place in a hidden queue.

That changes the operational interpretation. A later BUSY or PROTOCOL-VIOLATION was evidence that data would need a new sender decision. It was not a promise of automatic retry. Conversely, a missing immediate error after the second request did not mean acceptance. The receiver was obliged to preserve the first request's response order before speaking about the discarded second one.

TNVIP thus separated three moments that monitoring often compresses: octets reached the connection; a message was admitted to the current device flow; the device-specific work was processed. Delivery to the Telnet endpoint did not imply admission to a request slot.

LOCAL state made successful delivery end in deliberate loss

A VIP client could leave ONLINE mode for local tests or configuration. Before switching, it sent a LOCAL-STATE request. The server acknowledged and was supposed to suspend screen and printer data until the client sent an ONLINE-STATE indication.

If server-originated screen or printer data nevertheless arrived while the terminal was local, the client deleted it. For a request, it could return BUSY. The connection was alive. The block could be correctly framed. The address and command could be recognized. The specified result was still deletion.

The state did not freeze the whole connection. Client-originated screen messages and messages on other addresses remained allowed. This is why “the terminal was busy” is too coarse. The restriction had a direction, device scope and state transition. One flow could refuse incoming display work while another form of communication remained legitimate.

A screen copy required permission and a later result

The screen-copy address illustrates why response-and-request existed. Because the printer could also be under server control, a user could not simply begin a local screen copy without coordination. The client sent COPY-REQ. If the server allowed a local copy, it returned LOCAL-COPY.

That message closed the permission request and opened a result request. Authorization to begin was not completion. The client still had to answer with ACK, ERROR, BUSY, ABORTED, PURGED or NOT-AVAILABLE according to the later outcome.

The separation is unusually clean. The server could grant use of the shared device. The client could attempt the physical action. A later status could describe the attempt. None of those records alone proved what appeared on paper or who received it. The existing history of RFC 1318 makes the lower boundary equally clear: a physical printer signal is not a document result. TNVIP added an application exchange, not a witness standing beside the page.

Purge authority expired at acknowledgement

Screen, printer and screen-copy flows each defined a purge indication. Timing controlled its power. If the request had not yet been acknowledged, the receiver tried to abort processing and returned PURGED. If it had already replied, the purge message was ignored and deleted.

The rule prevented a late cancellation from rewriting settled protocol history. It also refused to promise physical reversal. PURGED described the request-processing path that could still be aborted. If a device effect had already escaped that path, the RFC supplied no universal undo.

This is where Running-Code Primacy is useful as a later analytical discipline, not as evidence of the authors' intent. A published command grammar is not the device effect. A response is real within its implemented state machine; it does not acquire authority over layers the implementation cannot reverse.

The sources prove a design, not a deployment

RFC 1921 supplies the TNVIP facts. RFC 854 supplies Telnet's base command/negotiation model; RFC 885, RFC 856, RFC 858 and RFC 1091 supply EOR, binary, go-ahead and terminal-type context. RFC 1576 documents a different terminal profile and marks the boundary with the earlier TN3270 Article.

Those documents establish specified behavior. They do not count installations, verify a Bull product, authenticate a user, show a screen, print a page or prove a host application succeeded. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption sharpens the modern reading: keep the common state deterministic, then leave device policy and operational proof with the participants that can observe them.

RFC 1921's most durable achievement was not a grand terminal architecture. It was a disciplined refusal to let one response answer two requests. Three small ledgers, explicit loss and ordered error made the evidence narrower—and therefore usable.