Internet DRAFT - draft-ietf-stif-paging-protocol
draft-ietf-stif-paging-protocol
Network Working Group Allen Gwinn
Internet Draft <STIF> 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 <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 "!ERROR, Already Entered"
message, and allow the user to continue.
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 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, <reason> - 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
