Network Working Group A. Gwinn
Request for Comments: 1568 Southern Methodist University
Category: Informational January 1994
Simple Network Paging Protocol - Version 1(b)
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 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.
Gwinn [Page 1]
RFC 1568 SNPP - Version 1(b) January 1994
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 (fish@hugecompany.org) sends a message to Zaphod Beeblebrox's beeper (5551212@pager.pagingcompany.com). 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!
Gwinn [Page 2]
RFC 1568 SNPP - Version 1(b) January 1994 4. The Future of SNPPWhile 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.
6.1 A Typical Successful Connection
Client Server
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.
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: 250 Page Sent - successful delivery 554 Failed, <reason> - unsuccessful, and gives a reason
Gwinn [Page 4]
RFC 1568 SNPP - Version 1(b) January 1994
Or, in the case of an illegal or non-existent pager ID, or some other administrative reason for rejecting the page, the server should respond:
6.2.5 QUIT
The QUIT command terminates the current session. The server should respond "221 OK, Goodbye" and close the connection.
6.2.6 HELP
The HELP command (optional) displays a screen of information about commands that are valid on the SNPP server. This is primarily to assist manual users of the gateway. Each line of the HELP screen (responses) are preceded by a code "214". At the end of the HELP sequence, a "250 OK" is issued.
6.3 Illegal Commands
Should the client issue an illegal command, the server should respond "421 ERROR, Goodbye" and close the connection immediately. Optionally, the server may respond "502 Command Error, try again" should it be desirable to leave the connection open.
6.4 Timeouts
The SNPP server can, optionally, have an inactivity timeout implemented. At the expiration of the allotted time, the server responds "421 Timeout, Goodbye" and closes the connection.
6.5 Rigidity of Command Structure
The commands from client to server should remain constant. However, since the first character of the response indicates success or failure, the text of the server responses could be altered should one desire. The following is a hunk of C code that is used currently in an SNPP gateway. The only response that has not been discussed is "421 SERVER DOWN, Goodbye" and is used when the gateway is administratively down, or when there are communication problems with the TAP/IXO paging terminal. /* SNPP Client Commands */
Gwinn [Page 5]
RFC 1568 SNPP - Version 1(b) January 1994
#define PAGER "PAGE" #define MESSAGE "MESS" #define SEND "SEND" #define QUIT "QUIT" #define RESET "RESE" #define HELP "HELP"
7. Revision History
Originally, when proposed, the author employed POP2 style result/response codes. The Internet community suggested that this '+' and '-' style theory be altered to provide numeric response codes -- similar to those used in other services such as SMTP. The protocol has been altered to this specification from the first proposed draft.
8. Relationship to Other IETF Work
The strategy of this specification, and many of its details, were reviewed by an IETF Working Group and three IESG members. They concluded that an approach using the existing email infrastructure was preferable, due in large measure to the very high costs of deploying a new protocol and the advantages of using the Internet's most widely-distributed applications protocol infrastructure. Most reviewers felt that no new protocol was needed at all because the special "deliver immediately or fail" requirements of SNPP could be accomplished by careful configuration of clients and servers. The experimental network printing protocol [3] was identified as an example of an existing infrastructure approach to an existing problem. Other reviewers believed that a case could be made for new protocol details to identify paging clients and servers to each other and negotiate details of the transactions, but that it would be sensible to handle those details as extensions to SMTP [1,2] rather than deploying a new protocol structure.
Gwinn [Page 6]
RFC 1568 SNPP - Version 1(b) January 1994
The author, while recognizing these positions, believes that there is merit in a separate protocol to isolate details of TAP/IXO and its evolving successors from users and, indeed, from mail-based approaches that might reach systems that would act as SMTP/MIME [4] to SNPP gateways. Such systems and gateways are, indeed, undergoing design and development concurrent with this work. See the section "Why not just use Email and SMTP?" for additional discussion of the author's view of the classical electronic email approach.
9. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
Gwinn [Page 7]
RFC 1568 SNPP - Version 1(b) January 1994 10. Security ConsiderationsSecurity issues are not discussed in this memo.
11. Author's Address
R. Allen Gwinn, Jr. Associate Director, Computing Services Business Information Center Southern Methodist University Dallas, TX 75275