Let me take a half-step past Steve Dorner's comments, with which I basically
What you are hearing, I think, is a general sense that "one more protocol"
is worse than "pushing a little on an existing one", just in terms of
what is already deployed. We've got about 20 years of Internet experience
to attest to the wisdom of that. You seem to have two main problems
with using SMTP.
One seems to be complexity; but people on this list are arguing
forcefully that SMTP isn't inherently more complex than what you are
The other seems to be the risks of getting involved in a store-and-
forward situation. One way to eliminate that is to use SMTP client-to-
remote server, just as you propose with SNPP. That was, curiously, the
normal situation in early internet mail implementations: wide adoption
of "send it to the local server and let it cope" came only later.
The design ideas suggested below are not proposals but weak strawmen
intended to help open up the discussion and thinking a bit.
We do have some interesting artifacts lying around in SMTP that were
intended for direct delivery to terminals (with or without "delivery to
mailbox" fallbacks). It might be worthwhile for you to take a look at
SEND FROM and its two cousins (SAML and SOML). In principle, if you
really didn't want any relaying, you could even define an SMTP service
extension of either the "don't relay at all" or the "deliver by YYYYMMDD
HHMMSS or tell me" persuasions. Dealing with those service extensions
would require changing clients and servers, but those changes are
typically smaller than deploying a new protocol.
And, by continuing to use the mail infrastructure, it is plausible that
you could get pages through gateways from other mail services--e.g., by
having a MIME message with specific content sent to a gateway that would
set up the appropriate extended SMTP machinery from the message
content. Eliminating the requirement for IP-connected Internet use only
would seem like an advantage too. And it seems to me that you haven't
argued for "real time" as much as for "fast delivery or notification".
Let me make another suggestion: if you, and the "major national paging
firm", invent a new protocol, its use will end up localized to a few gateway
servers and clients that speak directly to them, probably by typing
commands over a telnet connection (a nasty business, since everything has
to be correct). The rest of the folks you are hearing from here, if they
want to communicate with pagers offered by that firm, will just set up
a mail-based protocol by which messages can be sent to pagers by routing
them to gateways that accept SMTP/822/MIME and produce SNPP. Marshall
suggested a variation on that theme in one of his notes, paralleling the
remote printing experiment. If that is the case, the discussion here turns
into one of whether there is value in injecting an SNPP middleman between
SMTP/822/MIME machinery, which will be used anyway, and IXO on the far