RFC 1569

RFC 1569: Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures 📟

Okay bestie, this one's a Network Working Group doc 🫶. It was written by Marshall Rose of Dover Beach Consulting, Inc. and dated January 1994 🌸. It's Informational, which means it's sharing info with the Internet community. It is not a standard. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨.

---

Status of This Memo 📜

This memo gives info to the Internet community 💖. It does not specify an Internet standard of any kind, so don't treat it like one 🙈. Distribution of this memo is unlimited 🦋.

Table of Contents 🗂️

1. Introduction ................................................    1
2. Naming, Addressing, and Routing .............................    2
2.1 Addressing .................................................    2
2.2 Routing ....................................................    3
3. Procedure ...................................................    3
3.1 MAILing versus SENDing .....................................    4
3.2 Latency ....................................................    4
4. Usage Examples ..............................................    5
4.1 MIME-based .................................................    5
4.2 Non-MIME ...................................................    5
5. Security Considerations .....................................    6
6. Acknowledgements ............................................    6
7. References ..................................................    6
8. Author's Address ............................................    6

1. Introduction ✨

So regular email is two-way, right? 💌 But sometimes you just want a one-way text notification service, and that's called radio paging 📟. This memo describes a technique for radio paging using the Internet mail infrastructure. It mainly focuses on the case where radio pagers are identified through the international telephone network 🌍.

The technique here maps telephone numbers to domain names, and that idea comes from the TPC.INT subdomain 🗺️. For the overview, check out RFC 1530, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy" 📚.

2. Naming, Addressing, and Routing 🎀

A radio pager is identified by a telephone number, like this:

+1 415 940 8776

The +1 means the IDDD country code, and the rest is a telephone number inside that country 🌈.

2.1. Addressing 💅

The number gets used to build the address of a radio pager server, which becomes the recipient address for the message. For example, one of these:

pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int

The domain-part is made by reversing the telephone number, turning each digit into a domain-label, and putting that under tpc.int. (The telephone number must not include any international access codes 🙅‍♀️.)

