Before I start, let me say that you have talked me into adding support
for SMTP sessions into the ultimate goal of the paging system. I am
not, however, convinced to drop SNPP.
Without commenting on the various details under discussion, I want to
raise a couple of questions: Why does SMTP "inherently" incur the
delay that you cite? While it is certainly true that general use of it
involves various sources of store-and-forward delay, I believe that
none of that is required, if a given sender wishes to accomplish a
"direct" interactive link to a given receiver.
It isn't really the possible delay as much as it is the interaction with
SMTP. I realize that SMTP could probably be modified to allow for a
specific type of message to be aimed directly at a pager (maybe?). But
if the message originated from a UUCP site, while perfectly legal to
deliver it, the real time advantages that I seek would not be possible.
SNPP, as I have said time and time again, is a simple protocol designed
for immediate interaction with the paging terminal, replacing a phone
line. It is not intended to be a two-way path for electronic mail.
I do want to provide support for email connections, but want to do
it right. Right now, I just want to get something up and running--
something that I've already developed, and that works. How long
do you think it would take to get a full mail gateway into place
and make modifications to SMTP to allow for immediate status reporting
of failed or delivered pages?
Case in point: you have to provide the beeper "PIN" and the
message body itself to present to the IXO/TAP terminal in
order to even get the terminal to tell you if the PIN was
valid. In other words, the entire message (header and all)
must be completely delivered before message validation can
occur. It is my understanding that you cannot immediately
reject a message on the DATA portion of the message--only
on information contained in the header (RCPT TO in this case).
Since you can't validate the page until after the DATA, you
can't immediately reject it. Is this not the case?
Therefore, if the IXO/TAP gateway did not like the pager "PIN"
number, the only way to be notified of failure is via email.
Don't you think that this would make a simple UA rather
cumbersome to create? Consider one sitting on a PC running
a Clarkson packet driver. It would have to sit there with an SMTP
server active for a period of time after a page had been sent
waiting for a bounce message that may or may not come.
That is, there is a big difference between protocol design and operational
configuration.
On the matter of user agents, you are simultaneously challenging the
lack of any UA's designed specifically for paging while also stating a
desire to allow Telnet interaction with an SNPP server. These sound
like competing arguments, to me. (However, the argument for allowing
Telnet access reminds me of the original arguments for the design of
FTP, 20 years ago...)
Actually not competing arguments. I want to be able to tell people
how they can send messages to their beepers via the Internet starting
"next Tuesday," and "this" is how they can do it. I also want to
provide a spec so that software providers can create simple UA's to
eventually do the job--perhaps integrating support for them into
existing products.