[Top] [All Lists]

Re: SNPP - A Clarification

1993-09-06 11:43:53

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.

On the other hand, the UUCP site has no chance at all at using the
SNPP over a TCP connection, so a few minutes delay vs. infinity
perhaps isn't so bad.

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?  

We've already developed and use in production an EMAIL to IXO paging
gateway, and it works just fine.  Our network management software
doesn't use it, as it just generates pages directly, but other folks
do use it.  It simply pages the Subject: line of the email message as
well as sending the message via email to the recipient.  I don't know
why I'd want to throw this away and use SNPP since it doesn't seem to
buy me anything.

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?

Given a typical SMTP dialog like:

220 5.65c/IDA-1.4.4 Sendmail is ready at Mon, 6 Sep 1993 14:28:16 
250 Hello, pleased to meet you
MAIL From:<louie(_at_)sayshell(_dot_)umd(_dot_)edu>
250 <louie(_at_)sayshell(_dot_)umd(_dot_)edu>... Sender ok
RCPT To:<louie(_at_)ni(_dot_)umd(_dot_)edu>
250 <louie(_at_)ni(_dot_)umd(_dot_)edu>... Recipient ok
354 Enter mail, end with "." on a line by itself
250 Ok
221 closing connection

There's no reason why the response to the CR LF '.' CR LF terminating
the data can't be something othe rthan '250 Ok'.  According to RFC-821
(that documents SMTP), the valid responses to the second phase of the
data command are

        250 ok
        552 Requested mail action aborted; exceeded storage allocation
        554 Transaction failed
        451 Requested action aborted; local error in processing
        452 Requested action not taken: unsufficient system storage

You could certain return something other than "Transaction failed" as
descriptive text if the PIN number (which no IXO system I've seen ever
uses) was wrong.

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.

Don't have the client wait around; return an error at the end of the
DATA command.  Of course, he still will never know that the page was
delivered or not, due to lack of coverage, pager being turned off,

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.

The way that we tell people is to send mail to
username(_dot_)beep(_at_)foo(_dot_)dom(_dot_)ain, which will page the 
"username" person.
Nothing different than they've been doing for years, other than the
addition of the ".beep" suffix on the user name.

You have to be careful not to build too high a level of expection that
devliver of the message will actually occur.  As Marshall Rose pointed
out, delays of 10 or 15 minutes are not unusual here in the
Washington, DC area either.  And given the open-loop nature of the
page, you don't know that you missed a page because you were in an
area of bad coverage.

Frankly, I'd rather just have an RPC to the paging system rather than
anything that has to go via an IXO gateway.  Those paging system are
just plain ugly.  In any case, doing IXO is not that difficult; we do
it in an expect script (checksums and all).

Louis A. Mamakos
University of Maryland, College Park

<Prev in Thread] Current Thread [Next in Thread>