Simple Network Paging Protocol - Version 3 -Two-Way Enhanced
RFC 1861

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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