RFC 1861 (rfc1861) - Page 3 of 26
Simple Network Paging Protocol - Version 3 -Two-Way Enhanced
Alternative Format: Original Text Document
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
