Summary

  • RFC 1312 defined an Experimental short-message service over TCP and UDP, with recipient, terminal, sender, cookie and signature fields whose meaning did not always identify one actual screen or person.
  • Its TCP + acknowledgement meant that a message was successfully delivered to some user or terminal, but the RFC explicitly limited that conclusion: it might indicate only that the server invoked a local delivery service.
  • The specification did not require the acknowledgement to wait for a display or for a user to read or dismiss a message; a positive reply therefore was not a human-attention receipt.

Analysis

The message had several possible destinations before it had a person

RFC 1312 appeared in April 1992 as an Experimental protocol for a short message directed to a user and terminal on a host. Its message form began with a revision octet and continued with null-terminated fields: recipient, recipient terminal, message, sender, sender terminal, cookie and signature. The smallness of the packet did not make its target simple.

An empty recipient could allow delivery to any user on the destination system. An empty terminal meant that the system would choose the “right” terminal, a system-dependent function. An asterisk in the terminal field implied all terminals. With both recipient and terminal empty, the message should go to a console: not a named device, but a place likely to be seen by an operator or administrator. These are useful delivery instructions. They are not evidence that one identified person, one visible screen or one attentive human has been reached.

The distinction matters because the protocol's vocabulary is close to ordinary language. “Recipient,” “terminal” and “delivered” can make a service-stage record sound like a social fact. RFC 1312 keeps enough alternatives in view to prevent that move. A host may choose the terminal; a message may be aimed at any user; a console is defined functionally rather than personally. The fields express a request and a routing preference inside the receiving system. They do not settle who was present, what interface appeared, or whether the content entered anyone's awareness.

A plus sign had a specific job

The TCP service listened on port 18. Once a connection was established and the client sent a message, the server returned one character: positive + or negative , followed by an optional explanation. The positive form meant that the message was successfully delivered to some user or terminal; the negative form meant that it was not delivered to any terminal. That is already a bounded and useful operational distinction.

The RFC then refuses to turn it into an end-to-end ceremony. A positive acknowledgement may indicate only that the Message Send server successfully invoked a local message-delivery service. The authors say it may not be possible to infer true end-to-end semantics. They make the unresolved alternatives concrete: the acknowledgement might correspond to handoff to the local service, to a window system displaying the message, or to a user confirming that it was read by dismissing a pop-up. The protocol does not prescribe which.

This is not a defect hidden in a footnote. It is the contract's boundary. A client receiving + has evidence that the server reached the stage it reports. It does not have evidence that the chosen local mechanism made a window visible, that a window stayed visible, that the intended person was at the terminal, that anyone comprehended the content, or that a response or later action followed. Each statement would need evidence from a later component and perhaps from a human process that the wire protocol deliberately does not govern.

UDP's silence and cookie solve different problems

The UDP service made the boundary even more visible. A server could send an answering datagram. It should send a positive acknowledgement for a message addressed to a particular user that was successfully delivered to that user. For an any-user message, or for a delivery failure, it sent no reply. The RFC explains the asymmetry as a compromise for broadcast behavior: requiring every server to reply would make broad sends produce inappropriate reply traffic.

Silence therefore cannot be casually named failure, and a reply cannot be inflated into universal completion. The two cases have their own conditions and trade-offs. The same is true of the cookie. Combined with the sender's UDP port, the cookie should be unique enough for a server to identify duplicate messages. A client may send a message several times to improve reception chances, and a server may discard repeats. This is a duplicate-handling aid within a stated scope. It is not a proof that the first instance reached a display, nor a proof that deduplication named the correct person, nor a receipt of attention.

Identity was not supplied by a sender-shaped field

The protocol also includes a SIGNATURE field, but it does not let that field become a ready-made identity result. An empty signature cannot verify the sender's identity. A nonempty one is only a case-insensitive text encoding of some security token; RFC 1312 does not define its encoding or interpretation. Its security section also calls for filtering displayed text and warns about the risk of writing to a user's terminal without permission.

Those details reinforce the same evidence discipline. A sender string, source address, token-shaped field and local delivery attempt belong to different layers. Even a service that invokes a local display mechanism should not silently claim that the displayed text was safe, that the supposed sender was verified or that the user agreed to receive it. The RFC provides a narrow message service, not a proof system for people.

The useful conclusion is smaller than a read receipt

RFC 1312 is an Experimental 1992 specification, not a claim about contemporary notifications, chat systems or deployment. Its historical value is the exact restraint it records. A positive reply can be a legitimate receipt for local handling. It stops there unless another component produces evidence of display, interaction or human response.

That order protects operators as well as recipients. It prevents an alerting system from calling a local invocation a confirmed read, prevents an audit trail from creating consent out of a terminal name, and makes the point of missing evidence visible rather than filling it with a green status icon.

Sources

RFC 1312 specifies an Experimental 1992 message service. It does not prove an actual recipient, display, reading, consent, identity, deployment or outcome.