Simple Network Paging Protocol - Version 3 -Two-Way Enhanced
RFC 1861
Document | Type |
RFC - Informational
(October 1995; No errata)
Obsoletes RFC 1645
Was draft-rfced-info-snpp-v3 (individual)
|
|
---|---|---|---|
Author | Southern University | ||
Last updated | 2013-03-02 | ||
Replaces | draft-gwinn-paging-protocol-v3 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1861 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 baseShow full document text