diff options
Diffstat (limited to 'doc/rfc/rfc1861.txt')
| -rw-r--r-- | doc/rfc/rfc1861.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc1861.txt b/doc/rfc/rfc1861.txt new file mode 100644 index 0000000..9e953f7 --- /dev/null +++ b/doc/rfc/rfc1861.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group A. Gwinn +Request for Comments: 1861 Southern Methodist University +Obsoletes: 1645 October 1995 +Category: Informational + + + Simple Network Paging Protocol - Version 3 - Two-Way Enhanced + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This RFC suggests a simple way for delivering wireless messages, both + one and two-way, to appropriate receiving devices. In its simplest + form, SNPP provides a simple way to implement a "shim" between the + Internet and a TAP/IXO paging terminal. In its level 3 form, it + provides an easy-to-use (and build) method for communicating and + receiving end-to-end acknowledgments and replies from two-way + messaging devices (such as ReFLEX units). + + Gateways supporting this protocol, as well as SMTP, have been in use + for well over a year at several commercial paging companies, and + private businesses. Client software supporting this protocol has + become widespread, and is being integrated into many of the new + paging and messaging products being built. In addition to commercial + software, email filters and SNPP client software for Unix and Windows + (WikiPage) are available at no cost. Please contact the author for + more information. + + Earlier versions of this specification were reviewed by IESG members + and the "822 Extensions" Working Group. They preferred an alternate + strategy, as discussed under "Relationship to Other IETF Work", + below. + +1. Introduction + + With all due apologies to the Glenayre engineers (who take offense at + the term "nerd") 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 and phone lines to produce + alphanumeric pages, and the added ease of delivery of pages to + terminals in other cities or countries. The benefits of the Internet + + + +Gwinn Informational [Page 1] + +RFC 1861 SNPP - Version 3 October 1995 + + + become even more realized when growing towards acknowledgment-based + messaging such as ReFLEX paging--where it may be impossible to + accurately predict costs associated with telco services such as 1-800 + numbers. + +2. 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. + + Even though TAP is widely used throughout the industry, there are + plans on the table to move to a more flexible "standard" protocol + referred to as TME (Telocator Message Entry Protocol). The level two + enhancements to SNPP (as described below) are intended for use with + this forthcoming standard. + + The recently-added level three enhancements have been engineered for + use, specifically, with acknowledgment-based paging. With the recent + advances in wireless technology, two-way paging is fast approaching + reality--therefore creating a need for a workable end-to-end + acknowledged protocol. Two-way messaging, however, opens up several + new areas of unpredictability. The most pronounced is the subscriber + response time. Although deliveries from host to subscriber, and + subsequent receipt-acknowledgments happen in a rather predictable + manner, it is impossible to know when the subscriber will physically + pull the unit out, read the message and respond to it. Therefore, it + could well be cost prohibitive to conduct such transactions online + using a phone line as medium--especially an 800-number. This makes + the Internet an extremely attractive alternative because of its + (generally) usage insensitive nature. + + However, acknowledging the complexity of task, 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, real-time function that the base + 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 of + this is deferred messaging when a gateway is down. Suppose Mary Ghoti + (fish@hugecompany.org) sends a message to Zaphod Beeblebrox's beeper + (5551212@pager.pagingcompany.com). Hugecompany's gateway to the + Internet is down causing Mary's message to be deferred. Mary, + however, is not notified of this delay because her message has not + actually failed to reach its destination. Three hours later, the + link is restored, and (as soon as sendmail wakes up) the message is + sent. Obviously, if Mary's page concerned a meeting that was + supposed to happen 2 hours ago, there will be some minor + administrative details to work out between Mary and Zaphod! + + On the other hand, if Mary had used her SNPP client (or simply + telnetted to the SNPP gateway), she would have immediately discovered + the network problem. She would have decided to invoke plan "B" and + call Zaphod's pager on the telephone, ringing him that way. + + The obvious difference here is not page delivery, but the immediate + notification of a problem that affects your message. Standard email + and SMTP, while quite reliable in most cases, cannot be positively + guaranteed between all nodes at all times, making it less desirable + for emergency or urgent paging. This inability to guarantee delivery + could, whether rightly or wrongly, place the service provider in an + uncomfortable position with a client who has just received his or her + emergency page, six hours too late. + + Another advantage of using a separate protocol for paging delivery is + that it gives the sender absolute flexibility over what is sent to + the pager. For instance, in the paging arena, where messages are + sent to alphanumeric pagers, it is less desirable to send the + recipient general header lines from a standard SMTP message. Much of + the information is useless, possibly redundant, and a waste of + precious RF bandwidth. + + Therefore, when implementing an SMTP gateway, the service provider + should elect to parse out needed information (such as the sender, and + possibly subject) such to maximize the utility of the transmission. + Parsing generally means less control over content and format by the + message originator. SNPP provides a clean, effective way to send a + message, as written, to the recipient's pager. + + The other consideration is the relative simplicity of the SNPP + protocol for manual telnet sessions versus someone trying to manually + hack a mail message into a gateway. + + + + + +Gwinn Informational [Page 3] + +RFC 1861 SNPP - Version 3 October 1995 + + +4. The SNPP 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 several input commands (the first 4 characters of each are + significant) that solicit various server responses falling into the + following categories: + + 2xx - Successful, continue + 3xx - Begin DATA input (see "DATA" command) + 4xx - Failed with connection terminated + 5xx - Failed, but continue session + + SNPP version 3 (two-way) adds the following categories: + + + 7xx - UNsuccessful two-way specific transaction, but continue + session + 8xx - Successful two-way specific transaction, continue + 9xx - Successful QUEUED two-way transaction, continue + + The first character of every server response code is a digit + indicating the category of response. The text portion of the + response following the code may be altered to suit individual + applications. + + The session interaction, especially at SNPP level one, is actually + quite simple (hence the name). The client initiates the connection + with the listening server. Upon opening the connection, the server + issues a "220" level message (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 paging terminal, gathers a + response, and reports the success or failure to the client. + +4.1 Examples of "simple" SNPP Transactions + + The following illustrate examples of client-server communication + using SNPP. + + + + + + + + + + + + +Gwinn Informational [Page 4] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.1.1 A Typical Level One Connection + + Client Server + + Open Connection --> + <-- 220 SNPP Gateway Ready + PAGE 5551212 --> + <-- 250 Pager ID Accepted + MESS Your network is hosed --> + <-- 250 Message OK + SEND --> + <-- 250 Message Sent OK + QUIT --> + <-- 221 OK, Goodbye + +4.1.2 A Typical Level Two, Multiple Transaction + + The following example illustrates a single message sent to two + pagers. Using this level protocol, pager-specific options may be + selected for each receiver by specifying the option prior to issuing + the "PAGEr" command. In this example, an alternate coverage area is + selected for the first pager, while delayed messaging is specified + for the second. + + Client Server + + Open Connection --> + <-- 220 SNPP Server Ready + COVE 2 --> + <-- 250 Alternate Area Selected + PAGE 5551212 FOOBAR --> + <-- 250 Pager ID Accepted + HOLD 9401152300 -0600 --> + <-- 250 Delayed Message OK + PAGE 5552323 XYZZY --> + <-- 250 Pager ID Accepted + SUBJ Seattle Meeting --> + <-- 250 Message Subject OK + DATA --> + <-- 354 Begin Input, End With '.' + Please meet me tomorrow at --> + the Seattle office --> + <-- 250 DATA Accepted + SEND --> + <-- 250 Message Sent OK + QUIT --> + <-- 221 OK, Goodbye + + + + +Gwinn Informational [Page 5] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.1.3 A Typical Level Three (two-way) Transaction + + Level three transactions are inherently single-unit oriented because + of the one-to-one issues surrounding responses. Each transaction + begins with the "2WAY" command and terminates with a "SEND" command. + + Client Server + +Open Connection --> + <-- 220 SNPP (V3) Gateway Ready +2WAY --> + <-- 250 Two-Way Mode Enabled +NOQUEUE --> + <-- 250 Msg will either be Sent or Rejected +PAGER SHIRLEY --> + <-- 850 Unit online; Don't call me Shirley! +ACKRead 1 --> + <-- 250 Read Acknowledgment Requested +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 Accepted +RTYPE MULTICHOICE --> + <-- 250 Multichoice Responses Enabled +MCRESP 01 In the West Pasture --> + <-- 250 MCR Code Accepted +MCRESP 02 GoldiFLOCKs has it --> + <-- 250 MCR Code Accepted +MCRESP 03 Haven't a clue --> + <-- 250 MCR Code Accepted +MCRESP 04 Haven't a life --> + <-- 250 MCR Code Accepted +MCRESP 05 Oh, GO AWAY! --> + <-- 250 MCR Code Accepted +SEND --> + <-- 860 00321 1234 Message Delivered +QUIT --> + <-- 221 OK, Goodbye + +4.2 General Response Code Theory + + Before discussing specific SNPP transactions, it may be helpful to + discuss some of the response codes. As mentioned previously, every + response from the SNPP server to the client contains a 3 digit code + that categorizes the response. Several of these codes fall into the + + + +Gwinn Informational [Page 6] + +RFC 1861 SNPP - Version 3 October 1995 + + + "general" category, and may occur more frequently throughout a given + SNPP transaction. There are some lesser used (somewhat transaction + specific) responses that will be discussed in conjunction with the + format of a specific command. + +4.2.1 Code 214 - Multi-line "help/info" message + + This code prefixes a line of response information (such as in + response to the HELP command). It should be terminated with a "250 + OK" message. This code is used when the response will take more than + one line to display. + +4.2.2 Code 218 - Single-line "help/info" message + + This code prefixes a single line of response information (such as the + request for a single database entry). Unlike the 214 series, it has + no "250" series terminator. + +4.2.3 Code 250 - Successful Transaction + + This code is a general positive acknowledgment from the server + 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 Terminated + + This code is displayed just prior to the SNPP server terminating a + connection with a client for errors. Such a connection termination + may occur at any time and for any reason (administrative or + technical). + +4.2.5 Code 500 - Command Not Implemented + + This code is a "fail but continue code" that appears when an illegal + command is entered. + +4.2.6 Code 503 - Duplicate Command Entry; Already Entered That + + This code indicates that the specified information has already been + entered. This code would appear, for instance, if the client + attempted to enter a MESSage command after specifying a "DATA" + sequence. + +4.2.7 Codes 550 and 554 - Transaction Failed, but Continue + + These codes indicate a failed command, but the session is allowed to + continue. A 550 code should be used to indicate a more + + + +Gwinn Informational [Page 7] + +RFC 1861 SNPP - Version 3 October 1995 + + + "administrative" failure (such as an invalid pager ID, or illegal + parameter), while a 554 series indicates a more technical reason + (such as a gateway down or equipment failure). In addition to the + specified failure codes, additional 550 and 554 failures may be + specified as necessary to allow for greater flexibility. + +4.2.8 Code 552 - Maximum Entries Exceeded + + This code is in response to the entry of the "n+1" item when the + server only permits "n" items in a category. As an example, the + client would expect to see this message when trying to enter the 6th + PAGEr command when the terminal only supported 5. + +4.3 Level 1 Commands + + Level one commands are designed as a minimum implementation of the + protocol. This collection of commands may be used with either + TAP/IXO or TME for message delivery to the paging terminal. + +4.3.1 PAGEr <Pager ID> + + The PAGEr command submits a pager ID (PID) number, for inclusion in + the next messaging transaction. The PID used must reside in, and be + validated by the paging terminal. Limited validation may optionally + be done on the server (such as all numeric, and ID length), or + validation can be left up to the terminal at the time the page is + sent. + + When implementing SNPP, the user may elect to support multiple + recipients per message sent. However, be wary that validation- + prior-to-sending is not possible with TAP/IXO (and is not an official + option of the current TME specification). What this means is that in + order to validate a PID, one must generate a message to the pager. + The terminal responds favorably or negatively. When reporting + failure of a single PID in a sequence, delineating and reporting the + failure in a "standard format" may prove to be a challenge. + + Possible responses from the SNPP server, with suggested text, in + response to a PAGEr command are: + + 250 Pager ID Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 550 Error, Invalid Pager ID + 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 <Alpha or Numeric Message> + + The MESSage command specifies a single-line message, 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 by the paging terminal. Duplicating the MESSage command before + SENDing the message should produce an "503 ERROR, Message Already + Entered" message, and allow the user to continue. + + Possible responses from the SNPP server, with suggested text, in + response to a MESSage command are: + + 250 Message OK + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 503 ERROR, Message Already Entered + 550 ERROR, Invalid Message + 554 Error, failed (technical reason) + +4.3.3 RESEt + + The RESEt command clears already entered information from the server + session, resetting it to the state of a freshly opened connection. + This is provided, primarily, as a means to reset accidentally entered + information during a manual session. + + Possible responses from the SNPP server, with suggested text, in + response to a RESEt command are: + + 250 RESET OK + 421 Too Many Errors, Goodbye (terminate connection + 421 Gateway Service Unavailable (terminate connection) + +4.3.4 SEND + + The SEND command finalizes the current message transaction, and + processes the page to the paging terminal. Prior to processing, the + PAGEr and MESSage fields (or message DATA when using the level two + option) should be checked for the existence of information. Should + one of these required fields be missing, the server should respond + "503 Error, Incomplete Information" and allow the user to continue. + Assuming that the information is complete, the SNPP server should + format and send the page to the paging terminal, and await a + response. + + Possible responses from the SNPP server, with suggested text, in + response to a SEND command are: + + + + +Gwinn Informational [Page 9] + +RFC 1861 SNPP - Version 3 October 1995 + + + 250 Message Sent Successfully + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 503 Error, Pager ID or Message Incomplete + 554 Message Failed [non-administrative reason] + + Or, in the case of an illegal or non-existent pager ID, or some other + administrative reason for rejecting the page, the server should + respond: + + 550 Failed, Illegal Pager ID (or other explanation) + + After processing a SEND command, the server should remain online to + 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 QUIT + + The QUIT command terminates the current session. The server should + simply respond: + + 221 OK, Goodbye" + + and close the connection. + +4.3.6 HELP (optional) + + The optional HELP command displays a screen of information about + commands that are valid on the SNPP server. This is primarily to + assist manual users of the gateway. Each line of the HELP screen + (responses) are preceded by a code "214". At the end of the HELP + sequence, a "250" series message is issued. + + Possible responses from the SNPP server, with suggested text, in + response to a HELP command are: + + 214 [Help Text] (repeated for each line of information) + 250 End of Help Information + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + +4.4 Level 2 - Minimum Extensions + + This section specifies minimum enhancements to the SNPP protocol for + added functionality. + + + +Gwinn Informational [Page 10] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.4.1 DATA + + The DATA command is an alternate form of the MESSage command, + allowing for multiple line delivery of a message to the paging + terminal. This command's function is similar to the DATA command + implemented in SMTP (Internet STD10, RFC821). The SNPP server should + only allow one DATA or MESSage command to be issued prior to a SEND. + + Possible responses from the SNPP server, with suggested text, in + response to a DATA command are: + + 354 Begin Input; End with <CRLF>'.'<CRLF> + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 503 ERROR, Message Already Entered + 500 Command Not Implemented + 550 ERROR, failed (administrative reason) + 554 ERROR, failed (technical reason) + + Upon receiving a "354" response, the client begins line input of the + message to send to the pager. A single period ("."), in the first + position of the line, terminates input. After input, the server may + respond: + + 250 Message OK + 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 Extensions + + This section discusses enhancements to the SNPP protocol for more + control over paging functions. These are primarily designed to + mirror the added functionality built into the Telocator Message Entry + (TME) protocol as specified in the TDP protocol suite. These + functions may, optionally (as is being done by the author), be + integrated into a paging terminal. There is no requirement to + implement all of these functions. Requests for invalid functions + should return a "500 Function Not Implemented" error. + + It is important to note that, at the time of this publication, the + TME standard is still not finalized. + +4.5.1 LOGIn <loginid> [password] + + This command allows for a session login ID to be specified. It is + 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, in + response to a LOGIn command are: + + 250 Login Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 421 Illegal Access Attempt + 550 Error, Invalid LoginID or Password + 554 Error, failed (technical reason) + +4.5.2 PAGEr <PagerID> [Password/PIN] + + This PAGEr command is an enhancement to the level one specification. + The primary difference is the ability to specify a password or PIN + for validation or feature access. + + Before proceeding, it is important to understand the logical function + of the PAGEr command with respect to the LEVEl, COVErage, HOLDtime, + and ALERt commands (option parameters as described below). Each time + a PAGEr command is issued, it should be thought of as the last step + in a multiple step transaction. + + When the PAGEr command is processed, the pager ID (and password) is + submitted to the paging terminal with LEVEl, COVErage, HOLDtime, and + ALERt. If these parameters have not been altered, then their + defaults are assumed for the transaction. After the next PAGEr + command has been processed, these option parameters are reset their + defaults. Using this type of "option-option-option-go" scheme, it is + possible to specify a different priority level for "Jeff," and an + alternate coverage area for "Kathy," while sending the same message + to each. + + Possible responses from the SNPP server, with suggested text, in + response to a PAGEr command are: + + 250 Pager ID Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 550 Error, Invalid Pager ID or Password + 552 Max Recipients Exceeded + 554 Error, failed (technical reason) + +4.5.3 LEVEl <ServiceLevel> + + The LEVEl function is used to specify an optional alternate level of + service for the next PAGEr command. Ideally, "ServiceLevel" should + + + +Gwinn Informational [Page 12] + +RFC 1861 SNPP - Version 3 October 1995 + + + be an integer between 0 and 11 inclusive. The TME protocol specifies + ServiceLevel as follows: + + 0 - Priority + 1 - Normal (default) + 2 - Five minutes + 3 - Fifteen minutes + 4 - One hour + 5 - Four hours + 6 - Twelve hours + 7 - Twenty Four hours + 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 it + should be implemented, should be optional and up to the discretion of + the carrier. + + Possible responses from the SNPP server, with suggested text, in + response to a LEVEl command are: + + 250 OK, Alternate Service Level Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 550 Error, Invalid Service Level Specified + 554 Error, failed (technical reason) + +4.5.4 ALERt <AlertOverride> + + The optional ALERt command may be used to override the default + setting and specify whether or not to alert the subscriber upon + receipt of a message. This option, like the previous command, alters + the parameters submitted to the paging terminal using the PAGEr + command. The TME protocol specifies AlertOverride as either 0- + DoNotAlert, or 1-Alert. + + Possible responses from the SNPP server, with suggested text, in + response to a ALERt command are: + + 250 OK, Alert Override Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 550 Error, Invalid Alert Parameter + 554 Error, failed (technical reason) + + + +Gwinn Informational [Page 13] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.5.5 COVErage <AlternateArea> + + The optional COVErage command is used to override the subscriber's + default coverage area, and allow for the selection of an alternate + region. This option, like the previous command, alters the + parameters submitted to the paging terminal using the PAGEr command. + AlternateArea is a designator for one of the following: + + - A subscriber-specific alternate coverage area + - A carrier-defined region available to subscribers + + As an example, Mary Ghoti is a subscriber having local service in + Chicago, Illinois (Mary's region '1'). Her account has been set up + in such a manner as to allow Mary's pager to be paged nationwide upon + demand (Mary's region '2'). Specifying "COVErage 2" prior to issuing + the appropriate "PAGEr" command allows the default Chicago area to be + overridden, and Mary's pager to be messaged nationally for that + transaction. It is assumed that the carrier providing Mary's service + will keep track of how many pages have been sent to her pager in this + manner, and will bill her accordingly. + + Possible responses from the SNPP server, with suggested text, in + response to a COVErage command are: + + 250 Alternate Coverage Selected + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 550 Error, Invalid Alternate Region + 554 Error, failed (technical reason) + +4.5.6 HOLDuntil <YYMMDDHHMMSS> [+/-GMTdifference] + + The HOLDuntil command allows for the delayed delivery of a message, + to a particular subscriber, until after the time specified. The time + may be specified in local time (e.g. local to the paging terminal), + or with an added parameter specifying offset from GMT (in other + words, "-0600" specifies Eastern Standard Time). This option, like + the previous command, alters the parameters submitted to the paging + terminal using the PAGEr command. + + Possible responses from the SNPP server, with suggested text, in + response to a HOLDuntil command are: + + 250 Delayed Messaging Selected + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + + + +Gwinn Informational [Page 14] + +RFC 1861 SNPP - Version 3 October 1995 + + + 550 Error, Invalid Delivery Date/Time + 554 Error, failed (technical reason) + +4.5.7 CALLerid <CallerID> + + The CALLerid function is a message-oriented function (as opposed to + the subscriber-oriented functions just described). This allows for + the specification of the CallerIdentifier function as described in + TME. This parameter is optional, and is at the discretion of the + carrier as to how it should be implemented or used. + + Possible responses from the SNPP server, with suggested text, in + response to a CALLerid command are: + + 250 Caller ID Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 550 Error, Invalid Caller ID + 554 Error, failed (technical reason) + +4.5.8 SUBJect <MessageSubject> + + The SUBJect function allows is a message-oriented function that + allows the sender to specify a subject for the next message to be + sent. This parameter is optional and is at the discretion of the + carrier as to how it should be implemented or used. + + Possible responses from the SNPP server, with suggested text, in + response to a SUBJect command are: + + 250 Message Subject Accepted + 421 Too Many Errors, Goodbye (terminate connection) + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 550 Error, Invalid Subject Option + 554 Error, failed (technical reason) + +4.6 Level 3 - Two-Way Extensions + + This section specifies enhancements to the SNPP protocol to support + acknowledgment-based paging (2-way). One of the more powerful + features of ReFLEX-style paging, in addition to confirmed message + delivery, is the ability to "seed" a message with multiple-choice + type responses. After the recipient views the message, she can reply + with one of the seeded messages. In addition to the multiple-choice + responses (MCR's), the sender may elect to receive confirmation when + the message is first viewed by the recipient. + + + +Gwinn Informational [Page 15] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.6.1 2WAY + + The 2WAY command prefaces each two-way transaction (see previous + example). This places the server in the mode to receive and process + a single 2-way transaction. The server returns to "non-2WAY" mode + upon the completion of a SEND command or a RESEt command. In 2WAY + mode, it is, however, possible to do multiple MSTAtus commands (to + check responses from field message units). Possible responses are: + + 250 OK, Beginning 2-Way Transaction + 550 Error, Standard Transaction Already Underway, use RESEt + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + + 4.6.2 PING <PagerID | Alias> + + This command localizes (finds) the field message unit on the system + and returns its location and/or status. Because of the sensitive + nature of location information, the subscriber may elect to have a + generic "pager located" message (ACLU mode) rather than to return her + actual location. Possible responses are: + + 820 <Locus_Code> Unit On System, This Area + 821 Unit On System, No Location Information Available (ACLU mode) + 750 Unit Valid But Not Online At This Time + 920 Unit Not Online, But Can Queue Message for Later Delivery + 550 Can't PING; Unit NOT 2-way capable + 550 Unknown or Illegal ID + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + +4.6.3 EXPTag <hours> + + Changes the default expiry time for a queued message delivery. If + the message is not delivered in the specified number of hours, then + it is deleted and the MSTAtus tag is updated to reflect the inability + to deliver (code 760). Possible responses are: + + 250 Message Expiry Time Changed to 'nnn' Hours + 550 Cannot Change Expiry Time + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + + + + + + +Gwinn Informational [Page 16] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.6.4 NOQUEUEing + + Specifies that the server should not allow message queuing for this + 2WAY transaction. In this mode, if a pager is not online, the client + will receive a "750" series response to a PAGEr command. This + command must be specified prior to a PAGEr command. Possible + responses are: + + 250 Queuing Disabled, This Transaction + 550 Can't Disable Queueing + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + +4.6.5 ACKRead <0|1> + + Activates or deactivates message "read" acknowledgment. When + activated, instructs the field message unit to return a message when + the subscriber actually views the received message. This feature is + independent of the actual reply. Possible responses are: + + 250 Read Acknowledgment <Enabled|Disabled> + 550 Cannot modify Read Acknowledgment + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + +4.6.6 RTYPe <Reply_Type_Code> + + Changes the type of reply expected from the field message unit that + is acceptable to the client program. Initial appropriate reply type + codes are: + + NONE - (default) No Reply Permitted + YESNO - Seeds a simple "Yes" or "No reply + SIMREPLY - Only pre-coded replies from providers's reply base + MULTICHOICE - Allows full multiple choice replies + TEXT - Allows full text replies (generated by field unit) + + Possible responses to an RTYPe command are: + + 250 Reply Type Accepted + 550 Illegal Reply Type + 503 Already Entered That + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + + + + +Gwinn Informational [Page 17] + +RFC 1861 SNPP - Version 3 October 1995 + + +4.6.7 MCREsponse <2-byte_Code> Response_Text + + This command is issued prior the the SEND command, and "seeds" the + transaction with an acceptable multiple choice response. Each + response is specific to the current message. The number of + acceptable responses may be limited by the SNPP server as desired by + the provider. Examples of MCREsponse(s) are: + + MCREsponse 1E2C Here is one response + MCREsponse 0002 This is another response + + Responses from the SNPP server to the client are: + + 250 Response Added to Transaction + 502 Error! Would Duplicate Previously Entered MCResponse + 550 Invalid MCResponse Code + 550 MCResponses Not Enabled + 552 Too Many MCResponses Entered + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + +4.6.8 PAGEr + + In 2WAY mode, the following enhanced responses are available: + + 850 Two-Way Unit Online and Available; Transaction Accepted + 950 Unit NOT Online; Message Will be Queued for Later Delivery + 750 Two-Way Unit NOT Online; Transaction Denied + 550 Error, Pager Not 2WAY Capable + 550 Error, RTYPe Mode Invalid for This Unit + 503 Already Selected PAGEr + 421 Gateway Service Unavailable (terminate connection) + 554 Error, failed (technical reason) + +4.6.9 SEND + + Instructs the SNPP server to "launch" the message (plus attached + response codes) to the field message unit. A successful SEND command + will return, to the client, a "Message_Tag" number and a "Pass_Code" + for periodic status checking. The client then uses the MSTAtus + command to check the progression of the transaction. The + "Message_Tag" functions as a "record locator," while the "Pass_Code" + should be a randomly generated "PIN" code to authorize checking of + 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 the + + + +Gwinn Informational [Page 18] + +RFC 1861 SNPP - Version 3 October 1995 + + + delivery process, there are four categories. Together with their + response code prefixes, these are: + + 86x - Initial message delivered, awaiting requested action(s) + 87x - Intermediate processing completed, awaiting closure + 88x - Transaction concluded (final) + 96x - Queued transaction + These prefixes make a multi-tiered transaction relatively simple to + follow to closure. When an 88x series response code is received from + the server, all requested portions of the transaction have been + processed, and no further status changes will take place. + + The SEND command should reply with the first tier of message + processing. Following this, the status of the message in the system + is checked, periodically, using the MSTAtus command. + + Possible responses to a SEND command are: + + 860 <Message_Tag> <Pass_Code> Delivered, Awaiting Read Ack + 861 <Message_Tag> <Pass_Code> Delivered, Awaiting Reply (MCR) + + 880 <Message_Tag> <Pass_Code> Message Delivered + + 960 <Message_Tag> <Pass_Code> OK, Message QUEUED for Delivery + + 550 Delivery Failed! Message destroyed. + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 554 Error, failed (technical reason) + +4.6.10 MSTAtus <Message_Tag> <Pass_Code> + + This is used by a client program to periodically check the status of + delivery and response of a given message. The SEND command returns + the "Message_Tag" and "Pass_Code" required to check the status. A + "Message_Tag" may be (should be) expired by the SNPP server after an + appropriate amount of time has passed. Expiration of these tags is + vendor dependent, and may accelerate after the first check after + final disposition of the message (such as after a client program has + successfully received the field unit's response code). + + The tag record contains a "Sequence" number which is an incremental + counter that rises as the record's status changes (such as from a + delivery acknowledgment to a reply). In addition, date and time of + 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 an + MSTAtus command are: + + 860 <Sequence> <Date&Time> Delivered, Awaiting Read Confirmation + 861 <Sequence> <Date&Time> Delivered, Awaiting Reply (MCR) + + 870 <Sequence> <Date&Time> Delivered, Read, Awaiting Reply (MCR) + + 880 <Sequence> <Date&Time> Message Delivered (No Reply Pending) + 881 <Sequence> <Date&Time> Message Delivered and Read by Recipient + 888 <Sequence> <Date&Time> <Reply_Code> MCR Reply Received + 889 <Sequence> <Date&Time> <Full_Text_Response> + + 960 <Sequence> <Date&Time> Message Queued; Awaiting Delivery + + 780 <Sequence> <Date&Time> MESSAGE EXPIRED Before Delivery! + + 550 Unknown or Illegal Message_Tag or Pass_Code + 421 Gateway Service Unavailable (terminate connection) + 500 Command Not Implemented + 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 use + of resources on the server. + +KTAG <Message_Tag> <Pass_Code> + + Used to "kill" the message tag after final reading (or when no + further responses are desired). This is more of a courtesy feature + that allows the client to "clean up" rather than wait for the SNPP + server to expire the tag. + +4.7 Illegal Commands + + Should the client issue an illegal command, the server may respond in + one of the two following ways: + + 421 Too Many Errors, Goodbye (terminate connection) + 500 Command Not Implemented, Try Again + + The number of illegal commands allowed before terminating the + connection should be at the discretion of the operator of the SNPP + server. The only response that has not been discussed is: + + 421 SERVER DOWN, Goodbye + + + + + +Gwinn Informational [Page 20] + +RFC 1861 SNPP - Version 3 October 1995 + + + This is used to refuse or terminate connections when the gateway is + administratively down, or when there is some other technical or + administrative problem with the paging terminal. + +4.8 Timeouts + + The SNPP server can, optionally, have an inactivity timeout + implemented. At the expiration of the allotted time, the server + responds "421 Timeout, Goodbye" and closes the connection. + +4.9 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 to suit + the tastes of the operator of the SNPP server. It is suggested that + the response codes mirror SMTP response codes as closely as possible. + +5. Revision History + + Originally, when proposed, the author employed POP2 style + result/response codes. The Internet community suggested that this + '+' and '-' style theory be altered to provide numeric response codes + -- similar to those used in other services such as SMTP. The + protocol has been altered to this specification from the first + proposed draft. + + Administrative errors (Illegal Pager ID, for example) have been + separated from technical errors (out-of-space on disk, for example). + Administrative failures are generally preceded with a 550 series + response, while technical failures bear a 554 series code. + + Level two enhancements to the protocol have been added in preparation + for TME deployment. + + Level three enhancements to the protocol have been added in + preparation for acknowledgment-based messaging. + + Error code "502 Command not implemented" was changed to a general + "500 Command not recognized" failure result to closer follow SMTP. + +6. Relationship to Other IETF Work + + The strategy of this specification, and many of its details, were + reviewed by an IETF Working Group and three IESG members. They + concluded that an approach using the existing email infrastructure + was preferable, due in large measure to the very high costs of + deploying a new protocol and the advantages of using the Internet's + + + +Gwinn Informational [Page 21] + +RFC 1861 SNPP - Version 3 October 1995 + + + most widely-distributed applications protocol infrastructure. Most + reviewers felt that no new protocol was needed at all because the + special "deliver immediately or fail" requirements of SNPP could be + accomplished by careful configuration of clients and servers. The + experimental network printing protocol [4] was identified as an + example of an existing infrastructure approach to an existing + problem. Other reviewers believed that a case could be made for new + protocol details to identify paging clients and servers to each other + and negotiate details of the transactions, but that it would be + sensible to handle those details as extensions to SMTP [1, 2] rather + than deploying a new protocol structure. + + The author, while recognizing these positions, believes that there is + merit in a separate protocol to isolate details of TAP/IXO and its + evolving successors from users and, indeed, from mail-based + approaches that might reach systems that would act as SMTP/MIME [3] + to SNPP gateways. Such systems and gateways are, indeed, undergoing + design and development concurrent with this work. See the section + "Why not just use Email and SMTP?" for additional discussion of the + author's view of the classical electronic email approach. + +7. References + + [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 Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, Bellcore, + Innosoft, September 1993. + + [4] Rose, M., and C. Malamud, "An Experiment in Remote Printing", RFC + 1486, Dover Beach Consulting, Inc., Internet Multicasting + Service, July 1993. + + + + + + + + + + + + +Gwinn Informational [Page 22] + +RFC 1861 SNPP - Version 3 October 1995 + + +8. Security Considerations + + Security issues are not discussed in this memo. + +9. 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@radio.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gwinn Informational [Page 23] + |