Summary

  • RFC 938 specified PORT NAK for an in-window IRTP data packet whose destination port was unknown: the receiver discarded the data, returned its current rcv_nxt, and thereby NAKed the port rather than the packet sequence.
  • The response can evidence a bounded transport observation and a failed local port lookup. It cannot show that an application received, parsed, authorized, stored or completed the payload.

Some protocol names make a promise that their details do not quite keep. Internet Reliable Transaction Protocol, published as RFC 938 in February 1985, sounds as though it should settle the whole fate of a transaction. The document's most revealing move does the opposite. It separates a host-to-host judgement about packet sequence from a local judgement about where, if anywhere, the payload should go.

The document was experimental/proposed, as the RFC 938 information record makes clear. That status is important: the specification tells us what its authors designed, not how widely it ran, how often it worked, or whether a particular installed system adopted it. The historical value is in the proposed boundary.

IRTP sat above IP. RFC 791 defines IP's Protocol field as the identifier for the next-level protocol; the current IANA protocol-numbers registry records 28 as IRTP and points to RFC 938. The registry preserves a coordination fact. It is not traffic measurement, code census or proof that IRTP remains in use.

A small header carried two different addresses of meaning

An IRTP packet had an eight-octet header. It held a packet type, a port number, a sequence number, a length and a checksum. RFC 938 defined five types: SYNCH, SYNCH ACK, DATA, DATA ACK, and PORT NAK.

That header placed two questions beside each other without merging them. The sequence number belonged to the host-to-host reliable-delivery machinery. The port identified the higher-level protocol or process for which the data was intended. A process could claim several port numbers, but no more than one process could claim a particular number. Packet exchange at a claimed local port was intended to match the same port at the remote host.

IRTP's connection was also unusual enough to deserve care. Its state relationship was between hosts, identified by remote Internet address, rather than a separate connection for every host-and-port pair. The module's connection table carried variables including snd_nxt, rcv_nxt and snd_una. SYNCH and SYNCH ACK repaired or established that host-pair state. A port was therefore not the name of the reliable connection; it was a local demultiplexing question encountered by data within that connection.

This distinction is easy to flatten in a modern log line. “Delivered to port 4000” may be read as an application result, while “acknowledged packet 47” may be read as the same claim in lower-level language. RFC 938 did not allow that shortcut. It gave each statement a separate field, state condition and response code.

The packet qualified before the port was consulted

The receive procedure makes the order explicit. For an incoming DATA packet, the IRTP module first considered whether the sequence number lay in its acknowledgement window. A packet outside the relevant window did not earn the same result. For a packet in it, the receiver recomputed rcv_nxt and then considered whether the stated port was known.

If the port was known, the receiver queued data for the user process only after acknowledging it with DATA ACK. If the port was not known, it sent PORT NAK instead and discarded the data. The sequence field in either acknowledgement-style reply carried the current rcv_nxt.

RFC 938 removes any possible ambiguity in its definition of the latter reply: PORT NAK “acknowledges reception of all packet numbers up through the packet number in the sequence field.” It NAKs the port number, “not the packet number.” The language is unusually exact because two independent facts have been compressed into one wire event.

A receiver could consequently tell its peer: the host-level sequence has advanced through this boundary; do not infer from that fact that the local endpoint existed. The packet's payload was discarded. The reply was neither a retry request for its sequence number nor an admission ticket to an application.

Receipt is not dispatch; dispatch is not outcome

The sequence acknowledgement establishes a limited protocol fact. Given RFC 938's state machine, a trace can support that an IRTP receiver treated the received DATA packet as lying in the relevant acknowledgement range and reported cumulative receipt up to a stated rcv_nxt. The port NAK adds a second limited fact: at that point the receiver did not know a process that had claimed the named port.

Neither fact does the work commonly assigned to “delivery” in casual prose. They do not establish that an application parsed bytes, that a service chose to accept a request, that an identity was authenticated, that an authorization check passed, that a record was stored, or that a human task was completed. They do not establish a permanent absence either: port claims can be local and temporal, while the protocol response records one observation in one state.

The boundary becomes still clearer if the packet's sequence and port are treated as different evidence objects. A sequence event speaks about the relationship between the two hosts. A port-claim event speaks about a receiving module's local mapping to a process. An application event, should one occur, belongs to yet another actor and may have its own validation, transaction and durability rules.

That layered restraint echoes the distinction in Heng Lu's Note 64 between a minimal common rule and a later local choice. A wire protocol can make one deterministic, locally verifiable statement about its own state. It cannot, merely by recording that statement, exercise authority for a process that did not claim the port or for an organisation that will decide what a payload means.

Reliability did not mean one universal policy

RFC 938 offered a compact mechanism for host-pair synchronization, checksums, acknowledgement and retransmission pressure. It did not prescribe a complete operating policy. It required an implementation to have a way to trigger retransmission and to retransmit snd_una, but left specific timer and retransmission strategies open. The local implementation, not the common header, determined those choices.

The two-minute quiet-time reference illustrates the same discipline. RFC 938 asked an IRTP module to observe a quiet time when a remote address became known and referred readers to the discussion in RFC 793. That reference is a bounded design comparison. It does not make IRTP TCP, grant their packets identical semantics, or demonstrate that their implementations shared a deployment history.

The result is a useful historical corrective to grand protocol labels. “Reliable” here did not mean that every intended application endpoint was present. “Transaction” did not mean that every payload became a completed business or user action. The RFC defined reliable sequence handling and a port-dispatch result in a limited arrangement; it conspicuously preserved the gap between them.

The right audit trail is a chain, not an ACK bit

An operator investigating a PORT NAK needs more than the word NAK. Preserve the remote address, the port, the received sequence number, the rcv_nxt returned, the applicable receive window, the connection-state epoch, checksum outcome, packet type, and the port-claim state at the time. Record the implementation's timer and retransmission policy separately, because RFC 938 intentionally did not supply one universal policy.

Those records enable questions that a single “delivery failed” counter cannot answer. Was the packet rejected because the port was unclaimed, or did it fail checksum or window tests before dispatch was even possible? Was the remote host in resynchronization? Did the peer retransmit snd_una because it interpreted the response as required by the protocol? Was a process brought up later and a fresh packet then routed differently? The signals point to different control surfaces and should not be collapsed into a single application-failure story.

The strongest conclusion is also the narrowest. RFC 938 designed a response that preserved reliability evidence while refusing to counterfeit local delivery. A packet could count in the sequence state and still be thrown away at the port boundary. That is not an incomplete acknowledgement. It is the protocol's argument that receipt, dispatch and outcome belong to different authorities.

Sources and limits

This account relies on RFC 938 for IRTP's specified packet structure and receive procedure; the RFC 938 information record for experimental/proposed status; RFC 791 for the IP next-protocol field; RFC 793 only for the quiet-time comparison; and IANA's protocol-number registry for the current number-28 coordination record. These sources do not quantify implementation, adoption, traffic, performance or present-day operation.

They also do not allow a PORT NAK to be promoted into a security or business conclusion. The response supplies neither peer authentication nor confidentiality, neither application authorization nor durable completion. Its historical lesson is more modest and more durable: an acknowledgement can truthfully describe one boundary while a refusal truthfully describes the next.