summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1703.txt
blob: 13d15fdc463bc73db64df10df81529a5f097773b (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
Network Working Group                                            M. Rose
Request for Comments: 1703                  Dover Beach Consulting, Inc.
Obsoletes: 1569                                             October 1994
Category: Informational


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

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

   As an adjunct to the usual, two-way electronic mail service, it is at
   times useful to employ a one-way text notification service, called
   radio paging.  This memo describes a technique for radio paging using
   the Internet mail infrastructure.  In particular, this memo focuses
   on the case in which radio pagers are identified via the
   international telephone network.

   The technique described by this memo, mapping telephone numbers to
   domain names, is derived from the TPC.INT subdomain.  Consult RFC
   1530, "Principles of Operation for the TPC.INT Subdomain: General
   Principles and Policy" for overview information.



Rose                                                            [Page 1]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


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.

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

2.1.  Addressing

   This number is used to construct the address of a radio paging
   server, which forms the recipient address for the message, e.g., one
   of:

     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

   where "ATOM" is an RFC 822 atom [1], an opaque string for use in
   recipient identification when communicating with the paging network,
   and the domain-part is constructed by reversing the telephone number,
   converting each digit to a domain-label, and being placed 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, 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.





Rose                                                            [Page 2]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


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
   paging 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 paging server residing 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 were willing to access any
   radio pager in that prefix, multiple MX resource records would be
   present.  (The DNS servers for the TPC.INT subdomain perform a
   rudimentary form of load balancing by rotating the order of the MX
   records returned on each query.)

   It should be noted that the presence of a wildcard RR which matches a
   radio paging 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 paging 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 paging server's electronic mail
   address.  The radio paging server begins 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
   this indicates that the recipient is using an alpha-numeric radio
   pager, and ATOM either identifies a paging network (CARRIER), or a
   radio pager identity number (PIN), or both, according to 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,




Rose                                                            [Page 3]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


   (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 is used to identify the radio pager.

   If the local-part starts with "pager.", then the message sent to the
   radio pager consists of the body of the message; otherwise, if the
   local-part starts with "pager-alpha.", then the radio paging server
   determines which information in the headers and body of the message
   are used when constructing the paging message.  For example, some
   radio paging servers might choose to examine the "To" and "Subject"
   fields, in addition to the body, whilst other radio paging servers
   might choose to simply send the body verbatim.

3.2.  Numeric Radio Pagers

   If the local-part is the literal string "pager-numeric" then this
   indicates that 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 communicating with a radio paging server may use
   attempt 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, 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.





Rose                                                            [Page 4]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


   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

   Although the Internet electronic mail service tends to perform
   delivery in a timely and reliable manner, some paging services will
   wish to provide a higher degree of assurance to their clients, in
   particular guaranteeing that a positive reply code means that the
   page has been sent on the radio paging network.  For such
   requirements, the primary constraints are server implementation and
   client/server network connectivity.

   A client that uses the SEND or SAML commands is explicitly requesting
   real-time transmission on the radio paging network and is requiring
   that the server reply code will carry a statement of success or
   failure about that transmission.

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

   A client that configures their Internet attachment to permit "direct"
   SMTP connectivity to a radio paging server will be able to submit
   paging requests to the server directly, without additional SMTP-
   relaying. That is, transmission from radio paging client to server
   will be one "SMTP-hop"only.  This will eliminate any possibility of
   non-deterministic delay by the Internet itself.

   The combination of configuring radio paging server and client to
   allow direct IP/SMTP-level interaction and ensuring that they use
   SEND or SAML commands only will mean that a client receiving a
   positive reply from the server is assured that the page has been sent
   on the radio paging network.

4.  Usage Examples

   These examples make use of the "iddd.tpc.int" subdomain.  The DNS
   servers for this subdomain, upon encountering a domain of the form:

        NUMBER.iddd.tpc.int




Rose                                                            [Page 5]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


   automatically create a CNAME RR of the 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

     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

     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

   A hypothetical radio paging carrier, e.g.,

     Pigeon Paging

   might choose to integrate its radio paging services with Internet e-
   mail in the following fashion:






Rose                                                            [Page 6]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


   (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 carry 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>




Rose                                                            [Page 7]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


        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

   Internet mail may be subject to monitoring by third parties, and in
   particular, message relays.

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.

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.



Rose                                                            [Page 8]
^L
RFC 1703          Radio Paging -- Technical Procedures      October 1994


   [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






























Rose                                                            [Page 9]
^L