Milt Roselinsky (milt.roselinsky@openwave.com)
Wed, 12 Dec 2001 16:43:07 -0800
> -----Original Message-----
> From: noam_shapira@icomverse.com [mailto:noam_shapira@icomverse.com]
> Sent: Wednesday, December 12, 2001 7:27 AM
> To: milt.roselinsky@openwave.com; Shapira_Noam@icomverse.com;
> ietf-imapext@imc.org; snap@lists.neystadt.org; vpim@lists.neystadt.org
> Subject: RE: SNAP progress and request for comment
>
>
> Thanks for your comment
>
> See my comments in text:
>
>
> > I have a few comments about the current draft, and some larger comments
> > about the scope of the ID
> >
> > In section 3.5.11 and 3.5.12 regarding attachment names and number of
> > attachments, using Content Disposition isn't a very reliable
> way of gaining
> > this information. Perhaps an IMAP-like bodystructure that's
> annotated with
> > attachment information would be more useful.
> Basically I agree that Content Disposition isn't the best thing.
> But, your alternative will make the work very "expensive". If for
> each email entering the system we will need to do this annotation
> - it will be a killer for the SMTP process on the email server
> side. Any one - thoughts on the issue?
There are very few situations where Content Disposition is going to work.
Yet in the current SNAP ID its the basis of some important functionality.
IMO it would be better to make provision of a description of message content
optional and then describe something that works than to design something
that isn't likely to work.
>
> >
> > 3.5.14 - Body should enable sending non-text body content - the
> decision on
> > what is appropriate content is outside the scope of SNAP.
> I am not sure I agree with you. This is a notification protocol
> and not a messaging transferring protocol. The notification
> protocol should be rich enough in order to allow the notification
> server (or the UA that the notification server usses to notify
> the user) to retrieve the new message. The fact that we added the
> text (and maybe we shouldn't have..) was because of the facts
> that some of the UA are primitive and can't retrieve the message.
In bandwidth starved environments, it would be a huge win to be able to
provide payload in the notification. Why not design something with network
efficiency in mind?
> >
> > 3.6 - counters group - specific message type counters are very
> limiting, it
> > would be better to have an extensible mechanism.
> See my later comment on the issue
This issue is actually separate from the issue of using notification for
other applications. The counters group would be much better served by
allowing a simple extensible list of counters. To support fax, voice and
email as in the current ID, this could be a list
"Counters:total=X,image/tiff=Y,multipart/voice-message=Z". If an
implementation wanted to provide the number of any other media type, they
could just add it to the list. If the recipient of this information doesn't
care about some of the information, it can just ignore it.
> >
> > General comment:
> >
> > This protocol is very specific to notification of mailbox
> status but mailbox
> > status is just one of the many applications that use
> notification. It seems
> > that there should be application specific payload descriptions
> in the body
> > of these messages one of them related to MWI and other mailbox related
> > information and other related to other notification events.
> The interface
> > to the notification service should handle more than mailbox events.
> >
> > I strongly encourage you to expand the capabilities of the
> notification ID
> > by generalizing payload, counters and by adding an area for application
> > specific metadata. As application developers or future IETF
> working groups
> > adopt the notification standard, they would publish the
> definition of that
> > application specific usage.
> >
> The idea of having one notification protocol for a range of
> notification events has been talked about in the past. The
> problem with this is that trying to have a generic notification
> protocol has been tried in the past and failed. What we are
> trying to do is to attack the problem - one after the other -
> starting with the messaging arena. I understand the wish to have
> a multi-purpose protocol for notification (I share it) but it
> will be impossible to close it ever. We might need to add a
> header that will help us to extend the protocol later on. What do
> you think?
I think I'm disappointed at limiting scope so drastically. With this
approach we're doomed to implementing the same basic functions many times.
>
> > Milt Roselinsky
> > Openwave Systems
> >
> > > -----Original Message-----
> > > From: owner-ietf-imapext@mail.imc.org
> > > [mailto:owner-ietf-imapext@mail.imc.org]On Behalf Of Shapira, Noam
> > > Sent: Tuesday, December 04, 2001 10:39 PM
> > > To: ietf-imapext@imc.org
> > > Subject: SNAP progress and request for comment
> > >
> > >
> > >
> > > Hi all,
> > >
> > > As you know, a new SNAP draft has been submitted to (can be found in
> > > http://www.ietf.org/internet-drafts/draft-shapira-snap-02.txt).
> > >
> > > As one can recall, the SNAP describes a notification protocol
> between a
> > > Messaging Server (e.g. Email Server) and a Notification server
> > > (as specified
> > > in the draft).
> > >
> > > I would like to share some of the changes / decisions made and ask for
> > > comment on them:
> > >
> > > 1. Bind the SNAP to HTTP. This was a very big issue that we
> closed (after
> > > putting it in the SNAP mailing list). There where 3 alternatives:
> > > - HTTP
> > > - BEEP
> > > - No binding (and leaving the decision to the implementers).
> > > Comments?
> > >
> > > 2. Choose 2822 like as the format of the SNAP payload. Again,
> > > there where a
> > > few alternatives:
> > > - 2822 Like,
> > > - XML
> > > - In the HTTP query string (in the format of "attribute = value&)
> > > 2822 like format was chosen as it is more "friendly" to
> email servers.
> > > XML has a great deal of supporters as well so it was hard to
> > > decide. I would
> > > be happy to get comments.
> > >
> > > 3. Make sure that the SNAP is compatible with 2822.
> > >
> > > 4. Made sure that message-Context is compatible with
> > > http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-07.txt
> > >
> > > 5. Draft structural changes:
> > > - Added top-level requirements,
> > > - Partitioned the draft to 3 main part: Transport Layer, Semantics
> > > and format.
> > > - Better define the scope of the SNAP.
> > > - Added both IANA and Security considerations
> > > - Added extended terminology
> > >
> > >
> > > I would be happy to get comments and suggestions
> > >
> > > Thanks
> > >
> > > Noam
> > >
> > >
> > >
> >
> >
> >
>
>
This archive was generated by hypermail 2.0b3 on Thu Dec 13 2001 - 02:43:00 IST