Shapira, Noam (Shapira_Noam@icomverse.com)
Wed, 1 Aug 2001 08:39:55 +0300
Hi James,
Sorry for the slow response,
See my comments in the text,
> -----Original Message-----
> From: James P. Salsman [mailto:bovik@best.com]
> Sent: Sunday, July 29, 2001 12:53 PM
> To: Shapira, Noam
> Cc: snap@lists.neystadt.org; vpim@lists.neystadt.org
> Subject: RE: draft-shapira-snap-01.txt
>
>
> 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?
I will do it in the next version
>
> >> 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?
>
Basically, the protocol is for ES - email notification. But the truth is
that it can be extended to much more notification types. This specific
implementation is great and as far as I understand it can be deployed with
the SNAP (some thing like ServerType = physical in-box). The only problem
will be (is it?) that the information on the received messages will be very
small..
> > 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?
The SNAP proposal, talks about the channel between the ES and a
notification service.
The notification service will send the end notification to the hand-set,
PDA, etc.
The idea is not to bundle proposal with the HTTP transport from server to
server.
>
> 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.
I will!
>
> 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
>
Thanks again,
Noam
This archive was generated by hypermail 2.0b3 on Wed Aug 01 2001 - 08:41:08 IDT