Simple Network Paging Protocol - Version 2
RFC 1645
Document | Type |
RFC - Informational
(July 1994; No errata)
Obsoleted by RFC 1861
Obsoletes RFC 1568
|
|
---|---|---|---|
Author | Southern University | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1645 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group A. Gwinn Request for Comments: 1645 Southern Methodist University Obsoletes: 1568 July 1994 Category: Informational Simple Network Paging Protocol - Version 2 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 both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows 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 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. Additionally, automatic page delivery should be somewhat more simplified. 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 Gwinn [Page 1] RFC 1645 SNPP - Version 2 July 1994 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. However, acknowledging the complexity 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. Validation of the paging information is left completely up to the paging terminal, making an SNPP gateway a direct "shim" between a paging terminal and the Internet. 3. Why not just use Email and SMTP? Email, while quite reliable, is not always timely. A good example 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.Show full document text