As per Relevance of the word information, we have this rfc below:
Network Working Group A.
Request for Comments: 1568 Southern Methodist
Category: Informational January 1994
Simple Network Paging Protocol - Version 1(b
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This RFC suggests a simple way for delivering both alphanumeric
numeric pages (one-way) to radio paging terminals.
supporting this protocol, as well as SMTP, have been in use
several months in one nationwide paging firm. One other paging
is in the process of adopting it
Earlier versions of this specification were reviewed by IESG
and the IETF's "822 Extensions" Working Group. They preferred
alternate strategy, as discussed under "Relationship to Other
Work", below
1.
Beepers are as much a part of computer nerdom as X-
(perhaps, unfortunately, more). The intent of Simple Network
Protocol (SNPP) is to provide a standard whereby pages can
delivered to individual paging terminals. The most obvious
is the elimination of the need for modems to produce
pages, and the added ease of delivery of pages to terminals in
cities or countries. Additionally, automatic page delivery should
somewhat more simplified
2. System
Radio paging is somewhat taken for granted, because of the
availability and wide use of paging products. However, the
delivery of the page, and the process used (especially in wider
paging) is somewhat complicated. When a user initiates a page,
dialing a number on a telephone, or entering an alphanumeric
through some input device, the page must ultimately be delivered
some paging terminal, somewhere. In most cases, this delivery
made using TAP (Telocator Alphanumeric input Protocol, also known
IXO). This protocol can be a somewhat convoluted, and
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.
note: even though the TAP protocol allows for a password for
simple pages, they are rarely used (especially in
markets), and therefore support for them has not been implemented
this version of the protocol
Even though TAP is widely used throughout the industry, there
plans on the table to move to a more flexible "standard"
(the proposal for which is actually more convoluted than
Internet RFC's). However, acknowledging the complexity
flexibility of the current protocols (or the lack thereof), the
user function is quite simple: to deliver a page from point-of-
to someone's beeper. That is the simple, real-time function
this protocol attempts to address. Validation of the
information is left completely up to the TAP/IXO paging terminal
making an SNPP gateway a direct "shim" between a paging terminal
the Internet
3. Why not just use Email and SMTP
Email, while quite reliable, is not always timely. A good example
this is deferred messaging when a gateway is down. Suppose Mary
(fish@hugecompany.org) sends a message to Zaphod Beeblebrox's
(5551212@pager.pagingcompany.com). Hugecompany's gateway to
Internet is down causing Mary's message to be deferred. Mary
however, is not notified of this delay because her message has
actually failed to reach its destination. Three hours later,
link is restored, and (as soon as sendmail wakes up) the message
sent. Obviously, if Mary's page concerned a meeting that
supposed to happen 2 hours ago, there will be some
administrative details to work out between Mary and Zaphod
On the other hand, if Mary had used her SNPP client (or
telnetted to the SNPP gateway), she would have immediately
the network problem. She would have decided to invoke plan "B"
call Zaphod's pager on the telephone, ringing him that way
The obvious difference here is not page delivery, but the
notification of a problem that affects your message. Standard
and SMTP, while quite reliable in most cases, cannot be
guaranteed between all nodes at all times, making it less
for emergency or urgent paging. The other consideration is
relative simplicity of the SNPP protocol for manual Telnet
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
While the current form of the SNPP protocol is designed for use
TAP/IXO, it is intended to provide a porting base for use with
newer TME (TDP) protocol. In addition, future releases of SNPP
allow for multiple recipient messages with individual "envelope
options and specifications as allowed by TME. For example,
protocol should allow the user to specify delivery of an
message to Zaphod in Denver, while carbon-copying Mary in Des
at a lower priority
5. The
The SNPP protocol is a sequence of commands and replies, and is
on the philosophy of many other Internet protocols currently in use
SNPP has six input commands (the first 4 characters of each
significant) that solicit various server responses falling into
categories: (1) successful, (2) failed-but-continue, and (3) failed
with-connection-terminated. The first character of every
response code is a digit indicating the category of response: '2xx',
'5xx', and '4xx' respectfully. The text portion of the
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.
opening the connection, the server issues a greeting followed by "250
READY" (indicating the willingness of the server to accept
commands). The client passes pager ID information, and a message
then issues a "SEND" command. The server then feeds the
to the TAP paging terminal, gathers a response, and reports
success or failure to the client
6.1 A Typical Successful
Client
Open Connection -->
<-- 220 SNPP Gateway
PAGE 5551212 -->
<-- 250
MESS Your network is hosed -->
<-- 250
SEND -->
<-- 250 Page
QUIT -->
<-- 221 OK,
Gwinn [Page 3]
RFC 1568 SNPP - Version 1(b) January 1994
6.2
6.2.1 PAGEr
The PAGEr command sets the pager ID (PID) number, for
transaction, into the gateway. The PID used must reside in the
terminal (and there is where it should be validated).
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
the page is sent. Duplicating the PAGEr command before SENDing
message should produce an "503 ERROR, Already Entered" message,
allow the user to continue
In the future, a series of PAGEr commands may be specified to
for multiple recipients of the same message. Right now, however
TAP/IXO only validates the PID at the time the message is accepted
the paging terminal. This makes "pre" validation of PID's
difficult
6.2.2 MESSage
The MESSage command sets the numeric or alphanumeric message for
transaction, into the gateway. Limited validation of the message
be done on the SNPP server (such as length), but type-of-
validation should be done by the TAP/IXO paging terminal
Duplicating the MESSage command before SENDing the message
produce an "503 ERROR, Already Entered" message, and allow the
to continue
6.2.3
The RESEt command clears the PAGEr and MESSage fields, and allows
client to start over. This is provided, primarily, as a means
reset accidentally entered information during a manual session.
a successful reset, the server should respond "250 RESET OK".
6.2.4
The SEND command processes the page to the TAP terminal. Prior
processing, the PAGEr and MESSage fields should be checked for
existence of information. Should one of these required fields
missing, the server should respond "503 Error,
Information" and allow the user to continue. Assuming all of
fields are filled in, the SNPP server should format and send the
to the TAP terminal, and await a response. Upon receiving a reply
the server should respond as follows
Gwinn [Page 4]
RFC 1568 SNPP - Version 1(b) January 1994
250 Page Sent - successful
554 Failed, - unsuccessful, and gives a
Or, in the case of an illegal or non-existent pager ID, or some
administrative reason for rejecting the page, the server
respond
550 Failed, Illegal Pager ID (or other explanation
After processing a SEND command, the server should remain online
allow the client to enter another page
6.2.5
The QUIT command terminates the current session. The server
respond "221 OK, Goodbye" and close the connection
6.2.6
The HELP command (optional) displays a screen of information
commands that are valid on the SNPP server. This is primarily
assist manual users of the gateway. Each line of the HELP
(responses) are preceded by a code "214". At the end of the
sequence, a "250 OK" is issued
6.3 Illegal
Should the client issue an illegal command, the server should
"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
The SNPP server can, optionally, have an inactivity
implemented. At the expiration of the allotted time, the
responds "421 Timeout, Goodbye" and closes the connection
6.5 Rigidity of Command
The commands from client to server should remain constant. However
since the first character of the response indicates success
failure, the text of the server responses could be altered should
desire. The following is a hunk of C code that is used currently
an SNPP gateway. The only response that has not been discussed
"421 SERVER DOWN, Goodbye" and is used when the gateway
administratively down, or when there are communication problems
the TAP/IXO paging terminal
Gwinn [Page 5]
RFC 1568 SNPP - Version 1(b) January 1994
/* 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_OK "250 OK
#define SNPP_RESET "250 Reset OK
#define SNPP_SENT "250 Page Sent
#define SNPP_BADPIN "550 Failed,"
#define SNPP_NOTSENT "554 Failed,"
#define SNPP_ENTERR "503 Error, Already Entered
#define SNPP_ERRINC "503 Error, Incomplete Info
#define SNPP_OKCLOS "221 OK, Goodbye
#define SNPP_TIMEOUT "421 Timeout, Goodbye
#define SNPP_ERRCLOS "421 ERROR, Goodbye
#define SNPP_DOWN "421 SERVER DOWN, Goodbye
7. Revision
Originally, when proposed, the author employed POP2
result/response codes. The Internet community suggested that
'+' and '-' style theory be altered to provide numeric response
-- similar to those used in other services such as SMTP.
protocol has been altered to this specification from the
proposed draft
When a bad pager ID message (IXO/TAP administrative failure
received from the paging terminal, a 554 series (general failure)
returned. This has been changed to a 550 failure code allowing
distinction to be made
8. Relationship to Other IETF
The strategy of this specification, and many of its details,
reviewed by an IETF Working Group and three IESG members.
concluded that an approach using the existing email
was preferable, due in large measure to the very high costs
deploying a new protocol and the advantages of using the Internet'
most widely-distributed applications protocol infrastructure.
reviewers felt that no new protocol was needed at all because
special "deliver immediately or fail" requirements of SNPP could
accomplished by careful configuration of clients and servers.
Gwinn [Page 6]
RFC 1568 SNPP - Version 1(b) January 1994
experimental network printing protocol [3] was identified as
example of an existing infrastructure approach to an
problem. Other reviewers believed that a case could be made for
protocol details to identify paging clients and servers to each
and negotiate details of the transactions, but that it would
sensible to handle those details as extensions to SMTP [1,2]
than deploying a new protocol structure
The author, while recognizing these positions, believes that there
merit in a separate protocol to isolate details of TAP/IXO and
evolving successors from users and, indeed, from mail-
approaches that might reach systems that would act as SMTP/MIME [4]
to SNPP gateways. Such systems and gateways are, indeed,
design and development concurrent with this work. See the
"Why not just use Email and SMTP?" for additional discussion of
author's view of the classical electronic email approach
9.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker
"SMTP Service Extensions", United Nations University, Innosoft
Dover Beach Consulting, Inc., Network Management Associates
Inc., The Branch Office, February 1993.
[3] Rose, M., and C. Malamud, "An Experiment in Remote Printing",
1486, Dover Beach Consulting, Inc., Internet
Service, July 1993.
[4] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
Extensions) Part One: Mechanisms for Specifying and
the Format of Internet Message Bodies", RFC 1521, Bellcore
Innosoft, September 1993.
Gwinn [Page 7]
RFC 1568 SNPP - Version 1(b) January 1994
10. Security
Security issues are not discussed in this memo
11. Author's
R. Allen Gwinn, Jr
Associate Director, Computing
Business Information
Southern Methodist
Dallas, TX 75275
Phone: 214/768-3186
EMail: allen@mail.cox.smu.edu or allen@sulaco.lonestar.
Gwinn [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
