rfc1568.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           A. Gwinn
Request for Comments: 1568                 Southern Methodist University
Category: Informational                                     January 1994


             Simple Network Paging Protocol - Version 1(b)

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 both alphanumeric and
   numeric pages (one-way) to radio paging terminals.  Gateways
   supporting this protocol, as well as SMTP, have been in use for
   several months in one nationwide paging firm.  One other paging firm
   is in the process of adopting it.

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

1. Introduction

   Beepers are as much a part of computer nerdom as X-terminals
   (perhaps, unfortunately, more).  The intent of Simple Network Paging
   Protocol (SNPP) 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 to produce alphanumeric
   pages, and the added ease of delivery of pages to terminals in other
   cities or countries.  Additionally, automatic page delivery should be
   somewhat more simplified.

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



Gwinn                                                           [Page 1]

RFC 1568                  SNPP - Version 1(b)               January 1994


   protocol using older style ASCII control characters and a non-
   standard checksumming routine to assist in validating the data.  One
   note: even though the TAP protocol allows for a password for sending
   simple pages, they are rarely used (especially in commercial
   markets), and therefore support for them has not been implemented in
   this version of the protocol.

   Even though TAP is widely used throughout the industry, there are
   plans on the table to move to a more flexible "standard" protocol
   (the proposal for which is actually more convoluted than most
   Internet RFC's).  However, acknowledging the complexity 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
   this protocol attempts to address.  Validation of the paging
   information is left completely up to the TAP/IXO paging terminal,
   making an SNPP gateway a direct "shim" between a paging terminal and
   the Internet.

3. Why not just use Email and SMTP?

   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.  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                                                           [Page 2]

RFC 1568                  SNPP - Version 1(b)               January 1994


4. The Future of SNPP

   While the current form of the SNPP protocol is designed for use with
   TAP/IXO, it is intended to provide a porting base for use with the
   newer TME (TDP) protocol.  In addition, future releases of SNPP will
   allow for multiple recipient messages with individual "envelope"
   options and specifications as allowed by TME.  For example, the
   protocol should allow the user to specify delivery of an urgent
   message to Zaphod in Denver, while carbon-copying Mary in Des Moines
   at a lower priority.

5. The 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 six input commands (the first 4 characters of each are
   significant) that solicit various server responses falling into three
   categories: (1) successful, (2) failed-but-continue, and (3) failed-
   with-connection-terminated.  The first character of every server
   response code is a digit indicating the category of response: '2xx',
   '5xx', and '4xx' respectfully.  The text portion of the response
   following the code may be altered to suit individual applications.

   The session interaction is actually quite simple (hence the name).
   The client initiates the connection with the listening server.  Upon
   opening the connection, the server issues a greeting followed by "250
   READY" (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 TAP paging terminal, gathers a response, and reports the
   success or failure to the client.

6.1 A Typical Successful Connection

           Client                         Server

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





Gwinn                                                           [Page 3]

RFC 1568                  SNPP - Version 1(b)               January 1994


6.2 Commands

6.2.1 PAGEr <Pager ID>

   The PAGEr command sets the pager ID (PID) number, for the
   transaction, into the gateway.  The PID used must reside in the TAP
   terminal (and there is where it should be validated).  Limited
   validation may optionally be done on the server (such as all numeric,
   and ID length), or it can all be done by the TAP terminal at the time
   the page is sent.  Duplicating the PAGEr command before SENDing the
   message should produce an "503 ERROR, Already Entered" message, and
   allow the user to continue.

   In the future, a series of PAGEr commands may be specified to allow
   for multiple recipients of the same message.  Right now, however,
   TAP/IXO only validates the PID at the time the message is accepted by
   the paging terminal.  This makes "pre" validation of PID's currently
   difficult.

6.2.2 MESSage <Alpha or Numeric Message>

   The MESSage command sets the numeric or alphanumeric message for the
   transaction, into the gateway.  Limited validation of the message may
   be done on the SNPP server (such as length), but type-of-message
   validation should be done by the TAP/IXO paging terminal.
   Duplicating the MESSage command before SENDing the message should
   produce an "503 ERROR, Already Entered" message, and allow the user
   to continue.

6.2.3 RESEt

   The RESEt command clears the PAGEr and MESSage fields, and allows the
   client to start over.  This is provided, primarily, as a means to
   reset accidentally entered information during a manual session. Upon
   a successful reset, the server should respond "250 RESET OK".

6.2.4 SEND

   The SEND command processes the page to the TAP terminal.  Prior to
   processing, the PAGEr and MESSage fields should be checked for the
   existence of information.  Should one of these required fields be
   missing, the server should respond "503 Error, Incomplete
   Information" and allow the user to continue.  Assuming all of the
   fields are filled in, the SNPP server should format and send the page
   to the TAP terminal, and await a response.  Upon receiving a reply,
   the server should respond as follows:





Gwinn                                                           [Page 4]