Also, these are reserved for future use 🔮 (the ATOM part is optional, and it's an RFC 822 atom [1]):

pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-alpha.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-numeric.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int

Note that the mailbox syntax is purposefully restricted for pragmatism 🧠. To paraphrase RFC 822, an atom is defined as:

atom    = 1*atomchar

atomchar=   <any upper or lowercase alphabetic character
             (A-Z a-z)>
          / <any digit (0-9)>
          / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
          / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
          / "|" / "}" / "~"

Last tip, and it's important 🚨: some Internet mail software (especially gateways from outside the Internet) puts strict limits on how big a mailbox-string can be. So originating user agents should take care to limit the local-part to no more than 70 or so characters 🫡.

2.2. Routing 🛣️

The message gets routed exactly the same way as all other electronic mail, using the MX algorithm [2] 💫. A radio pager server might be able to reach lots of radio pagers, so the wildcarding facilities of the DNS [3,4] are used for that 🧩.

For example, say a radio pager server at dbc.mtview.ca.us is willing to access any radio pager with a telephone number prefix of:

+1 415 940

Then this resource record might be present:

*.0.4.9.5.1.4.1.tpc.int.    IN MX 10 dbc.mtview.ca.us.

If several radio pager servers were willing to access any radio pager in that prefix, then there would be multiple MX resource records 👯‍♀️.

It should be noted that a wildcard RR matching a radio pager server's address does not mean the telephone number is valid. And even if it is valid, it doesn't mean a radio pager is identified by that number 🙃. The wildcard RR just means the radio pager server is willing to attempt access 🤷‍♀️.

3. Procedure 🧚

When info needs to go to a radio pager, the user application builds an RFC 822 message. That message has a Message-ID field and some textual content (like a text/plain content [5]) 📝.

Then the message gets sent to the radio pager server's electronic mail address 📬.

The radio pager server starts by looking at the local part of the address. If the local-part is the literal string pager-alpha, then the recipient is using an alpha-numeric pager 🔤. The server checks a local database to figure out how to send the page, based on the domain-part. That local knowledge includes the protocol used to talk to the paging network and the access number 🔑. Because of that, a radio pager server will register itself in the DNS as providing service only for the phone numbers it actually knows how to handle 🌸.

Otherwise, if the local-part is the literal string pager-numeric, then the recipient is using a numeric pager 🔢. The radio pager server may consult a local database to work out how to send the page based on the domain-part. Or it may dial the number in the domain-part directly 📞.

For alpha-numeric pagers, the radio pager server decides which info from the headers and body of the message goes into the paging message 🎯. For example, some servers might look at the To and Subject fields as well as the body. Others might just send the body verbatim 💅.

For numeric pagers, the radio pager server sends only the body, which must consistent solely of digits 🔢✨.

3.1. MAILing versus SENDing 📮

An SMTP client talking to a radio pager server may use attempt either the MAIL or SEND command 💬. The radio pager server MUST support the MAIL command, and it MAY support any of the SEND, SOML, or SAML commands 🫶.

If the MAIL command is used, then a positive completion reply to both the RCPT and DATA commands means, at a minimum, that the message has been queued for transmission into the radio paging network for the recipient. It's queued for transmission into the radio paging network, and that's the whole promise 📥.

If the SEND command is used, then a positive completion reply to both the RCPT and DATA commands means the message has been accepted by the radio paging network for delivery to the recipient 🚀.

If the SOML or SAML command is used, then a positive completion reply to both the RCPT and DATA commands means the message may have been accepted by the radio paging network for delivery to the recipient 🤞.

3.2. Latency ⏱️

Internet email is usually timely and reliable 📨. But some paging services want an even higher level of assurance for their clients 👑. In particular, they want a positive reply code to actually mean the page was sent on the radio network 📻. For that kind of requirement, the main constraints are the server implementation and the client/server network connectivity 🔧.

A client that uses the SEND or SAML commands is explicitly asking for real-time transmission on the radio network. It's also requiring that the server's reply code carries a statement of success or failure about that transmission 🎯.

Here's the tea 🫖. The IP level of the Internet does datagram store-and-forward service, but it gives end system hosts the feel of direct connectivity by allowing interactive service 💻. Internet email adds another layer of store-and-forward indirection, so messages can go through any number of relays and/or gateways 🏃‍♀️. That can add arbitrarily large delays, like minutes, hours, or even days 🕰️. Rough.

A client that sets up its Internet attachment to allow "direct" SMTP connectivity to a pager server can submit paging requests straight to the server, with no extra SMTP relaying 🎯. So transmission from paging client to paging server is one "SMTP-hop"only 🦋. That removes any chance of non-deterministic delay coming from the Internet itself 🙌.

If you configure both the paging server and the paging client to allow direct IP/SMTP-level interaction, and they only use the SEND or SAML commands, then a client that gets a positive reply from the server can be assured the page was sent on the radio network 💖.

4. Usage Examples 💌

4.1. MIME-based 🎀

To: pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int
cc: Marshall Rose <mrose@dbc.mtview.ca.us>
From: Carl Malamud <carl@malamud.com>
Date: Thu, 22 Jul 1993 08:38:00 -0800
Subject: First example, for an alphanumeric pager
Message-ID: <19930908220700.1@malamud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

A brief textual message.

4.2. Non-MIME 🍓

To: pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int
cc: Marshall Rose <mrose@dbc.mtview.ca.us>
From: Carl Malamud <carl@malamud.com>
Date: Thu, 22 Jul 1993 08:38:00 -0800
Subject: Second example, for a numeric pager
Message-ID: <19930908220700.2@malamud.com>

2026282044

5. Security Considerations 🚨

Internet mail may be subject to monitoring by third parties, and in particular, message relays. Yes, it's giving spy movie, so keep that in mind before you send anything sensitive 🕵️‍♀️🔒.

6. Acknowledgements 🫶

This document was motivated by "Simple Network Paging Protocol - Version 1", by Allen Gwinn of Southern Methodist University 🌟.

David H. Crocker and Carl Malamud also provided substantive comments 💜.

7. References 📚

• [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.
• [2] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, BBN, January 1986.
• [3] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, Information Sciences Institute, November 1987.
• [4] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, Information Sciences Institute, November 1987.
• [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

8. Author's Address 💁‍♀️

Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA  94043-2186
US

Phone: +1 415 968 1052
Fax:   +1 415 968 2510
EMail: mrose@dbc.mtview.ca.us

---