As per Relevance of the word terminate, we have this rfc below:
Network Working Group A.
Request for Comments: 1861 Southern Methodist
Obsoletes: 1645 October 1995
Category:
Simple Network Paging Protocol - Version 3 - Two-Way
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 wireless messages,
one and two-way, to appropriate receiving devices. In its
form, SNPP provides a simple way to implement a "shim" between
Internet and a TAP/IXO paging terminal. In its level 3 form,
provides an easy-to-use (and build) method for communicating
receiving end-to-end acknowledgments and replies from two-
messaging devices (such as ReFLEX units).
Gateways supporting this protocol, as well as SMTP, have been in
for well over a year at several commercial paging companies,
private businesses. Client software supporting this protocol
become widespread, and is being integrated into many of the
paging and messaging products being built. In addition to
software, email filters and SNPP client software for Unix and
(WikiPage) are available at no cost. Please contact the author
more 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.
With all due apologies to the Glenayre engineers (who take offense
the term "nerd") beepers are as much a part of computer nerdom as X
terminals--perhaps, unfortunately, more. The intent of Simple
Paging Protocol is to provide a standard whereby pages can
delivered to individual paging terminals. The most obvious
is the 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. The benefits of the
Gwinn Informational [Page 1]
RFC 1861 SNPP - Version 3 October 1995
become even more realized when growing towards acknowledgment-
messaging such as ReFLEX paging--where it may be impossible
accurately predict costs associated with telco services such as 1-800
numbers
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
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
The recently-added level three enhancements have been engineered
use, specifically, with acknowledgment-based paging. With the
advances in wireless technology, two-way paging is fast
reality--therefore creating a need for a workable end-to-
acknowledged protocol. Two-way messaging, however, opens up
new areas of unpredictability. The most pronounced is the
response time. Although deliveries from host to subscriber,
subsequent receipt-acknowledgments happen in a rather
manner, it is impossible to know when the subscriber will
pull the unit out, read the message and respond to it. Therefore,
could well be cost prohibitive to conduct such transactions
using a phone line as medium--especially an 800-number. This
the Internet an extremely attractive alternative because of
(generally) usage insensitive nature
However, acknowledging the complexity of task, and flexibility of
current protocols (or the lack thereof), the final user function
quite simple: to deliver a page from point-of-origin to someone'
beeper. That is the simple, real-time function that the
protocol attempts to address
Gwinn Informational [Page 2]
RFC 1861 SNPP - Version 3 October 1995
3. Why not just use Email and SMTP for paging
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
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
Gwinn Informational [Page 3]
RFC 1861 SNPP - Version 3 October 1995
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
following categories
2xx - Successful,
3xx - Begin DATA input (see "DATA" command
4xx - Failed with connection
5xx - Failed, but continue
SNPP version 3 (two-way) adds the following categories
7xx - UNsuccessful two-way specific transaction, but
8xx - Successful two-way specific transaction,
9xx - Successful QUEUED two-way transaction,
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, especially at SNPP level one, is
quite simple (hence the name). The client initiates the
with the listening server. Upon opening the connection, the
issues a "220" level message (indicating the willingness of
server to accept SNPP commands). The client passes pager
information, and a message, then issues a "SEND" command. The
then feeds the information to the paging terminal, gathers
response, and reports the success or failure to the client
4.1 Examples of "simple" SNPP
The following illustrate examples of client-server
using SNPP
Gwinn Informational [Page 4]
RFC 1861 SNPP - Version 3 October 1995
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
SEND -->
<-- 250 Message Sent
QUIT -->
<-- 221 OK,
Gwinn Informational [Page 5]
RFC 1861 SNPP - Version 3 October 1995
4.1.3 A Typical Level Three (two-way)
Level three transactions are inherently single-unit oriented
of the one-to-one issues surrounding responses. Each
begins with the "2WAY" command and terminates with a "SEND" command
Client
Open Connection -->
<-- 220 SNPP (V3) Gateway
2WAY -->
<-- 250 Two-Way Mode
NOQUEUE -->
<-- 250 Msg will either be Sent or
PAGER SHIRLEY -->
<-- 850 Unit online; Don't call me Shirley
ACKRead 1 -->
<-- 250 Read Acknowledgment
DATA -->
<-- 354 Begin Input, End With '.'
Little Bo Binary has lost -->
her Sparcstation and doesn't -->
know where to find it. Have -->
you seen it recently? -->
<-- 250 DATA
RTYPE MULTICHOICE -->
<-- 250 Multichoice Responses
MCRESP 01 In the West Pasture -->
<-- 250 MCR Code
MCRESP 02 GoldiFLOCKs has it -->
<-- 250 MCR Code
MCRESP 03 Haven't a clue -->
<-- 250 MCR Code
MCRESP 04 Haven't a life -->
<-- 250 MCR Code
MCRESP 05 Oh, GO AWAY! -->
<-- 250 MCR Code
SEND -->
<-- 860 00321 1234 Message
QUIT -->
<-- 221 OK,
4.2 General Response Code
Before discussing specific SNPP transactions, it may be helpful
discuss some of the response codes. As mentioned previously,
response from the SNPP server to the client contains a 3 digit
that categorizes the response. Several of these codes fall into
Gwinn Informational [Page 6]
RFC 1861 SNPP - Version 3 October 1995
"general" category, and may occur more frequently throughout a
SNPP transaction. There are some lesser used (somewhat
specific) responses that will be discussed in conjunction with
format of a specific command
4.2.1 Code 214 - Multi-line "help/info"
This code prefixes a line of response information (such as
response to the HELP command). It should be terminated with a "250
OK" message. This code is used when the response will take more
one line to display
4.2.2 Code 218 - Single-line "help/info"
This code prefixes a single line of response information (such as
request for a single database entry). Unlike the 214 series, it
no "250" series terminator
4.2.3 Code 250 - Successful
This code is a general positive acknowledgment from the
indicating that a command was successfully processed. Additionally
code 250 can appear at the end of the response to a HELP command (214
series commands--discussed below).
4.2.4 Code 421 - Fatal Error, Connection
This code is displayed just prior to the SNPP server terminating
connection with a client for errors. Such a connection
may occur at any time and for any reason (administrative
technical).
4.2.5 Code 500 - Command Not
This code is a "fail but continue code" that appears when an
command is entered
4.2.6 Code 503 - Duplicate Command Entry; Already Entered
This code indicates that the specified information has already
entered. This code would appear, for instance, if the
attempted to enter a MESSage command after specifying a "DATA
sequence
4.2.7 Codes 550 and 554 - Transaction Failed, but
These codes indicate a failed command, but the session is allowed
continue. A 550 code should be used to indicate a
Gwinn Informational [Page 7]
RFC 1861 SNPP - Version 3 October 1995
"administrative" failure (such as an invalid pager ID, or
parameter), while a 554 series indicates a more technical
(such as a gateway down or equipment failure). In addition to
specified failure codes, additional 550 and 554 failures may
specified as necessary to allow for greater flexibility
4.2.8 Code 552 - Maximum Entries
This code is in response to the entry of the "n+1" item when
server only permits "n" items in a category. As an example,
client would expect to see this message when trying to enter the 6
PAGEr command when the terminal only supported 5.
4.3 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.3.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
Both level 2 and level 3 enhancements affect the PAGEr command
Please refer to the appropriate section(s) for details
Gwinn Informational [Page 8]
RFC 1861 SNPP - Version 3 October 1995
4.3.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
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.3.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.3.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
Gwinn Informational [Page 9]
RFC 1861 SNPP - Version 3 October 1995
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
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
Level 3 enhancements to this command allow for other responses
Please refer to the appropriate section for discussion
4.3.5
The QUIT command terminates the current session. The server
simply respond
221 OK, Goodbye
and close the connection
4.3.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.4 Level 2 - Minimum
This section specifies minimum enhancements to the SNPP protocol
added functionality
Gwinn Informational [Page 10]
RFC 1861 SNPP - Version 3 October 1995
4.4.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
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.5 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.5.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
Gwinn Informational [Page 11]
RFC 1861 SNPP - Version 3 October 1995
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
421 Illegal Access
550 Error, Invalid LoginID or
554 Error, failed (technical reason
4.5.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, it
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
552 Max Recipients
554 Error, failed (technical reason
4.5.3 LEVEl
The LEVEl function is used to specify an optional alternate level
service for the next PAGEr command. Ideally, "ServiceLevel"
Gwinn Informational [Page 12]
RFC 1861 SNPP - Version 3 October 1995
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
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.5.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
Gwinn Informational [Page 13]
RFC 1861 SNPP - Version 3 October 1995
4.5.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
- 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.5.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
Gwinn Informational [Page 14]
RFC 1861 SNPP - Version 3 October 1995
550 Error, Invalid Delivery Date/
554 Error, failed (technical reason
4.5.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
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.5.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.6 Level 3 - Two-Way
This section specifies enhancements to the SNPP protocol to
acknowledgment-based paging (2-way). One of the more
features of ReFLEX-style paging, in addition to confirmed
delivery, is the ability to "seed" a message with multiple-
type responses. After the recipient views the message, she can
with one of the seeded messages. In addition to the multiple-
responses (MCR's), the sender may elect to receive confirmation
the message is first viewed by the recipient
Gwinn Informational [Page 15]
RFC 1861 SNPP - Version 3 October 1995
4.6.1 2
The 2WAY command prefaces each two-way transaction (see
example). This places the server in the mode to receive and
a single 2-way transaction. The server returns to "non-2WAY"
upon the completion of a SEND command or a RESEt command. In 2
mode, it is, however, possible to do multiple MSTAtus commands (
check responses from field message units). Possible responses are
250 OK, Beginning 2-Way
550 Error, Standard Transaction Already Underway, use
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
4.6.2 PING
This command localizes (finds) the field message unit on the
and returns its location and/or status. Because of the
nature of location information, the subscriber may elect to have
generic "pager located" message (ACLU mode) rather than to return
actual location. Possible responses are
820 Unit On System, This
821 Unit On System, No Location Information Available (ACLU mode
750 Unit Valid But Not Online At This
920 Unit Not Online, But Can Queue Message for Later
550 Can't PING; Unit NOT 2-way
550 Unknown or Illegal
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
4.6.3 EXPTag
Changes the default expiry time for a queued message delivery.
the message is not delivered in the specified number of hours,
it is deleted and the MSTAtus tag is updated to reflect the
to deliver (code 760). Possible responses are
250 Message Expiry Time Changed to 'nnn'
550 Cannot Change Expiry
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
Gwinn Informational [Page 16]
RFC 1861 SNPP - Version 3 October 1995
4.6.4
Specifies that the server should not allow message queuing for
2WAY transaction. In this mode, if a pager is not online, the
will receive a "750" series response to a PAGEr command.
command must be specified prior to a PAGEr command.
responses are
250 Queuing Disabled, This
550 Can't Disable
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
4.6.5 ACKRead <0|1>
Activates or deactivates message "read" acknowledgment.
activated, instructs the field message unit to return a message
the subscriber actually views the received message. This feature
independent of the actual reply. Possible responses are
250 Read Acknowledgment
550 Cannot modify Read
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
4.6.6 RTYPe
Changes the type of reply expected from the field message unit
is acceptable to the client program. Initial appropriate reply
codes are
NONE - (default) No Reply
YESNO - Seeds a simple "Yes" or "No
SIMREPLY - Only pre-coded replies from providers's reply
MULTICHOICE - Allows full multiple choice
TEXT - Allows full text replies (generated by field unit
Possible responses to an RTYPe command are
250 Reply Type
550 Illegal Reply
503 Already Entered
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
Gwinn Informational [Page 17]
RFC 1861 SNPP - Version 3 October 1995
4.6.7 MCREsponse <2-byte_Code> Response_
This command is issued prior the the SEND command, and "seeds"
transaction with an acceptable multiple choice response.
response is specific to the current message. The number
acceptable responses may be limited by the SNPP server as desired
the provider. Examples of MCREsponse(s) are
MCREsponse 1E2C Here is one
MCREsponse 0002 This is another
Responses from the SNPP server to the client are
250 Response Added to
502 Error! Would Duplicate Previously Entered
550 Invalid MCResponse
550 MCResponses Not
552 Too Many MCResponses
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
4.6.8
In 2WAY mode, the following enhanced responses are available
850 Two-Way Unit Online and Available; Transaction
950 Unit NOT Online; Message Will be Queued for Later
750 Two-Way Unit NOT Online; Transaction
550 Error, Pager Not 2WAY
550 Error, RTYPe Mode Invalid for This
503 Already Selected
421 Gateway Service Unavailable (terminate connection
554 Error, failed (technical reason
4.6.9
Instructs the SNPP server to "launch" the message (plus
response codes) to the field message unit. A successful SEND
will return, to the client, a "Message_Tag" number and a "Pass_Code
for periodic status checking. The client then uses the
command to check the progression of the transaction.
"Message_Tag" functions as a "record locator," while the "Pass_Code
should be a randomly generated "PIN" code to authorize checking
the "Message_Tag."
Response codes to a SEND command, as well as the MSTAtus command
indicate the degree of "finality" to the transaction. Based on
Gwinn Informational [Page 18]
RFC 1861 SNPP - Version 3 October 1995
delivery process, there are four categories. Together with
response code prefixes, these are
86x - Initial message delivered, awaiting requested action(s
87x - Intermediate processing completed, awaiting
88x - Transaction concluded (final
96x - Queued
These prefixes make a multi-tiered transaction relatively simple
follow to closure. When an 88x series response code is received
the server, all requested portions of the transaction have
processed, and no further status changes will take place
The SEND command should reply with the first tier of
processing. Following this, the status of the message in the
is checked, periodically, using the MSTAtus command
Possible responses to a SEND command are
860 Delivered, Awaiting Read
861 Delivered, Awaiting Reply (MCR
880 Message
960 OK, Message QUEUED for
550 Delivery Failed! Message destroyed
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
4.6.10 MSTAtus
This is used by a client program to periodically check the status
delivery and response of a given message. The SEND command
the "Message_Tag" and "Pass_Code" required to check the status.
"Message_Tag" may be (should be) expired by the SNPP server after
appropriate amount of time has passed. Expiration of these tags
vendor dependent, and may accelerate after the first check
final disposition of the message (such as after a client program
successfully received the field unit's response code).
The tag record contains a "Sequence" number which is an
counter that rises as the record's status changes (such as from
delivery acknowledgment to a reply). In addition, date and time
the current transaction should be kept in the following format
YYMMDDHHMMSS+GMT (example: 950925143501+7)
Gwinn Informational [Page 19]
RFC 1861 SNPP - Version 3 October 1995
Because of the tiered structure of replies, possible responses to
MSTAtus command are
860 <Sequence> Delivered, Awaiting Read
861 <Sequence> Delivered, Awaiting Reply (MCR
870 <Sequence> Delivered, Read, Awaiting Reply (MCR
880 <Sequence> Message Delivered (No Reply Pending
881 <Sequence> Message Delivered and Read by
888 <Sequence> MCR Reply
889 <Sequence> Response
960 <Sequence> Message Queued; Awaiting
780 <Sequence> MESSAGE EXPIRED Before Delivery
550 Unknown or Illegal Message_Tag or Pass_
421 Gateway Service Unavailable (terminate connection
500 Command Not
554 Error, failed (technical reason
After a closure-series (88x) command has been returned to the client
acceleration of message tag deletion may be desired to maximize
of resources on the server
KTAG
Used to "kill" the message tag after final reading (or when
further responses are desired). This is more of a courtesy
that allows the client to "clean up" rather than wait for the
server to expire the tag
4.7 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,
Gwinn Informational [Page 20]
RFC 1861 SNPP - Version 3 October 1995
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
4.8
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.9 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
Level three enhancements to the protocol have been added
preparation for acknowledgment-based messaging
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'
Gwinn Informational [Page 21]
RFC 1861 SNPP - Version 3 October 1995
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
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 Informational [Page 22]
RFC 1861 SNPP - Version 3 October 1995
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@radio.
Gwinn Informational [Page 23]
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
