I suppose if one were to write a set of technical procedures for radio
paging over the Internet, with the goal of maximizing leverage of the
existing infrastructure, it might look like this. One might observe a
rather striking resemblence to RFC 1486...
/mtr
2. Naming, Addressing, and Routing
A radio pager is identified by a telephone number, e.g.,
+1 415 940 8776
where "+1" indicates the IDDD country code, and the remaining string is
a telephone number within that country.
2.1. Addressing
This number is used to construct the address of a radio pager server,
which forms the recipient address for the message, e.g., either
pager(_at_)6(_dot_)7(_dot_)7(_dot_)8(_dot_)0(_dot_)4(_dot_)9(_dot_)5(_dot_)1(_dot_)4(_dot_)1(_dot_)tpc(_dot_)int
or
pager(_dot_)ATOM(_at_)6(_dot_)7(_dot_)7(_dot_)8(_dot_)0(_dot_)4(_dot_)9(_dot_)5(_dot_)1(_dot_)4(_dot_)1(_dot_)tpc(_dot_)int
where "ATOM" is an (optional) RFC 822 atom [1], an opaque string for use
in recipient identification, and the domain-part is constructed by
reversing the telephone number, converting each digit to a domain-label,
and being placed under "tpc.int."
Note that the mailbox syntax is purposefully restricted in the interests
of 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)>
/ "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
/ "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
/ "|" / "}" / "~"
Finally, note that some Internet mail software (especially gateways from
outside the Internet) impose stringent limitations on the size of a
mailbox-string. Thus, 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 fashion as all other
electronic mail, i.e., using the MX algorithm [2]. Since a radio pager
server might be able to access many radio pagers, the wildcarding
facilities of the DNS [3,4] are used accordingly. For example, if a
radio pager server residing at "dbc.mtview.ca.us" was 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 pager servers were willing to access any
radio pager in that prefix, multiple MX resource records would be
present.
It should be noted that the presence of a wildcard RR which matches a
radio pager server's address does not imply that the corresponding
telephone number is valid, or, if valid, that a radio pager is
identified by the phone number. Rather, the presence of a wildcard RR
indicates that a radio pager server is willing to attempt access.
3. Procedure
When information is to be sent to a radio pager, the user application
constructs an RFC 822 message, containing a "Message-ID" field and a
textual content (e.g., a "text/plain" content [5]).
The message is then sent to the radio pager server's electronic mail
address.
3.1. MAILing versus SENDing
An SMTP client communicating with a radio pager server may use attempt
either the MAIL or SEND command. The radio pager 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, but is 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.
4. Usage Examples
4.1. MIME-based
To:
pager(_at_)6(_dot_)7(_dot_)7(_dot_)8(_dot_)0(_dot_)4(_dot_)9(_dot_)5(_dot_)1(_dot_)4(_dot_)1(_dot_)tpc(_dot_)int
cc: Marshall Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
From: Carl Malamud <carl(_at_)malamud(_dot_)com>
Date: Thu, 22 Jul 1993 08:38:00 -0800
Subject: First example
Message-ID: <19930908220700(_dot_)1(_at_)malamud(_dot_)com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
A brief textual message.
4.2. Non-MIME
To:
pager(_at_)6(_dot_)7(_dot_)7(_dot_)8(_dot_)0(_dot_)4(_dot_)9(_dot_)5(_dot_)1(_dot_)4(_dot_)1(_dot_)tpc(_dot_)int
cc: Marshall Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
From: Carl Malamud <carl(_at_)malamud(_dot_)com>
Date: Thu, 22 Jul 1993 08:38:00 -0800
Subject: Second example
Message-ID: <19930908220700(_dot_)2(_at_)malamud(_dot_)com>
Another brief textual message.
5. Security Considerations
Internet mail may be subject to monitoring by third parties, and in
particular, message relays.
6. Acknowledgements
This document was motiviated by "Simple Network Paging Protocol -
Version 1", by Allen Gwinn of Southern Methodist University.
7. References
[1] Crocker, D.H., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, University of Delaware, August, 1982.
[2] Partridge, C., "Mail Routing and the Domain System", BBN
Laboratories, RFC 974, January, 1986.
[3] Mockapetris, P.V., "Domain Names -- Concepts and Facilities", RFC
1034, Information Sciences Institute, November, 1987.
[4] Mockapetris, P.V., "Domain Names -- Implementation and
Specification", RFC 1035, Information Sciences Institute, November,
1987.
[5] Borenstein, N. and N. Freed, "MIME: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC 1341,
Bellcore, Innosoft, June, 1992.