In <8884(_dot_)746939162(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> Marshall
Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
writes:
Ok, I'll ask the obvious question then. Why can't you do this with SMTP?
There seems to be some confusion surrounding the purpose and intent of
SNPP. Here are the constraints:
1) The protocol MUST be simple enough for someone to use via a telnet
session, so that even if there is never a paging client developed
to interface with it, it is still usable.
2) This *cannot* be a store and forward function. It must run real
time and report immediate success or failure. In the "Real" world,
page latency is critical. As a doctor, when my patient suffers cardiac
arrest, I need to be notified *then*! To send messages via email
is not acceptable to me, because if the message didn't go through,
I want my answering service to know about it *then* and take action
under plan "B" (a modem to a dial-up line).
SNPP is designed to sit on a box (gateway) plugged into the Internet on
one side, and a serial line to an IXO port on the other. It is designed to
have real-time interaction, and real-time response reporting. In other
words, when you have finished a message, requested a "Send" and received the
message "Page Sent," this means that the data has actually been delivered
to the paging terminal and is being processed to the uplink. About
20 seconds later, your recipient's beeper should ring.
I guess the key words here are "real time" and "simplicity." I know that
this was a point of a little confusion, and hopefully this will clear
it up.
Allen