1> It seems overly complicated. If you only allow one MESS and one
PAGE for each send, you shold collapse it into one verb, e.g.
-> PAGE 5551212 Your network is hosed
<- 250 Page Sent
-> QUIT
<- 221 Goodbye!
I helped build a pager system with a very similar protocol. Don't
needlessly multiply entities.
2> You should allow for multiple pager IDs per message.
Funny you should mention that :-) The reason that I did it with the
PAGEr/MESSage format was so that eventually, hopefully, I could
figure out a "good" way to provide for multiple pager IDs per
message. As you are aware, IXO doesn't really tell you that a
pager ID *was* invalid until you have assembled the whole message and
sent it to the paging terminal. Big problem. This means that you
can't really validate a pager ID without trying to send it a page.
There are standard protocols in the paging industry that will allow
you to do a validation query. That is why I've started building this
protocol this way. Hopefully, this philosophy will allow for instant
validation of each page in a multi-recipient message. But right now
its just a "stepping stone" to get a terminal up in an easy-to-access
manner.
3> Meaningful error responses should be numeric, with arbitrary
ASCII strings appended for human-readability.
I patterned this after the (yecch) POP2 protocol because of being able
to report success or failure (in various degrees) by looking at the
first character of the reply. I have, however, considered numeric
error responses in later implementations.
4> Some form of authentication should be provided.
Yeah, yeah, I know :-) I will probably do some sort of lookup and
logging of the sender at the gateway, but is this really part of the
protocol? I mean, look at what they deal with now: dialup phone lines
into a modem. Thats pretty anonymous. Anything we do on the net is
going to be more "secure" than that.
It is interesting to note that IXO does provide for a "password" to
access the IXO terminal, but nobody really uses it (rather I should
say "not that I know of") at public paging companies.
That aside, I like your approach,and this is something that sure could
use standardization!
Thanks! This has been one of those "gonna-do's" that I have wanted
to do for some time. My goal was (1) simplicity, and (2) something that
would be buildable for the future.
Is this really appropriate for ietf-822?
Dave Crocker threatened to have me thrown into an industrial eggbeater
and turned into an omlette if I didn't :-) If this is not appropriate
for this group, I will certainly refrain. Please let me know.
Allen Gwinn
allen(_at_)mail(_dot_)cox(_dot_)smu(_dot_)edu