James P. Salsman (bovik@best.com)
Sun, 29 Jul 2001 02:52:56 -0700 (PDT)
Noam,
Thanks for your message:
> Actually, from other responses, as well as yours, I was thinking of using
> draft-ietf-vpim-hint-07.txt, for the message type attribute - any comments?
That's probably a good idea, although I am not sure why they feel a need
to distinguish pager messages from text messages. Perhaps phone numbers
are more likely to be in pager message strings, but why not combine the
two and use whatever function scans pager messages for phone numbers to
do the same thing from ordinary text messages?
>> Is the protocol extensible enough to be notified when other messages
>> are received (such as when there is new physical mail waiting at some
>> location, for instance)?
>
> I am not sure I understand the question - can you elaborate?
Suppose we put a small pressure-sensitive switch at the bottom of the
physical in-box on our desks. If we connected it to one of the TTL
input pins on our parallel printer ports (not connected to printers)
and wrote a program to constantly test the pin and keep track of the
switch's state, could the SNAP system provide notification when the
switch is pressed by new papers being placed in the in-box?
> The proposal is not based on HTTP - rather, the proposal was implemented
> over HTTP - as the transport Layer. As you can see in the proposal, most of
> the proposal uses RFC-822 - mostly in the attributes values & formatting. We
> might need to improve it - but this is the spirit of things.
Well, let me tell you a story. I used to carry a pager, a phone, and
a PDA, but some months ago I got a Kyocera QCP-6035 phone+Palm-pilot
hybrid. I like it a lot. (My only complaint is that I can not access
the microphone from the PalmOS programs, so therefore it is useless
as a VPIM transmitting client, although it can play many audio types.)
Anyway, to make a long story short, my phone has two different email
addresses, one of which beeps or vibrates, truncates messages to 140
characters, and which can be read from by pressing one button on the
side of the phone, and another address that requires a manual check of
the email server spool, and handles plain Internet messages, but not
attachments. However, the email reader makes embedded URLs directly
clickable, and the registry allows for adding custom URL schemes with
which audio can be played, faxes could be retrieved, etc.
So, my notification method consists of some procmail recipies and a
few cron jobs that send things of importance through to one or both of
my phone's email addresses. Internet access is charged the same as
voice phone calls, precluding the phone from runing an always-on web
server, so the HTTP-based examples in the SNAP draft would exclude me
from the ability to be notified. I suppose I could write a CGI script
as a gateway, but is there anyone who WON'T have to do the same thing
to start using SNAP?
For example, when someone sends email to an address such as
<6035@bovik.org>, procmail basically just sends a copy to both of the
phone's email addresses, similar to <6505554321@sms.phoneco.com> and
<j.salsman@popmail.phoneco.com>. My cron jobs, which indicate when
systems that I'm responsible for fail, use that unified address, the
Subject: line header, and the message body ONLY. Anything else would
not be visible, and the part that I can see within a minute or two
gets truncated anyway, so the important information must always be on
the first few lines.
An ideal notification system for the phone would not require an HTTP
server, and if the notification details end up in the message headers,
or in some complex MIME structure, that won't help either. I hope you
will please keep these constraints in mind when refining SNAP.
Cheers,
James
P.S. There are other reasons for not using HTTP as a transport layer:
http://www.ietf.org/internet-drafts/draft-moore-using-http-01.txt
This archive was generated by hypermail 2.0b3 on Sun Jul 29 2001 - 12:53:26 IDT