As per Relevance of the word terminate, we have this rfc below:
Network Working Group A.
Request for Comments: 1645 Southern Methodist
Obsoletes: 1568 July 1994
Category:
Simple Network Paging Protocol - Version 2
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 for nationwide paging and messaging. In addition
email filters and SNPP client software for Unix and Windows
available at no cost. Please contact the author for
information
Earlier versions of this specification were reviewed by IESG
and the "822 Extensions" Working Group. They preferred an
strategy, as discussed under "Relationship to Other IETF Work",
below
1.
Beepers are as much a part of computer nerdom as X-
(perhaps, unfortunately, more). The intent of Simple Network
Protocol is to provide a standard whereby pages can be delivered
individual paging terminals. The most obvious benefit is
elimination of the need for modems and phone lines to
alphanumeric pages, and the added ease of delivery of pages
terminals in other cities or countries. Additionally, automatic
delivery should be 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
Gwinn [Page 1]
RFC 1645 SNPP - Version 2 July 1994
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
protocol using older style ASCII control characters and a non
standard checksumming routine to assist in validating the data
Even though TAP is widely used throughout the industry, there
plans on the table to move to a more flexible "standard"
referred to as TME (Telocator Message Entry Protocol). The level
enhancements to SNPP (as described below) are intended for use
this forthcoming standard
However, acknowledging the complexity and flexibility of the
protocols (or the lack thereof), the final user function is
simple: to deliver a page from point-of-origin to someone's beeper
That is the simple, real-time function that the base
attempts to address. Validation of the paging information is
completely up to the paging terminal, making an SNPP gateway a
"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
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. This inability to guarantee
could, whether rightly or wrongly, place the service provider in
uncomfortable position with a client who has just received his or
emergency page, six hours too late
Gwinn [Page 2]
RFC 1645 SNPP - Version 2 July 1994
Another advantage of using a separate protocol for paging delivery
that it gives the sender absolute flexibility over what is sent
the pager. For instance, in the paging arena, where messages
sent to alphanumeric pagers, it is less desirable to send
recipient general header lines from a standard SMTP message. Much
the information is useless, possibly redundant, and a waste
precious RF bandwidth
Therefore, when implementing an SMTP gateway, the service
should elect to parse out needed information (such as the sender,
possibly subject) such to maximize the utility of the transmission
Parsing generally means less control over content and format by
message originator. SNPP provides a clean, effective way to send
message, as written, to the recipient's pager
The other consideration is the relative simplicity of the
protocol for manual telnet sessions versus someone trying to
hack a mail message into a gateway
4. The SNPP
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 several input commands (the first 4 characters of each
significant) that solicit various server responses falling into
categories
2xx - Successful,
3xx - Begin DATA input (see "DATA" command
4xx - Failed with connection
5xx - Failed, but continue
The first character of every server response code is a
indicating the category of response. The text portion of
response following the code may be altered to suit
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 "220" level
(indicating the willingness of the server to accept SNPP commands).
The client passes pager ID information, and a message, then issues
"SEND" command. The server then feeds the information to the
terminal, gathers a response, and reports the success or failure
the client
Gwinn [Page 3]
RFC 1645 SNPP - Version 2 July 1994
4.1 Examples of SNPP
The following illustrate examples of client-server
using SNPP
4.1.1 A Typical Level One
Client
Open Connection -->
<-- 220 SNPP Gateway
PAGE 5551212 -->
<-- 250 Pager ID
MESS Your network is hosed -->
<-- 250 Message
SEND -->
<-- 250 Message Sent
QUIT -->
<-- 221 OK,
4.1.2 A Typical Level Two, Multiple
The following example illustrates a single message sent to
pagers. Using this level protocol, pager-specific options may
selected for each receiver by specifying the option prior to
the "PAGEr" command. In this example, an alternate coverage area
selected for the first pager, while delayed messaging is
for the second
Client
Open Connection -->
<-- 220 SNPP Server
COVE 2 -->
<-- 250 Alternate Area
PAGE 5551212 FOOBAR -->
<-- 250 Pager ID
HOLD 9401152300 -0600 -->
<-- 250 Delayed Message
PAGE 5552323 XYZZY -->
<-- 250 Pager ID
SUBJ Seattle Meeting -->
<-- 250 Message Subject
DATA -->
<-- 354 Begin Input, End With '.'
Please meet me tomorrow at -->
the Seattle office -->
<-- 250 DATA
Gwinn [Page 4]
RFC 1645 SNPP - Version 2 July 1994
SEND -->
<-- 250 Message Sent
QUIT -->
<-- 221 OK,
4.2 Level 1
Level one commands are designed as a minimum implementation of
protocol. This collection of commands may be used with
TAP/IXO or TME for message delivery to the paging terminal
4.2.1 PAGEr
The PAGEr command submits a pager ID (PID) number, for inclusion
the next messaging transaction. The PID used must reside in, and
validated by the paging terminal. Limited validation may
be done on the server (such as all numeric, and ID length),
validation can be left up to the terminal at the time the page
sent
When implementing SNPP, the user may elect to support
recipients per message sent. However, be wary that validation
prior-to-sending is not possible with TAP/IXO (and is not an
option of the current TME specification). What this means is that
order to validate a PID, one must generate a message to the pager
The terminal responds favorably or negatively. When
failure of a single PID in a sequence, delineating and reporting
failure in a "standard format" may prove to be a challenge
Possible responses from the SNPP server, with suggested text,
response to a PAGEr command are
250 Pager ID
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
550 Error, Invalid Pager
554 Error, failed (technical reason
The level 2 enhancements affect the PAGEr command. Please refer
the appropriate section for details
4.2.2 MESSage
The MESSage command specifies a single-line message, into
gateway. Limited validation of the message may be done on the
server (such as length), but type-of-message validation should
done by the paging terminal. Duplicating the MESSage command
SENDing the message should produce an "503 ERROR, Message
Gwinn [Page 5]
RFC 1645 SNPP - Version 2 July 1994
Entered" message, and allow the user to continue
Possible responses from the SNPP server, with suggested text,
response to a MESSage command are
250 Message
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
503 ERROR, Message Already
550 ERROR, Invalid
554 Error, failed (technical reason
4.2.3
The RESEt command clears already entered information from the
session, resetting it to the state of a freshly opened connection
This is provided, primarily, as a means to reset accidentally
information during a manual session
Possible responses from the SNPP server, with suggested text,
response to a RESEt command are
250 RESET
421 Too Many Errors, Goodbye (terminate
421 Gateway Service Unavailable (terminate connection
4.2.4
The SEND command finalizes the current message transaction,
processes the page to the paging terminal. Prior to processing,
PAGEr and MESSage fields (or message DATA when using the level
option) should be checked for the existence of information.
one of these required fields be missing, the server should
"503 Error, Incomplete Information" and allow the user to continue
Assuming that the information is complete, the SNPP server
format and send the page to the paging terminal, and await
response
Possible responses from the SNPP server, with suggested text,
response to a SEND command are
250 Message Sent
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
503 Error, Pager ID or Message
554 Message Failed [non-administrative reason
Gwinn [Page 6]
RFC 1645 SNPP - Version 2 July 1994
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 submit another transaction
4.2.5
The QUIT command terminates the current session. The server
simply respond
221 OK, Goodbye
and close the connection
4.2.6 HELP (optional
The optional HELP command 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" series message is issued
Possible responses from the SNPP server, with suggested text,
response to a HELP command are
214 [Help Text] (repeated for each line of information
250 End of Help
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
4.3 Level 2 - Minimum
This section specifies minimum enhancements to the SNPP protocol
added functionality
4.3.1
The DATA command is an alternate form of the MESSage command
allowing for multiple line delivery of a message to the
terminal. This command's function is similar to the DATA
implemented in SMTP (Internet STD10, RFC821). The SNPP server
only allow one DATA or MESSage command to be issued prior to a SEND
Gwinn [Page 7]
RFC 1645 SNPP - Version 2 July 1994
Possible responses from the SNPP server, with suggested text,
response to a DATA command are
354 Begin Input; End with '.'
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
503 ERROR, Message Already
500 Command Not
550 ERROR, failed (administrative reason
554 ERROR, failed (technical reason
Upon receiving a "354" response, the client begins line input of
message to send to the pager. A single period ("."), in the
position of the line, terminates input. After input, the server
respond
250 Message
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
550 ERROR, Invalid Message (or administrative reason
554 ERROR, Failed (technical reason
4.4 Level 2 - Optional
This section discusses enhancements to the SNPP protocol for
control over paging functions. These are primarily designed
mirror the added functionality built into the Telocator Message
(TME) protocol as specified in the TDP protocol suite.
functions may, optionally (as is being done by the author),
integrated into a paging terminal. There is no requirement
implement all of these functions. Requests for invalid
should return a "500 Function Not Implemented" error
It is important to note that, at the time of this publication,
TME standard is still not finalized
4.4.1 LOGIn [password
This command allows for a session login ID to be specified. It
used to validate the person attempting to access the paging terminal
If no LOGIn command is issued, "anonymous" user status is assumed
Possible responses from the SNPP server, with suggested text,
response to a LOGIn command are
250 Login
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
Gwinn [Page 8]
RFC 1645 SNPP - Version 2 July 1994
421 Illegal Access
550 Error, Invalid LoginID or
554 Error, failed (technical reason
4.4.2 PAGEr [Password/PIN
This PAGEr command is an enhancement to the level one specification
The primary difference is the ability to specify a password or
for validation or feature access
Before proceeding, it is important to understand the logical
of the PAGEr command with respect to the LEVEl, COVErage, HOLDtime
and ALERt commands (option parameters as described below). Each
a PAGEr command is issued, it should be thought of as the last
in a multiple step transaction
When the PAGEr command is processed, the pager ID (and password)
submitted to the paging terminal with LEVEl, COVErage, HOLDtime,
ALERt. If these parameters have not been altered, then
defaults are assumed for the transaction. After the next
command has been processed, these option parameters are reset
defaults. Using this type of "option-option- option-go" scheme,
is possible to specify a different priority level for "Jeff," and
alternate coverage area for "Kathy," while sending the same
to each
Possible responses from the SNPP server, with suggested text,
response to a PAGEr command are
250 Pager ID
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
550 Error, Invalid Pager ID or
554 Error, failed (technical reason
4.4.3 LEVEl
The LEVEl function is used to specify an optional alternate level
service for the next PAGEr command. Ideally, "ServiceLevel"
be an integer between 0 and 11 inclusive. The TME protocol
ServiceLevel as follows
0 -
1 - Normal (default
2 - Five
3 - Fifteen
4 - One
5 - Four
Gwinn [Page 9]
RFC 1645 SNPP - Version 2 July 1994
6 - Twelve
7 - Twenty Four
8 - Carrier specific '1'
9 - Carrier specific '2'
10 - Carrier specific '3'
11 - Carrier specific '4'
The choice on how to implement this feature, or to what level
should be implemented, should be optional and up to the discretion
the carrier
Possible responses from the SNPP server, with suggested text,
response to a LEVEl command are
250 OK, Alternate Service Level
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
550 Error, Invalid Service Level
554 Error, failed (technical reason
4.4.4 ALERt
The optional ALERt command may be used to override the
setting and specify whether or not to alert the subscriber
receipt of a message. This option, like the previous command,
the parameters submitted to the paging terminal using the
command. The TME protocol specifies AlertOverride as either 0-
DoNotAlert, or 1-Alert
Possible responses from the SNPP server, with suggested text,
response to a ALERt command are
250 OK, Alert Override
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
550 Error, Invalid Alert
554 Error, failed (technical reason
4.4.5 COVErage
The optional COVErage command is used to override the subscriber'
default coverage area, and allow for the selection of an
region. This option, like the previous command, alters
parameters submitted to the paging terminal using the PAGEr command
AlternateArea is a designator for one of the following
Gwinn [Page 10]
RFC 1645 SNPP - Version 2 July 1994
- A subscriber-specific alternate coverage
- A carrier-defined region available to
As an example, Mary Ghoti is a subscriber having local service
Chicago, Illinois (Mary's region '1'). Her account has been set
in such a manner as to allow Mary's pager to be paged nationwide
demand (Mary's region '2'). Specifying "COVErage 2" prior to
the appropriate "PAGEr" command allows the default Chicago area to
overridden, and Mary's pager to be messaged nationally for
transaction. It is assumed that the carrier providing Mary's
will keep track of how many pages have been sent to her pager in
manner, and will bill her accordingly
Possible responses from the SNPP server, with suggested text,
response to a COVErage command are
250 Alternate Coverage
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
550 Error, Invalid Alternate
554 Error, failed (technical reason
4.4.6 HOLDuntil [+/-GMTdifference
The HOLDuntil command allows for the delayed delivery of a message
to a particular subscriber, until after the time specified. The
may be specified in local time (e.g. local to the paging terminal),
or with an added parameter specifying offset from GMT (in
words, "-0600" specifies Eastern Standard Time). This option,
the previous command, alters the parameters submitted to the
terminal using the PAGEr command
Possible responses from the SNPP server, with suggested text,
response to a HOLDuntil command are
250 Delayed Messaging
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
550 Error, Invalid Delivery Date/
554 Error, failed (technical reason
4.4.7 CALLerid
The CALLerid function is a message-oriented function (as opposed
the subscriber-oriented functions just described). This allows
the specification of the CallerIdentifier function as described
Gwinn [Page 11]
RFC 1645 SNPP - Version 2 July 1994
TME. This parameter is optional, and is at the discretion of
carrier as to how it should be implemented or used
Possible responses from the SNPP server, with suggested text,
response to a CALLerid command are
250 Caller ID
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
550 Error, Invalid Caller
554 Error, failed (technical reason
4.4.8 SUBJect
The SUBJect function allows is a message-oriented function
allows the sender to specify a subject for the next message to
sent. This parameter is optional and is at the discretion of
carrier as to how it should be implemented or used
Possible responses from the SNPP server, with suggested text,
response to a SUBJect command are
250 Message Subject
421 Too Many Errors, Goodbye (terminate connection
421 Gateway Service Unavailable (terminate connection
500 Command Not
550 Error, Invalid Subject
554 Error, failed (technical reason
4.5 Illegal
Should the client issue an illegal command, the server may respond
one of the two following ways
421 Too Many Errors, Goodbye (terminate connection
500 Command Not Implemented, Try
The number of illegal commands allowed before terminating
connection should be at the discretion of the operator of the
server. The only response that has not been discussed is
421 SERVER DOWN,
This is used to refuse or terminate connections when the gateway
administratively down, or when there is some other technical
administrative problem with the paging terminal
Gwinn [Page 12]
RFC 1645 SNPP - Version 2 July 1994
4.6
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
4.7 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 to
the tastes of the operator of the SNPP server. It is suggested
the response codes mirror SMTP response codes as closely as possible
5. 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
Administrative errors (Illegal Pager ID, for example) have
separated from technical errors (out-of-space on disk, for example).
Administrative failures are generally preceded with a 550
response, while technical failures bear a 554 series code
Level two enhancements to the protocol have been added in
for TME deployment
Error code "502 Command not implemented" was changed to a
"500 Command not recognized" failure result to closer follow SMTP
6. 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.
experimental network printing protocol [4] was identified as
example of an existing infrastructure approach to an
problem. Other reviewers believed that a case could be made for
Gwinn [Page 13]
RFC 1645 SNPP - Version 2 July 1994
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 [3]
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
7.
[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, RFC 1425, February 1993.
[3] 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.
[4] Rose, M., and C. Malamud, "An Experiment in Remote Printing",
1486, Dover Beach Consulting, Inc., Internet
Service, July 1993.
Gwinn [Page 14]
RFC 1645 SNPP - Version 2 July 1994
8. Security
Security issues are not discussed in this memo
9. 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 15]
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
