Network Working Group Allen Gwinn Internet Draft Southern Methodist University Expiration: 3/94 23 August 1993 SIMPLE NETWORK PAGING PROTOCOL - VERSION 1 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. Introduction 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 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. 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. 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 function that this protocol attempts to address. 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 is a single character indicating the category of response: '+', '!', and '-' respectfully. 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 "+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. A Typical Successful Connection Client Server Wait for Connection Open Connection --> <-- SNPP Gateway (Version Foo.Bar) Copyright Gwinn, Bletchley and Foo +READY PAGE 5551212 --> <-- +OK MESS Your network is hosed --> <-- +OK SEND --> <-- +Page Sent QUIT --> <-- +OK, Goodbye Commands PAGEr 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 "!ERROR, Already Entered" message, and allow the user to continue. 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 on the TAP terminal. Duplicating the MESSage command before SENDing the message should produce an "!ERROR, Already Entered" message, and allow the user to continue. 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 "+RESET OK". 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 "!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: +Page Sent - Indicates successful delivery -Error, - Indicates unsuccessful, and gives a reason After processing a SEND command, the server should remain online to allow the client to enter another page. QUIT The QUIT command terminates the current session. The server should respond "+OK, Goodbye" and close the connection. 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. Illegal Commands Should the client issue an illegal command, the server should respond "-ERROR, Goodbye" and close the connection immediately. Timeouts The SNPP server can, optionally, have an inactivity timeout implemented. At the expiration of the allotted time, the server responds "-ERROR, Timeout" and closes the connection. 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 "- SERVER DOWN, Goodbye" and is used when the gateway is administratively down, or when there are communication problems with the TAP terminal. /* SNPP Client Commands */ #define PAGER "PAGE" #define MESSAGE "MESS" #define SEND "SEND" #define QUIT "QUIT" #define RESET "RESE" #define HELP "HELP" /* Responses from SNPP server to client */ #define SNPP_READY "+READY" #define SNPP_OK "+OK" #define SNPP_RESET "+Reset OK" #define SNPP_SENT "+Page Sent" #define SNPP_NOTSENT "!Error," #define SNPP_ENTERR "!Error, Already Entered" #define SNPP_ERRINC "!Error, Incomplete Info" #define SNPP_OKCLOS "+OK, Goodbye" #define SNPP_TIMEOUT "-ERROR, Timeout" #define SNPP_ERRCLOS "-ERROR, Goodbye" #define SNPP_DOWN "-SERVER DOWN, Goodbye" Author's Address R. Allen Gwinn, Jr. Associate Director, Computing Services Business Information Center Southern Methodist University Dallas, TX 75275 Phone: 214/768-3186 Email: allen@mail.cox.smu.edu or allen@sulaco.lonestar.org