rfc1861.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,292 行 · 第 1/4 页

Network Working Group                                           A. Gwinn
Request for Comments: 1861                 Southern Methodist University
Obsoletes: 1645                                             October 1995
Category: Informational


     Simple Network Paging Protocol - Version 3 - Two-Way Enhanced

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.

Abstract

   This RFC suggests a simple way for delivering wireless messages, both
   one and two-way, to appropriate receiving devices.  In its simplest
   form, SNPP provides a simple way to implement a "shim" between the
   Internet and a TAP/IXO paging terminal. In its level 3 form, it
   provides an easy-to-use (and build) method for communicating and
   receiving end-to-end acknowledgments and replies from two-way
   messaging devices (such as ReFLEX units).

   Gateways supporting this protocol, as well as SMTP, have been in use
   for well over a year at several commercial paging companies, and
   private businesses.  Client software supporting this protocol has
   become widespread, and is being integrated into many of the new
   paging and messaging products being built.  In addition to commercial
   software, email filters and SNPP client software for Unix and Windows
   (WikiPage) are available at no cost.  Please contact the author for
   more information.

   Earlier versions of this specification were reviewed by IESG members
   and the "822 Extensions" Working Group.  They preferred an alternate
   strategy, as discussed under "Relationship to Other IETF Work",
   below.

1. Introduction

   With all due apologies to the Glenayre engineers (who take offense at
   the term "nerd") beepers are as much a part of computer nerdom as X-
   terminals--perhaps, unfortunately, more. The intent of Simple Network
   Paging Protocol is to provide a standard whereby pages can be
   delivered to individual paging terminals.  The most obvious benefit
   is the elimination of the need for modems and phone lines to produce
   alphanumeric pages, and the added ease of delivery of pages to
   terminals in other cities or countries. The benefits of the Internet



Gwinn                        Informational                     [Page 1]

RFC 1861                   SNPP - Version 3                October 1995


   become even more realized when growing towards acknowledgment-based
   messaging such as ReFLEX paging--where it may be impossible to
   accurately predict costs associated with telco services such as 1-800
   numbers.

2. System Philosophy

   Radio paging is somewhat taken for granted, because of the wide
   availability and wide use of paging products.  However, the actual
   delivery of the page, and the process used (especially in wider area
   paging) is somewhat complicated.  When a user initiates a page, by
   dialing a number on a telephone, or entering an alphanumeric page
   through some input device, the page must ultimately be delivered to
   some paging terminal, somewhere.  In most cases, this delivery is
   made using TAP (Telocator Alphanumeric input Protocol, also known as
   IXO).  This protocol can be a somewhat convoluted, and complicated
   protocol using older style ASCII control characters and a non-
   standard checksumming routine to assist in validating the data.

   Even though TAP is widely used throughout the industry, there are
   plans on the table to move to a more flexible "standard" protocol
   referred to as TME (Telocator Message Entry Protocol).  The level two
   enhancements to SNPP (as described below) are intended for use with
   this forthcoming standard.

   The recently-added level three enhancements have been engineered for
   use, specifically, with acknowledgment-based paging.  With the recent
   advances in wireless technology, two-way paging is fast approaching
   reality--therefore creating a need for a workable end-to-end
   acknowledged protocol.  Two-way messaging, however, opens up several
   new areas of unpredictability.  The most pronounced is the subscriber
   response time.  Although deliveries from host to subscriber, and
   subsequent receipt-acknowledgments happen in a rather predictable
   manner, it is impossible to know when the subscriber will physically
   pull the unit out, read the message and respond to it.  Therefore, it
   could well be cost prohibitive to conduct such transactions online
   using a phone line as medium--especially an 800-number. This makes
   the Internet an extremely attractive alternative because of its
   (generally) usage insensitive nature.

   However, acknowledging the complexity of task, and flexibility of the
   current protocols (or the lack thereof), the final user function is
   quite simple: to deliver a page from point-of-origin to someone's
   beeper.  That is the simple, real-time function that the base
   protocol attempts to address.






Gwinn                        Informational                     [Page 2]

RFC 1861                   SNPP - Version 3                October 1995


3. Why not just use Email and SMTP for paging?

   Email, while quite reliable, is not always timely.  A good example of
   this is deferred messaging when a gateway is down. Suppose Mary Ghoti
   ([e-mail]) sends a message to Zaphod Beeblebrox's beeper
   ([e-mail]). Hugecompany's gateway to the
   Internet is down causing Mary's message to be deferred.  Mary,
   however, is not notified of this delay because her message has not
   actually failed to reach its destination.  Three hours later, the
   link is restored, and (as soon as sendmail wakes up) the message is
   sent.  Obviously, if Mary's page concerned a meeting that was
   supposed to happen 2 hours ago, there will be some minor
   administrative details to work out between Mary and Zaphod!

   On the other hand, if Mary had used her SNPP client (or simply
   telnetted to the SNPP gateway), she would have immediately discovered
   the network problem.  She would have decided to invoke plan "B" and
   call Zaphod's pager on the telephone, ringing him that way.

   The obvious difference here is not page delivery, but the immediate
   notification of a problem that affects your message. Standard email
   and SMTP, while quite reliable in most cases, cannot be positively
   guaranteed between all nodes at all times, making it less desirable
   for emergency or urgent paging.  This inability to guarantee delivery
   could, whether rightly or wrongly, place the service provider in an
   uncomfortable position with a client who has just received his or her
   emergency page, six hours too late.

   Another advantage of using a separate protocol for paging delivery is
   that it gives the sender absolute flexibility over what is sent to
   the pager.  For instance, in the paging arena, where messages are
   sent to alphanumeric pagers, it is less desirable to send the
   recipient general header lines from a standard SMTP message.  Much of
   the information is useless, possibly redundant, and a waste of
   precious RF bandwidth.

   Therefore, when implementing an SMTP gateway, the service provider
   should elect to parse out needed information (such as the sender, and
   possibly subject) such to maximize the utility of the transmission.
   Parsing generally means less control over content and format by the
   message originator.  SNPP provides a clean, effective way to send a
   message, as written, to the recipient's pager.

   The other consideration is the relative simplicity of the SNPP
   protocol for manual telnet sessions versus someone trying to manually
   hack a mail message into a gateway.





