RFC 1861
Simple Network Paging Protocol - Version 3 -Two-Way Enhanced
RFC 1861 is titled Simple Network Paging Protocol - Version 3 - Two-Way Enhanced 📟✨. It's from the Network Working Group, written by A. Gwinn of Southern Methodist University, dated October 1995, and filed as Informational 💅. It obsoletes RFC 1645 🫶. This is part 1 of 4, so let's go 🎀
Status of this Memo ✨
Okay so this memo just provides information for the Internet community 💖. It does not specify an Internet standard of any kind 🙈. Distribution of this memo is unlimited 🌈.
Abstract 🦋
So this RFC suggests a simple way to deliver wireless messages, both one-way and two-way, to the right receiving devices 📟. In its simplest form, SNPP gives you a simple way to build a "shim" between the Internet and a TAP/IXO paging terminal 🧚. In its level 3 form, it gives you an easy-to-use (and build) method for sending and receiving end-to-end acknowledgments and replies from two-way messaging devices, like ReFLEX units 🔥.
Gateways supporting this protocol, plus SMTP, have been running for well over a year at several commercial paging companies and private businesses 💅. Client software for it has gotten super widespread and is being plugged into a ton of new paging and messaging products 👑. On top of the commercial stuff, email filters and SNPP client software for Unix and Windows (WikiPage) are available at no cost 🍓. Contact the author for more info 🫶.
Earlier versions of this spec 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 way for pages to be delivered to individual paging terminals ✨. The most obvious benefit is no more modems and phone lines just to produce alphanumeric pages 📞, plus way easier delivery of pages to terminals in other cities or countries 🌍. The benefits of the Internet get even more realized as we grow toward acknowledgment-based messaging like ReFLEX paging--where it may be impossible to accurately predict costs for telco services like 1-800 numbers 💸.
2. System Philosophy 💖
Radio paging is kinda taken for granted because paging products are everywhere 📟. But the actual delivery of the page, and the process behind it (especially in wider area paging), is pretty complicated 🌀. When a user starts a page, by dialing a number on a telephone or entering an alphanumeric page through some input device, the page must ultimately get delivered to some paging terminal, somewhere 🗺️. Most of the time that delivery is made using TAP (Telocator Alphanumeric input Protocol, also known as IXO) 📨. This protocol can be a bit convoluted and complicated 😭, using older-style ASCII control characters and a non-standard checksumming routine to help validate the data 🧮.
Even though TAP is widely used across the industry, there are plans on the table to move to a more flexible "standard" protocol called TME (Telocator Message Entry Protocol) 🌸. The level two enhancements to SNPP (described below) are meant for use with this upcoming standard ✨.
The recently-added level three enhancements were engineered specifically for acknowledgment-based paging 💅. With recent wireless advances, two-way paging is fast approaching reality, which creates a need for a workable end-to-end acknowledged protocol 🦋. Two-way messaging, though, opens up several new areas of unpredictability 🙈. The most pronounced is the subscriber response time. Deliveries from host to subscriber, and the receipt-acknowledgments that follow, happen in a rather predictable way, but it's impossible to know when the subscriber will physically pull the unit out, read the message and respond to it 🫠. So it could be cost prohibitive to conduct these transactions online over a phone line, especially an 800-number 💸. That makes the Internet an extremely attractive alternative because of its (generally) usage insensitive nature 🌐.
However, acknowledging the complexity of the task, and the flexibility of the current protocols (or the lack thereof), the final user function is quite simple: deliver a page from point-of-origin to someone's beeper 📟✨. That's the simple, real-time function the base protocol attempts to address 💜.
3. Why not just use Email and SMTP for paging? 🤔
Email, while quite reliable, is not always timely 🐢. A good example 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, isn't notified of this delay because her message hasn't 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 could 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 them 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 that 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) so as 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 how simple SNPP is for manual telnet sessions versus someone trying to manually hack a mail message into a gateway 🎀.
4. The SNPP Protocol 📟
SNPP is a sequence of commands and replies, and it's based on the same philosophy as lots of other Internet protocols in use today 💜. SNPP has several input commands (the first 4 characters of each are significant) that solicit various server responses, falling into these categories:
2xx - Successful, continue
3xx - Begin DATA input (see "DATA" command)
4xx - Failed with connection terminated
5xx - Failed, but continue sessionSNPP version 3 (two-way) adds these categories too:
7xx - UNsuccessful two-way specific transaction, but continue
session
8xx - Successful two-way specific transaction, continue
9xx - Successful QUEUED two-way transaction, continueThe 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 🌸.
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, Goodbye4.1.2 A Typical Level Two, Multiple Transaction
The following example illustrates a single message sent to two pagers. Using this level of the 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, Goodbye4.1.3 A Typical Level Three (two-way) Transaction ✨
okay so level three transactions are inherently single-unit oriented 🫶 because of the one-to-one issues around responses. every transaction starts with the 2WAY command and ends with a SEND command. here's how it plays out 💅
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, Goodbye4.2 General Response Code Theory 🌸
before we get into specific SNPP transactions, it's helpful to talk about some of the response codes 🧚 as mentioned earlier, every response from the SNPP server to the client has a 3 digit code that sorts the response into a category. several of these codes are "general" ones and can show up a lot during one SNPP transaction. there are also some less common, more transaction-specific responses, and we'll cover those alongside the format of the specific command they belong to.
4.2.1 Code 214 - Multi-line "help/info" message 💜
this code goes in front of each line of response info (like the reply to the HELP command). it should be ended with a "250 OK" message. you use it when the response needs more than one line to display.
4.2.2 Code 218 - Single-line "help/info" message 🦋
this code goes in front of a single line of response info (like the reply when you ask for one database entry). unlike the 214 series, it has no "250" series terminator. just one line and done ✨
4.2.3 Code 250 - Successful Transaction 🎀
this is the general "yes, that worked" code 🫶 it tells you the server successfully processed a command. on top of that, a 250 can also show up at the end of a HELP response (the 214 series commands, which we'll get to).
4.2.4 Code 421 - Fatal Error, Connection Terminated 💀
this one shows up right before the SNPP server closes a connection with a client because of errors. the connection can get cut at any time and for any reason, administrative or technical. not me getting kicked out mid-convo 😭
4.2.5 Code 500 - Command Not Implemented 🙈
this is a "fail but continue" code 💅 it pops up when someone enters an illegal command, but the session keeps going.
4.2.6 Code 503 - Duplicate Command Entry; Already Entered That 🍓
this code means the info you're giving has already been entered. for example, you'd get this if the client tried to enter a MESSage command after already starting a DATA sequence. we've all been there, bestie 😭
4.2.7 Codes 550 and 554 - Transaction Failed, but Continue 🔥
these codes mean a command failed, but the session is still allowed to keep going. a 550 is for more "administrative" failures (like an invalid pager ID or an illegal parameter), while the 554 series is for more technical stuff (like a gateway being down or equipment failing). on top of the listed failure codes, extra 550 and 554 failures can be defined as needed for more flexibility 🌈
4.2.8 Code 552 - Maximum Entries Exceeded 👑
this code is the reply when someone enters the "n+1" item and the server only allows "n" items in a category. example: you'd see this if you tried to enter a 6th PAGEr command when the terminal only supports 5 🙃
4.3 Level 1 Commands 💖
level one commands are the minimum implementation of the protocol, the basic starter pack 🧸 this set can be used with either TAP/IXO or TME for sending messages to the paging terminal.
4.3.1 PAGEr <Pager ID> 📟
the PAGEr command submits a pager ID (PID) number so it gets included in the next messaging transaction. the PID has to live in the paging terminal and be validated there. the server may optionally do limited validation (like checking that it's all numeric or checking the ID length), or the validation can be left to the terminal when the page gets sent.
when you implement SNPP, the user may choose to support multiple recipients per message. just be wary though: validation-prior-to-sending isn't possible with TAP/IXO (and it isn't an official option in the current TME spec). so if you want to validate a PID, you have to generate a message to the pager, and the terminal responds with a yes or a no. when a single PID in a sequence fails, figuring out how to report that failure in a "standard format" might be a challenge 😩
possible responses from the SNPP server, with suggested text, 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, so check out the right section(s) for the details 💅
4.3.2 MESSage <Alpha or Numeric Message> 💬
the MESSage command sends a single-line message into the gateway. the SNPP server may do limited validation on the message (like length), but type-of-message validation should be done by the paging terminal. if you enter MESSage again before SENDing, the server should give you "503 ERROR, Message Already Entered" and let you keep going ✨
possible responses from the SNPP server, with suggested text, 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 wipes the info already entered in the server session and puts it back to how it was when the connection first opened. it's mainly there so you can fix stuff you accidentally typed during a manual session. oops-proof, babe 🫠
possible responses from the SNPP server, with suggested text, 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. before processing, the PAGEr and MESSage fields (or the message DATA if you're using the level two option) should be checked to make sure they actually have info in them. if one of those required fields is missing, the server should reply "503 Error, Incomplete Information" and let you continue. if everything's complete, the SNPP server should format the page, send it to the paging terminal, and wait for a response 💖
possible responses from the SNPP server, with suggested text, to a SEND command are:
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, if the pager ID is illegal or doesn't exist, or the page is being rejected for some other administrative reason, the server should respond:
550 Failed, Illegal Pager ID (or other explanation)after processing a SEND command, the server should stay online so the client can submit another transaction 🌈
level 3 enhancements to this command allow for other responses, so check the appropriate section for that 🦋
4.3.5 QUIT 👋
the QUIT command ends the current session. the server should just respond with:
221 OK, Goodbye"and then close the connection 🥀
4.3.6 HELP (optional) 🧠
the optional HELP command shows a screen of info about the commands that are valid on the SNPP server. it's mostly there to help manual users of the gateway. every line of the HELP screen (the responses) starts with a "214" code. at the end of the HELP sequence, a "250" series message is sent ✨
possible responses from the SNPP server, with suggested text, 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 Implemented4.4 Level 2 - Minimum Extensions 🎀
this section lays out the minimum enhancements to the SNPP protocol for extra functionality 🔥
4.4.1 DATA 📝
the DATA command is an alternate form of the MESSage command. it lets you deliver a message to the paging terminal over multiple lines 🌸 this command works a lot like the DATA command in SMTP (Internet STD10, RFC821). the SNPP server should only allow one DATA or MESSage command before a SEND.
possible responses from the SNPP server, with suggested text, 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)once the client gets a "354" response, it starts typing in the message line by line 💬 a single period (".") in the very first position of a line ends the input. after the input, the server may respond with:
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 covers enhancements to the SNPP protocol that give you more control over paging functions 💅 they're mainly designed to mirror the extra functionality built into the Telocator Message Entry (TME) protocol, which is specified in the TDP protocol suite. these functions may, optionally (as is being done by the author), be built into a paging terminal. nobody's required to implement all of them 🫶 if someone asks for a function that isn't valid, the server should return a "500 Function Not Implemented" error.
it's important to note that, at the time of this publication, the TME standard is still not finalized 🙈
4.5.1 LOGIn <loginid> [password] ✨
okay so this command lets you set a session login ID 🔐 It's how the paging terminal checks who's trying to get in, so nobody random can slide into the DMs 💅
If no LOGIn command is issued, the session is treated as "anonymous" user status 👻
Here's what the SNPP server might send back when you use LOGIn, with suggested text:
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 the glow-up of the level one version 💖 The big difference is that you can now attach a password or PIN for validation or to unlock certain features 🔑
Before we go further, you need to get the vibe of how PAGEr works with LEVEl, COVErage, HOLDtime, and ALERt (those option parameters are described below) 🧠 Every time you send a PAGEr command, think of it as the final step of a multi-step transaction. It's the grand finale 🎆
When PAGEr gets processed, the pager ID (and password) gets sent to the paging terminal along with LEVEl, COVErage, HOLDtime, and ALERt. If you haven't changed those options, their defaults are used for that transaction. Once the next PAGEr command has been processed, those option parameters go back to their defaults 🔄 This is the "option-option-option-go" scheme, and it's so iconic because you can give "Jeff" a higher priority level and "Kathy" an alternate coverage area, all while sending the same message to both of them 🫶
Here's what the SNPP server might send back in response to a PAGEr command, with suggested text:
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 lets you pick an optional alternate service level for the next PAGEr command ⭐ Ideally, "ServiceLevel" should be an integer from 0 to 11 inclusive. The TME protocol defines ServiceLevel like this:
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'Whether this feature gets implemented, and how far it goes, is up to the carrier 💁♀️ It's optional, so they get to decide the details.
Here's what the SNPP server might send back in response to a LEVEl command, with suggested text:
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 lets you override the default and decide whether the subscriber gets alerted when a message comes in 📳 Like the command before it, it changes the parameters that go to the paging terminal along with PAGEr. The TME protocol says AlertOverride is either 0-DoNotAlert, or 1-Alert.
Here's what the SNPP server might send back in response to an ALERt command, with suggested text:
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)4.5.5 COVErage <AlternateArea> 🗺️
the optional COVErage command lets you override the subscriber's default coverage area and pick an alternate region 🌍 Like the previous command, it changes the parameters sent to the paging terminal with PAGEr. AlternateArea is a designator for one of these:
- A subscriber-specific alternate coverage area
- A carrier-defined region available to subscribers
Let's take Mary Ghoti as an example 🥰 Mary has local service in Chicago, Illinois (that's her region '1'). Her account is set up so her pager can be paged nationwide on demand (that's her region '2'). If you send COVErage 2 before the right PAGEr command, it overrides the default Chicago area, and Mary's pager gets messaged nationally for that one transaction 📲 The carrier providing Mary's service is expected to keep track of how many pages were sent to her pager this way, and will bill her accordingly 💸
Here's what the SNPP server might send back in response to a COVErage command, with suggested text:
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 lets you delay delivery of a message to a particular subscriber until after the time you specify 🕰️ The time can be in local time (local to the paging terminal), or you can add a parameter for the offset from GMT. For example, -0600 specifies Eastern Standard Time 🗽 Like the previous command, it changes the parameters sent to the paging terminal with PAGEr.
Here's what the SNPP server might send back in response to a HOLDuntil command, with suggested text:
250 Delayed Messaging Selected
421 Too Many Errors, Goodbye (terminate connection)
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
550 Error, Invalid Delivery Date/Time
554 Error, failed (technical reason)4.5.7 CALLerid <CallerID> 📞
the CALLerid function is message-oriented, which is different from the subscriber-oriented functions we just went through 💬 It lets you specify the CallerIdentifier function as described in TME. This parameter is optional, and the carrier decides how it gets implemented or used 🤷♀️
Here's what the SNPP server might send back in response to a CALLerid command, with suggested text:
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> 📝
SUBJect is another message-oriented function, and it lets the sender set a subject for the next message 💌 This parameter is optional, and again, the carrier decides how it gets implemented or used 🫧
Here's what the SNPP server might send back in response to a SUBJect command, with suggested text:
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 covers the enhancements to SNPP that support acknowledgment-based paging, aka two-way paging 🔁 One of the most powerful things about ReFLEX-style paging, besides confirmed delivery, is being able to "seed" a message with multiple-choice responses 🍓 After the recipient reads the message, she can reply with one of those seeded options. On top of the multiple-choice responses (MCR's), the sender can also choose to get a confirmation the moment the recipient first views the message 👀
4.6.1 2WAY 🚀
the 2WAY command comes before each two-way transaction (see the previous example) 🎬 It puts the server in a mode where it can receive and process one single 2-way transaction. The server goes back to "non-2WAY" mode once a SEND command or a RESEt command finishes. While in 2WAY mode, you can still send multiple MSTAtus commands to check responses from field message units 📟
Here's what the SNPP server might send back, with suggested text:
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 🛰️ Location info is super sensitive, so the subscriber can choose a generic "pager located" message (ACLU mode) instead of getting their 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> ⌛
this one changes the default expiry time for a queued message delivery ⏳ If the message isn't delivered within the number of hours you set, it gets deleted, and the MSTAtus tag is updated to show it couldn't be delivered (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)4.6.4 NOQUEUEing 🚫
this command tells the server not to allow message queuing for this 2WAY transaction 🙅♀️ In this mode, if a pager is offline, the client gets a "750" series response to a PAGEr command. This command must be sent before 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> ✅
this command turns message "read" acknowledgment on or off ✨ When it's on, the field message unit is told to send something back once the subscriber actually views the message 👁️ This works separately from the actual reply, so it's its own thing 🫶 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> 🎀
okay so RTYPe is how the client changes what kind of reply the field unit is allowed to send back 💅 the starter reply types 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)the server can respond to an RTYPe command with:
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)4.6.7 MCREsponse <2-byte_Code> Response_Text 🦋
this one gets sent right before the SEND command, and it basically "seeds" the transaction with a multiple choice response that's allowed 🫶 every response is specific to the message you're sending. the SNPP server can cap how many acceptable responses there are if the provider wants. examples:
MCREsponse 1E2C Here is one response
MCREsponse 0002 This is another responseand the SNPP server answers with:
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 🌈
when you're in 2WAY mode you get some upgraded responses, iykyk 😭
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 💜
SEND tells the SNPP server to "launch" the message (plus any attached response codes) to the field unit 🚀 a successful SEND hands you back a "Message_Tag" number and a "Pass_Code" for checking status later. then you use MSTAtus to see how things are going. the "Message_Tag" works like a "record locator," and the "Pass_Code" should be a randomly generated "PIN" code that authorizes checking that tag.
the response codes for SEND and MSTAtus show how "final" the transaction is. based on the delivery process there are four categories, and their prefixes are:
86x - Initial message delivered, awaiting requested action(s)
87x - Intermediate processing completed, awaiting closure
88x - Transaction concluded (final)
96x - Queued transactionthese prefixes make a multi-tiered transaction pretty easy to follow to the end 🧚 once you get an 88x series response code, every requested part of the transaction has been processed, and no more status changes will happen. ✨
the SEND command should reply with the first tier of message processing. after that, you check the status of the message with the MSTAtus command, periodically.
possible responses to SEND:
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 how a client program keeps checking the delivery and reply status of a message 👀 SEND gives you the "Message_Tag" and "Pass_Code" you need here. a "Message_Tag" may (should be) expired by the SNPP server once enough time has passed. how tags expire is up to the vendor, and it may speed up after the first check following the message's final disposition (like after a client program has successfully received the field unit's response code).
the tag record holds a "Sequence" number, an incremental counter that goes up whenever the record's status changes (like going from a delivery acknowledgment to a reply). the date and time of the current transaction should also be kept in this format:
YYMMDDHHMMSS+GMT (example: 950925143501+7)because replies come in tiers, the possible responses to MSTAtus 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)once a closure-series (88x) response has gone back to the client, speeding up deletion of the message tag may be desired, so the server isn't hoarding resources 🧹
KTAG <Message_Tag> <Pass_Code> 💅
this "kills" the message tag after the final read (or when you don't want any more responses). it's more of a courtesy feature so the client can "clean up" instead of waiting for the SNPP server to expire the tag 🫶
4.7 Illegal Commands 🚫
if the client sends an illegal command, the server may respond in one of these two ways:
421 Too Many Errors, Goodbye (terminate connection)
500 Command Not Implemented, Try Againhow many illegal commands get tolerated before the connection is terminated should be up to the operator of the SNPP server 🙈 the only response we haven't covered yet is:
421 SERVER DOWN, Goodbyethis one is used to refuse or end connections when the gateway is administratively down, or when there's some other technical or administrative problem with the paging terminal. 💀
4.8 Timeouts ⏰
the SNPP server can, optionally, have an inactivity timeout set up. when the time runs out, the server replies "421 Timeout, Goodbye" and closes the connection 👋
4.9 Rigidity of Command Structure 🧱
the commands from client to server should remain constant. but the first character of a response tells you success or failure, so the text of the server responses could be changed to suit the taste of the SNPP server's operator ✨ it's suggested that the response codes mirror SMTP response codes as closely as possible.
5. Revision History 📜
way back, the author first used POP2-style result/response codes. the Internet community suggested switching that '+' and '-' style to numeric response codes, like the ones used by services such as SMTP. the protocol was changed to this specification from the first proposed draft 🌸
administrative errors (like an Illegal Pager ID) were split off from technical errors (like being out of disk space). administrative failures generally get a 550 series response, while technical failures get a 554 series code.
level two enhancements were added to the protocol in preparation for TME deployment 🚀
level three enhancements were added in preparation for acknowledgment-based messaging 💖
the error code "502 Command not implemented" was changed to a general "500 Command not recognized" failure result, to follow SMTP more closely.
6. Relationship to Other IETF Work 🤝
this spec's strategy, and a lot of its details, were reviewed by an IETF Working Group and three IESG members 👑 they concluded that using the existing email infrastructure was the better approach, mostly because deploying a brand new protocol is super expensive and using the Internet's most widely distributed applications protocol infrastructure has big advantages. most reviewers felt no new protocol was needed at all, since SNPP's special "deliver immediately or fail" requirements could be met by carefully configuring clients and servers. the experimental network printing protocol [4] was pointed to as an example of using existing infrastructure for an existing problem. other reviewers thought there was a case for new protocol details to identify paging clients and servers to each other and negotiate transaction details, but they felt it would make more sense to handle those as extensions to SMTP [1, 2] rather than deploying a new protocol structure.
the author gets these positions, but thinks a separate protocol has merit, since it isolates the details of TAP/IXO and its evolving successors from users, and from mail-based approaches that might reach systems acting as SMTP/MIME [3] to SNPP gateways 🦋 those systems and gateways are actually being designed and developed alongside this work. see the section "Why not just use Email and SMTP?" for more on the author's take on the classic 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.
8. Security Considerations 🔒
Security issues are not discussed in this memo. Literally none. Go in with your eyes wide open 👀💀
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.netthat's the whole spec, bestie 🌈💖 you made it!!
📦 where this page comes from
- ietf: rfc1861 1995-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms