[Top] [All Lists]

Re: Simple Network Paging Protocol

1993-09-02 10:12:40
My take...

There is already a widely available *and* working infrastructure which
carries store-and-forward traffic.  That is.. E-Mail.

So like there's an Experiment in "Remote Printing" going on there could
be an experiment in "Remote Paging".

Rather..  The fact that it is a pager message would be a side effect
of the address it is sent to.  At the `delivery' point it might be sent
into a little queuing system which used an SNPP-like protocol to get through
the final hop into the pager.

For SNPP to succeed it would have to create a parallel infrastructure
which does `store-and-forward'.

Moving on to general issues..  E-Mail isn't the only sort of store and
forward activity around.  On Bitnet they make much use of unsolicited
file transfer (rather than the recipient having to request a file, the
sender can send a file) which could be usefully implemented in SaF style.
Then there are messages of the type meant to be carried by SEND/SAML/SOML.
Also real honest-to-goodness print queuing (with named printers, paper
attributes like page length & width, request postscript or HPGL, etc) should
be in SaF style.  This is what comes to mind after a moments thought.

With enough different application areas needing an SaF infrastructure perhaps
it is worthwhile creating a new general purpose SaF protocol.  One to which
could be added new SaF applications as needed.  Which had some management
abilities so one might be able to find out which spooling site has their
print job/mail message/etc and perhaps cancel it or see what is holding it up.

SaF application areas named above:  E-Mail, Unsolicited file transfer (perhaps
also solicited file transfer), SNPP, SEND/SAML/SOML, print queuing.

If done right it could be transferrable in a half duplex fashion like BSMTP.
And reach into places which can't to IP (bitnet, UUCP, etc).

All these application areas can be layered on top of E-Mail.  Especially with
good choices of MIME body part types.  So it might not be worth the trouble
to invent a new SaF infrastructure.  On the other hand maybe there is a user
perception problem .. if it is transferred using `e-mail' then isn't it e-mail?
How can it be e-mail but something that's not e-mail?  Or is that part of the
purpose in the remote printing experiment?  To show that e-mail can be a general
SaF transport protocol?

About the only idea above I'd like to see developed more is the management
aspect.  Users are *frequently* asking to be able to cancel messages that
are in transport.  Or to find out what's holding up their e-mail.  Or...

If E-Mail is used for other application areas then the requests will increase.
Most print queuing systems include an ability to look and see where your
print job is, cancel it, see what's holding it up, etc.

<- David Herron <david(_at_)twg(_dot_)com> (work) 
<david(_at_)davids(_dot_)mmdf(_dot_)com> (home)
<- All hard work brings a profit, but mere talk leads only to poverty.
<-               Proverbs 14:23