Gwinn                        Informational                     [Page 3]

RFC 1861                   SNPP - Version 3                October 1995


4. The SNPP Protocol

   The SNPP protocol is a sequence of commands and replies, and is based
   on the philosophy of many other Internet protocols currently in use.
   SNPP has several input commands (the first 4 characters of each are
   significant) that solicit various server responses falling into the
   following categories:

    2xx - Successful, continue
    3xx - Begin DATA input (see "DATA" command)
    4xx - Failed with connection terminated
    5xx - Failed, but continue session

   SNPP version 3 (two-way) adds the following categories:


    7xx - UNsuccessful two-way specific transaction, but continue
          session
    8xx - Successful two-way specific transaction, continue
    9xx - Successful QUEUED two-way transaction, continue

   The first character of every server response code is a digit
   indicating the category of response.  The text portion of the
   response following the code may be altered to suit individual
   applications.

   The session interaction, especially at SNPP level one, is actually
   quite simple (hence the name).  The client initiates the connection
   with the listening server.  Upon opening the connection, the server
   issues a "220" level message (indicating the willingness of the
   server to accept SNPP commands).  The client passes pager ID
   information, and a message, then issues a "SEND" command.  The server
   then feeds the information to the paging terminal, gathers a
   response, and reports the success or failure to the client.

4.1 Examples of "simple" SNPP Transactions

   The following illustrate examples of client-server communication
   using SNPP.












Gwinn                        Informational                     [Page 4]

RFC 1861                   SNPP - Version 3                October 1995


4.1.1 A Typical Level One Connection

            Client                         Server

    Open Connection               -->
                                  <--  220 SNPP Gateway Ready
    PAGE 5551212                  -->
                                  <--  250 Pager ID Accepted
    MESS Your network is hosed    -->
                                  <--  250 Message OK
    SEND                          -->
                                  <--  250 Message Sent OK
    QUIT                          -->
                                  <--  221 OK, Goodbye

4.1.2 A Typical Level Two, Multiple Transaction

   The following example illustrates a single message sent to two
   pagers.  Using this level protocol, pager-specific options may be
   selected for each receiver by specifying the option prior to issuing
   the "PAGEr" command.  In this example, an alternate coverage area is
   selected for the first pager, while delayed messaging is specified
   for the second.

            Client                         Server

    Open Connection               -->
                                  <--  220 SNPP Server Ready
    COVE 2                        -->
                                  <--  250 Alternate Area Selected
    PAGE 5551212 FOOBAR           -->
                                  <--  250 Pager ID Accepted
    HOLD 9401152300 -0600         -->
                                  <--  250 Delayed Message OK
    PAGE 5552323 XYZZY            -->
                                  <--  250 Pager ID Accepted
    SUBJ Seattle Meeting          -->
                                  <--  250 Message Subject OK
    DATA                          -->
                                  <--  354 Begin Input, End With '.'
    Please meet me tomorrow at    -->
    the Seattle office            -->
                                  <--  250 DATA Accepted
    SEND                          -->
                                  <--  250 Message Sent OK
    QUIT                          -->
                                  <--  221 OK, Goodbye




Gwinn                        Informational                     [Page 5]

RFC 1861                   SNPP - Version 3                October 1995


4.1.3 A Typical Level Three (two-way) Transaction

   Level three transactions are inherently single-unit oriented because
   of the one-to-one issues surrounding responses.  Each transaction
   begins with the "2WAY" command and terminates with a "SEND" command.

        Client                         Server

Open Connection               -->
                              <--  220 SNPP (V3) Gateway Ready
2WAY                          -->
                              <--  250 Two-Way Mode Enabled
NOQUEUE                       -->
                              <--  250 Msg will either be Sent or Rejected
PAGER SHIRLEY                 -->
                              <--  850 Unit online; Don't call me Shirley!
ACKRead 1                     -->
                              <--  250 Read Acknowledgment Requested
DATA                          -->
                              <--  354 Begin Input, End With '.'
Little Bo Binary has lost     -->
her Sparcstation and doesn't  -->
know where to find it. Have   -->
you seen it recently?         -->
                              <--  250 DATA Accepted
RTYPE MULTICHOICE             -->
                              <--  250 Multichoice Responses Enabled
MCRESP 01 In the West Pasture -->
                              <--  250 MCR Code Accepted
MCRESP 02 GoldiFLOCKs has it  -->
                              <--  250 MCR Code Accepted
MCRESP 03 Haven't a clue      -->
                              <--  250 MCR Code Accepted
MCRESP 04 Haven't a life      -->
                              <--  250 MCR Code Accepted
MCRESP 05 Oh, GO AWAY!        -->
                              <--  250 MCR Code Accepted