Summary

  • RFC 1703, published in October 1994, specified how an Internet mail client could submit a message to a radio paging server. Its central distinction was what positive replies to both RCPT and DATA certified under MAIL, SEND, SOML, or SAML.
  • The stronger real-time assurance combined direct client-to-server SMTP with SEND or SAML. Under that arrangement, a positive server reply assured that the page had been sent on the radio paging network. The receipt ends at transmission on the radio paging network.

One green light, several clocks

The neatest way to misunderstand a pager is to treat it as a small inbox. An inbox can wait. Paging was sold on interruption: make a receiver beep while the reason for the interruption still matters. Once the Internet took the front desk, the ordinary mail response became an operational promise. A client wanted to know which clock the server had just stopped. Had it placed an item in a tray, persuaded the paging network to take it, or sent a transmission into the air?

Marshall Rose’s RFC 1703 put that question inside SMTP itself. A radio paging server had to support MAIL; support for SEND, SOML, and SAML was optional. The meaningful receipt came from positive completion replies to both RCPT and DATA. Those two replies under MAIL meant, at minimum, that a message was queued for transmission into the paging network. A queue is useful. It is also a place where the clock can keep running after the sender has been thanked.

With SEND, the same positive pair signified that the radio paging network had accepted the page for delivery to the recipient. The RFC was more guarded about SOML and SAML: such replies may indicate acceptance by the network. This is unusually careful specification language for an everyday word like “OK.” The command changed the meaning of the receipt, and one of the alternatives came with an explicit “may.” Anyone reporting a universal guarantee from the success code alone had read the light while ignoring the switch beside it.

The addressing apparatus was clever, too, but it played a supporting role. A telephone number could be turned into DNS labels under tpc.int; MX records pointed mail toward a server prepared to attempt the paging job. A wildcard MX could cover a number range. As the RFC explained, that wildcard indicated a server's willingness to try, not the existence of a particular reachable pager. Its predecessor in the TPC.INT work, RFC 1530, supplied the broader idea of extending telephone-network access through Internet mail. RFC 1703's sharpest work happened after a client found the server: it had to decide what a successful handoff would buy.

There was another hitch in the phrase “send a message.” A numeric pager received a message body made of digits; an alphanumeric pager had a different service address. The email-shaped envelope did not make every device equally expressive. The server translated between mail conventions and a radio service with its own addressing and payload limits. A successful SMTP exchange therefore described a boundary crossed, with the boundary named as precisely as the available command allowed.

Then came the mail route. Ordinary electronic mail might pass through relays and gateways; Rose warned that these extra store-and-forward stops could add minutes, hours, or days. A time-sensitive page needed a shorter path. RFC 1703 proposed direct IP/SMTP connectivity from the paging client to the server: one SMTP hop, with no intermediate mail relay waiting for its turn. This removed the relay delay from the submission path. It also made the server's reply arrive at the end of a live conversation instead of through a chain of other people's queues.

Section 3.4 paired that direct path with SEND or SAML. Those commands explicitly requested real-time transmission and a reply about its success or failure. When client and server talked directly and used one of those commands, the RFC said a positive reply assured the page had been sent on the radio paging network. The specification chose its finish line with care. A radio-network send was the reported event. Device reception and human attention lay beyond that reply's evidence.

That is the small historical beauty of RFC 1703. It did not try to make SMTP sound more confident. It made the confidence conditional on the command and the route. A green light for a queued message and a green light after a radio-network send could look identical on a terminal. The specification made them tell different stories, so an operator could choose the promise needed for the job.