home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1569 < prev    next >
Text File  |  1994-01-07  |  13KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            M. Rose
  8. Request for Comments: 1569                  Dover Beach Consulting, Inc.
  9. Category: Informational                                     January 1994
  10.  
  11.  
  12.            Principles of Operation for the TPC.INT Subdomain:
  13.                   Radio Paging -- Technical Procedures
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Table of Contents
  22.  
  23.    1. Introduction ................................................    1
  24.    2. Naming, Addressing, and Routing .............................    2
  25.    2.1 Addressing .................................................    2
  26.    2.2 Routing ....................................................    3
  27.    3. Procedure ...................................................    3
  28.    3.1 MAILing versus SENDing .....................................    4
  29.    3.2 Latency ....................................................    4
  30.    4. Usage Examples ..............................................    5
  31.    4.1 MIME-based .................................................    5
  32.    4.2 Non-MIME ...................................................    5
  33.    5. Security Considerations .....................................    6
  34.    6. Acknowledgements ............................................    6
  35.    7. References ..................................................    6
  36.    8. Author's Address ............................................    6
  37.  
  38. 1.  Introduction
  39.  
  40.    As an adjunct to the usual, two-way electronic mail service, it is at
  41.    times useful to employ a one-way text notification service, called
  42.    radio paging.  This memo describes a technique for radio paging using
  43.    the Internet mail infrastructure.  In particular, this memo focuses
  44.    on the case in which radio pagers are identified via the
  45.    international telephone network.
  46.  
  47.    The technique described by this memo, mapping telephone numbers to
  48.    domain names, is derived from the TPC.INT subdomain.  Consult RFC
  49.    1530, "Principles of Operation for the TPC.INT Subdomain: General
  50.    Principles and Policy" for overview information.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Rose                                                            [Page 1]
  59.  
  60. RFC 1569          Radio Paging -- Technical Procedures      January 1994
  61.  
  62.  
  63. 2.  Naming, Addressing, and Routing
  64.  
  65.    A radio pager is identified by a telephone number, e.g.,
  66.  
  67.      +1 415 940 8776
  68.  
  69.    where "+1" indicates the IDDD country code, and the remaining string
  70.    is a telephone number within that country.
  71.  
  72. 2.1.  Addressing
  73.  
  74.    This number is used to construct the address of a radio pager server,
  75.    which forms the recipient address for the message, e.g., one of:
  76.  
  77.      pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  78.      pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  79.  
  80.    where the domain-part is constructed by reversing the telephone
  81.    number, converting each digit to a domain-label, and being placed
  82.    under "tpc.int." (The telephone number must not include any
  83.    international access codes.)
  84.  
  85.    In addition, addresses of the form
  86.  
  87.      pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  88.      pager-alpha.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  89.      pager-numeric.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  90.  
  91.    where "ATOM" is an (optional) RFC 822 atom [1], are reserved for
  92.    future use.  Note that the mailbox syntax is purposefully restricted
  93.    in the interests of pragmatism.  To paraphrase RFC 822, an atom is
  94.    defined as:
  95.  
  96.      atom    = 1*atomchar
  97.  
  98.      atomchar=   <any upper or lowercase alphabetic character
  99.                   (A-Z a-z)>
  100.                / <any digit (0-9)>
  101.                / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
  102.                / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
  103.                / "|" / "}" / "~"
  104.  
  105.    Finally, note that some Internet mail software (especially gateways
  106.    from outside the Internet) impose stringent limitations on the size
  107.    of a mailbox-string.  Thus, originating user agents should take care
  108.    in limiting the local-part to no more than 70 or so characters.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Rose                                                            [Page 2]
  115.  
  116. RFC 1569          Radio Paging -- Technical Procedures      January 1994
  117.  
  118.  
  119. 2.2.  Routing
  120.  
  121.    The message is routed in exactly the same fashion as all other
  122.    electronic mail, i.e., using the MX algorithm [2].  Since a radio
  123.    pager server might be able to access many radio pagers, the
  124.    wildcarding facilities of the DNS [3,4] are used accordingly.  For
  125.    example, if a radio pager server residing at "dbc.mtview.ca.us" is
  126.    willing to access any radio pager with a telephone number prefix of
  127.  
  128.      +1 415 940
  129.  
  130.    then this resource record might be present
  131.  
  132.      *.0.4.9.5.1.4.1.tpc.int.    IN MX 10 dbc.mtview.ca.us.
  133.  
  134.    Naturally, if several radio pager servers were willing to access any
  135.    radio pager in that prefix, multiple MX resource records would be
  136.    present.
  137.  
  138.    It should be noted that the presence of a wildcard RR which matches a
  139.    radio pager server's address does not imply that the corresponding
  140.    telephone number is valid, or, if valid, that a radio pager is
  141.    identified by the phone number.  Rather, the presence of a wildcard
  142.    RR indicates that a radio pager server is willing to attempt access.
  143.  
  144. 3.  Procedure
  145.  
  146.    When information is to be sent to a radio pager, the user application
  147.    constructs an RFC 822 message, containing a "Message-ID" field and a
  148.    textual content (e.g., a "text/plain" content [5]).
  149.  
  150.    The message is then sent to the radio pager server's electronic mail
  151.    address.
  152.  
  153.    The radio pager server begins by looking at the local part of the
  154.    address.  If the local-part is the literal string "pager-alpha" then
  155.    this indicates that the recipient is using an alpha-numeric pager.
  156.    The radio pager server consults a local database to determine how to
  157.    send the page based on the domain-part.  This local knowledge
  158.    includes information about the protocol used to talk to the paging
  159.    network and the access number.  As such, a radio pager server will
  160.    register itself in the DNS as providing service only to those phone
  161.    numbers for which it has such knowledge.
  162.  
  163.    Otherwise, if the local-part is the literal string "pager-numeric"
  164.    then this indicates that the recipient is using a numeric pager.  The
  165.    radio pager server may consult a local database to determine how to
  166.    send the page based on the domain-part; or, it may dial the number
  167.  
  168.  
  169.  
  170. Rose                                                            [Page 3]
  171.  
  172. RFC 1569          Radio Paging -- Technical Procedures      January 1994
  173.  
  174.  
  175.    specified in the domain-part directly.
  176.  
  177.    For alpha-numeric pagers, the radio pager server determines which
  178.    information found in the headers and body of the message are used
  179.    when constructing the paging message.  For example, some radio pager
  180.    servers might choose to examine the "To" and "Subject" fields, in
  181.    addition to the body, whilst other radio pager servers might choose
  182.    to simply send the body verbatim.
  183.  
  184.    For numeric pagers, the radio pager server sends only the body, which
  185.    must consistent solely of digits.
  186.  
  187. 3.1.  MAILing versus SENDing
  188.  
  189.    An SMTP client communicating with a radio pager server may use
  190.    attempt either the MAIL or SEND command.  The radio pager server MUST
  191.    support the MAIL command, and MAY support any of the SEND, SOML, or
  192.    SAML commands.
  193.  
  194.    If the MAIL command is used, then a positive completion reply to both
  195.    the RCPT and DATA commands indicates, at a minimum, that the message
  196.    has been queued for transmission into the radio paging network for
  197.    the recipient, but is at least queued for transmission into the radio
  198.    paging network.
  199.  
  200.    If the SEND command is used, then a positive completion reply to both
  201.    the RCPT and DATA commands indicates that the message has been
  202.    accepted by the radio paging network for delivery to the recipient.
  203.  
  204.    If the SOML or SAML command is used, then a positive completion reply
  205.    to both the RCPT and DATA commands indicates that the message may
  206.    have been accepted by the radio paging network for delivery to the
  207.    recipient.
  208.  
  209. 3.2.  Latency
  210.  
  211.    Although the Internet electronic mail service tends to perform
  212.    delivery in a timely and reliable manner, some paging services will
  213.    wish to provide a higher degree of assurance to their clients, in
  214.    particular guaranteeing that a positive reply code means that the
  215.    page has been sent on the radio network.  For such requirements, the
  216.    primary constraints are server implementation and client/server
  217.    network connectivity.
  218.  
  219.    A client that uses the SEND or SAML commands is explicitly requesting
  220.    real-time transmission on the radio network and is requiring that the
  221.    server reply code will carry a statement of success or failure about
  222.    that transmission.
  223.  
  224.  
  225.  
  226. Rose                                                            [Page 4]
  227.  
  228. RFC 1569          Radio Paging -- Technical Procedures      January 1994
  229.  
  230.  
  231.    The IP level of the Internet performs datagram store-and-forward
  232.    service, but gives the end system hosts the appearance of direct
  233.    connectivity, by virtue of allowing interactive service.  The
  234.    Internet electronic mail service adds another layer of store-and-
  235.    forward indirection, so that messages may go through any number of
  236.    relays (and/or gateways).  This may introduce arbitrarily large
  237.    delays of minutes, hours, or days.
  238.  
  239.    A client that configures their Internet attachment to permit "direct"
  240.    SMTP connectivity to a pager server will be able to submit paging
  241.    requests to the server directly, without additional SMTP-relaying.
  242.    That is, transmission from paging client to paging server will be one
  243.    "SMTP-hop"only.  This will eliminate any possibility of non-
  244.    deterministic delay by the Internet itself.
  245.  
  246.    The combination of configuring paging server and paging client to
  247.    allow direct IP/SMTP-level interaction and ensuring that they use
  248.    SEND or SAML commands only will mean that a client receiving a
  249.    positive reply from the server is assured that the page has been sent
  250.    on the radio network.
  251.  
  252. 4.  Usage Examples
  253.  
  254. 4.1.  MIME-based
  255.  
  256.      To: pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  257.      cc: Marshall Rose <mrose@dbc.mtview.ca.us>
  258.      From: Carl Malamud <carl@malamud.com>
  259.      Date: Thu, 22 Jul 1993 08:38:00 -0800
  260.      Subject: First example, for an alphanumeric pager
  261.      Message-ID: <19930908220700.1@malamud.com>
  262.      MIME-Version: 1.0
  263.      Content-Type: text/plain; charset=us-ascii
  264.  
  265.      A brief textual message.
  266.  
  267. 4.2.  Non-MIME
  268.  
  269.      To: pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int
  270.      cc: Marshall Rose <mrose@dbc.mtview.ca.us>
  271.      From: Carl Malamud <carl@malamud.com>
  272.      Date: Thu, 22 Jul 1993 08:38:00 -0800
  273.      Subject: Second example, for a numeric pager
  274.      Message-ID: <19930908220700.2@malamud.com>
  275.  
  276.      2026282044
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Rose                                                            [Page 5]
  283.  
  284. RFC 1569          Radio Paging -- Technical Procedures      January 1994
  285.  
  286.  
  287. 5.  Security Considerations
  288.  
  289.    Internet mail may be subject to monitoring by third parties, and in
  290.    particular, message relays.
  291.  
  292. 6.  Acknowledgements
  293.  
  294.    This document was motivated by "Simple Network Paging Protocol -
  295.    Version 1", by Allen Gwinn of Southern Methodist University.
  296.  
  297.    David H. Crocker and Carl Malamud also provided substantive comments.
  298.  
  299. 7.  References
  300.  
  301.    [1] Crocker, D., "Standard for the Format of ARPA Internet Text
  302.        Messages", STD 11, RFC 822, University of Delaware, August 1982.
  303.  
  304.    [2] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  305.        974, BBN, January 1986.
  306.  
  307.    [3] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
  308.        13, RFC 1034, Information Sciences Institute, November 1987.
  309.  
  310.    [4] Mockapetris, P., "Domain Names -- Implementation and
  311.        Specification", STD 13, RFC 1035, Information Sciences Institute,
  312.        November 1987.
  313.  
  314.    [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
  315.        Extensions) Part One: Mechanisms for Specifying and Describing
  316.        the Format of Internet Message Bodies", RFC 1521, Bellcore,
  317.        Innosoft, September 1993.
  318.  
  319. 8.  Author's Address
  320.  
  321.    Marshall T. Rose
  322.    Dover Beach Consulting, Inc.
  323.    420 Whisman Court
  324.    Mountain View, CA  94043-2186
  325.    US
  326.  
  327.    Phone: +1 415 968 1052
  328.    Fax:   +1 415 968 2510
  329.    EMail: mrose@dbc.mtview.ca.us
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Rose                                                            [Page 6]
  339.  
  340.