RFC 1703

Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures ✨

Okay bestie, this one is RFC 1703 🎀 It's from the Network Working Group and was written by M. Rose of Dover Beach Consulting, Inc. 💅 It's dated October 1994 and it's Informational, so it's sharing info, not setting a standard 📋 It obsoletes RFC 1569, which means this one replaces it 🦋 It doesn't list any updates.

Status of this Memo 📋

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. 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 Alpha-numeric Radio Pagers ................................    3
3.2 Numeric Radio Pagers ......................................    4
3.3 MAILing versus SENDing ....................................    4
3.4 Latency ...................................................    5
4. Usage Examples .............................................    5
4.1 A MIME Example ............................................    6
4.2 A Non-MIME Example ........................................    6
5. Server Configuration Example ...............................    6
6. Security Considerations ....................................    8
7. Acknowledgements ...........................................    8
8. References .................................................    8
9. Author's Address ...........................................    9

1. Introduction 🦋

So you already have regular two-way email, right? Sometimes you just need a one-way text ping, and that's called radio paging 📟 This memo explains how to do radio paging using the Internet mail infrastructure. It mostly focuses on radio pagers that are identified through the international telephone network 🌍

The technique here, which maps telephone numbers to domain names, comes from the TPC.INT subdomain. For the big-picture 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" is the IDDD country code, and the rest is a telephone number inside that country 💖

In addition to a telephone number, a PIN may also be required to uniquely identify a radio pager 🔐

2.1. Addressing 📬

That number gets used to build the address of a radio paging server, and that address becomes the recipient address for the message. For example, any of these work:

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@6.7.7.8.0.4.9.5.1.4.1.tpc.int

Here, ATOM is an RFC 822 atom [1]. It's basically an opaque string that identifies the recipient when you're talking to the paging network 🫶 The domain-part gets built 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.)

Note that the mailbox syntax is purposefully restricted in the interests of pragmatism 💅 To paraphrase STD 11, 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)>
          / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
          / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
          / "|" / "}" / "~"

Finally, some Internet mail software (especially gateways from outside the Internet) puts stringent limits on the size of a mailbox-string 😭 So originating user agents should take care in limiting the local-part to no more than 70 or so characters 🌈

2.2. Routing 🛣️

The message is routed in exactly the same way as all other electronic mail, using the MX algorithm [2] 💖 A radio paging server might be able to reach lots of radio pagers, so the wildcarding facilities of the DNS [3,4] get used for that. For example, say a radio paging 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.

Naturally, if several radio paging servers are willing to access any radio pager in that prefix, multiple MX resource records would be present 🧚 (The DNS servers for the TPC.INT subdomain do a rudimentary form of load balancing by rotating the order of the MX records returned on each query 🔄)

Heads up: it should be noted that a wildcard RR matching a radio paging server's address doesn't imply that the corresponding telephone number is valid. And even if it is valid, it doesn't mean a radio pager is identified by that phone number 🙈 Instead, the wildcard RR just means a radio paging server is willing to attempt access.

3. Procedure 📝

When info is going to a radio pager, the user application constructs an RFC 822 message. That message contains a "Message-ID" field and textual content (like a "text/plain" content [5]) 💌

The message then gets sent to the radio paging server's electronic mail address. The server starts by looking at the local part of the address 👀

3.1. Alpha-numeric Radio Pagers 🔢

If the local-part is either "pager.ATOM" or "pager-alpha.ATOM", then the recipient is using an alpha-numeric radio pager. ATOM either identifies a paging network (CARRIER), or a radio pager identity number (PIN), or both, following these rules:

1. if ATOM consists entirely of numeric characters, then ATOM is a PIN, and the domain-part refers to the IXO access telephone number for a radio paging carrier; otherwise,
2. if ATOM does not contain a hyphen character ("-"), then ATOM is a CARRIER. A local database is consulted to determine the corresponding IXO access telephone number, and the telephone number corresponding to the domain-part is used to identify the radio pager; otherwise,
3. if ATOM does contain a hyphen character ("-"), then everything to the left of the first hyphen is a CARRIER, and everything to the right of that hyphen is a PIN. A local database is consulted to determine the corresponding IXO access telephone number, and the PIN is used to identify the radio pager.

If the local-part starts with "pager.", then the message sent to the radio pager is just the body of the message 💅 Otherwise, if the local-part starts with "pager-alpha.", the radio paging server decides which info in the headers and body gets used when building the paging message ✨ For example, some servers might look at the "To" and "Subject" fields as well as the body, whilst others might just send the body verbatim 🍓

3.2. Numeric Radio Pagers 📞

If the local-part is the literal string "pager-numeric", then the recipient is using a numeric pager, and the radio pager dials the telephone number corresponding to the domain-part 📱

The message sent to the radio pager consists of the body of the message, which must consist solely of digits 🔢

3.3. MAILing versus SENDing 📨

An SMTP client talking to a radio paging server may use either the MAIL or SEND command. The radio paging server MUST support the MAIL command, and 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 indicates, at a minimum, that the message has been queued for transmission into the radio paging network for the recipient. So it's at least queued for transmission into the radio paging network 📥

If the SEND command is used, then a positive completion reply to both the RCPT and DATA commands indicates that 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 indicates that the message may have been accepted by the radio paging network for delivery to the recipient 🤞

3.4. Latency ⏱️

Okay so Internet email is usually timely and reliable, but some paging services want extra assurance for their clients 🥹 In particular, they want a guarantee that a positive reply code means the page has actually been sent on the radio paging network. For that kind of requirement, the main constraints are server implementation and client/server network connectivity 🔧

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

The IP level of the Internet does datagram store-and-forward service, but it gives end system hosts the appearance of direct connectivity by allowing interactive service 💫 The Internet electronic mail service adds another layer of store-and-forward indirection, so messages may go through any number of relays (and/or gateways). That can introduce arbitrarily large delays of minutes, hours, or days 😩

A client that configures its Internet attachment to permit "direct" SMTP connectivity to a radio paging server can submit paging requests straight to the server, without any additional SMTP relaying. In other words, transmission from radio paging client to server is one "SMTP-hop" only 🦋 This eliminates any possibility of non-deterministic delay by the Internet itself ✨

Put it all together: if you configure the radio paging server and client to allow direct IP/SMTP-level interaction, and make sure they use SEND or SAML commands only, then a client getting a positive reply from the server is assured that the page has been sent on the radio paging network 👑

4. Usage Examples 🎀

These examples use the "iddd.tpc.int" subdomain. The DNS servers for this subdomain, when they run into a domain of this form:

NUMBER.iddd.tpc.int

they automatically create a CNAME RR of this form:

R.E.B.M.U.N.iddd.tpc.int

e.g.,

14159408776.iddd.tpc.int

will be treated as

6.7.7.8.0.4.9.5.1.4.1.tpc.int

4.1. A MIME Example 💌

Here's a full example message 🥰

To: pager-alpha.98765@18005551234.iddd.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 sent to the radio paging network
having an IXO access telephone number of "+1-8005551234"
to the radio pager having a PIN of "98765".

4.2. A Non-MIME Example ✨

okay so no MIME wrapper this time, bestie. just a plain numeric pager message, no frills 💅

     To: pager-numeric@14159408776.iddd.tpc.int
     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. Server Configuration Example 🧚

this section is the full glow-up 🎀 it's about how a hypothetical radio paging carrier, e.g., Pigeon Paging, might wire up its pager services with Internet e-mail. it's giving "build your own network" energy and i'm obsessed 😭

1. The radio paging carrier establishes a top-level domain name, e.g.,

pigeon.net

2. The radio paging carrier installs and operates one or more radio paging servers, each having a unique entry in the DNS, e.g.,

ixo1.pigeon.net.              IN A  a.b.c.d

Each of these radio paging servers runs an SMTP server which implements the SEND command as described in Section 3.3 above.

3. The radio paging carrier coordinates with the administrators of the TPC.INT subdomain to have the appropriate MX records added to the DNS, assigning cost values in the MX records to reflect any difference in the quality of service between the radio paging servers, e.g.,

4.3.2.1.5.5.5.0.0.8.1.tpc.int. IN MX  5 ixo1.pigeon.net.
4.3.2.1.5.5.5.0.0.8.1.tpc.int. IN MX  5 ixo2.pigeon.net.

which would provide both load-balancing and redundancy (particularly if the servers were located at different points in the Internet). At this point, messages can be sent using the addressing formats described in Section 2.2 above.

4. The radio paging carrier may choose to make available a client program which uses the SMTP SEND command, in order to achieve "real-time" delivery of messages into the radio paging network. 🔥
5. Finally, the radio paging carrier may choose to assign each of its customers a mailbox, e.g.,

mrose@pager.pigeon.net

which maps to the TPC.INT address for the customer's radio pager.

The system(s) listed in the DNS for this domain would maintain the appropriate mail aliases for this mapping, e.g.,

R: 220 pager.pigeon.net SMTP ready
S: HELO malamud.com
R: 220 pager.pigeon.net
S: EXPN mrose
R: 250 <pager-alpha.98765@18005551234.iddd.tpc.int>

At the carrier's discretion, these systems may also be the systems running the radio paging servers. However, this needn't be the case. For example, consider a situation where a client program which uses the SMTP SEND command, wants to ensure that it is talking to radio paging server for an address: e.g.,

R: 220 pager.pigeon.net SMTP ready
S: EHLO malamud.com
R: 220-pager.pigeon.net
R: 220 SEND
S: VRFY mrose
R: 551 User not local;
        try <pager-alpha.98765@18005551234.iddd.tpc.int>

or

R: 220 pager.pigeon.net SMTP ready
S: EHLO malamud.com
R: 220-pager.pigeon.net
R: 220 SEND
S: VRFY mrose
R: 250 <pager-alpha.98765@18005551234.iddd.tpc.int>

6. Security Considerations 🚨

bestie, listen up 👀 Internet mail may be subject to monitoring by third parties, and in particular, message relays. this is not a drill 💀

7. Acknowledgements 🫶

this document was motivated by RFC 1568 [6] and RFC 1645 [7]. in addition, David Crocker, Carl Malamud, and Perry Metzger also provided substantive comments. so grateful for them 🌸

8. 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", BBN Laboratories, STD 14, RFC 974, BBN, January 1986.

[3] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.

[4] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[5] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

[6] Gwinn, A., "Simple Network Paging Protocol - Version 1(b)", RFC 1568, Southern Methodist University, January 1994.

[7] Gwinn, A., "Simple Network Paging Protocol - Version 2", RFC 1645, Southern Methodist University, July 1994.

9. 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