GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1703

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] 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] 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] 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] 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] 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] 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] 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] 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1703.txt · Last modified: 1994/10/21 20:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki