Subject: [UM] FW: [VPIM] SNAP - next steps

From: Erev Ari <[email-masked]>
Date: Mon, 24 Feb 2003 10:35:28 +0200

Hi,
The following message did not appear on the Lemonade list, so I am
re-sending it for Noam.
Ari
-----Original Message-----
From: Shapira Noam 
Sent: Tuesday, February 18, 2003 4:51 PM
To: [email-masked]'; [email-masked]'; [email-masked]
Subject: [VPIM] SNAP - next steps

Hi, 

This note is sent to summarize the status of SNAP, as I see it, and to start
an open discussion on the list on how to proceed with it.

SNAP is now in it's sixth addition. During the last eighteen months, we have
worked in the SNAP and VPIM mailing list in order to build what we think is
a good notification protocol for mailbox-related/messaging event. During
this time, the SNAP was a working draft that incorporated the changes that
were agreed by the different participants in the mailing lists. There were
some objections but they were resolved in the IETF meetings. Some of the
members in the VPIM working group have suggested that we should go on and
send the draft to IESG last call.

In the last IETF meeting there were a set of  substantial pushback against
SNAP that led me to conclude that the current draft is not ready for last
call. Some of the pushbacks were: 

- Security model is not sufficient 
- Subscription/provisioning method - how the servers "get to know each
other" - on a subscriber's basis 
- extensibility of the protocol 
- The payload format 
- Etc. 

Some of these pushbacks were already raised and can be reopened if the forum
wishes to do so. Other pushbacks, as I see it, can be pointed to a core
problem - the scope of the SNAP. There are two alternatives for SNAP scope:

1. Where the Messaging server and the Notification server are provided by
two different service providers (e.g. the email server is held by
myemail.com and the notification service by notification.com). Or,

2. Where the Messaging server and the Notification server are provided by
the same service provider but not necessarily the same manufacture (e.g.
both servers are held by service-provider.com  but the email server is from
Email-SW-Vendor1 and the notification server is from Notification-SW-Vendor2

The difference is clear. The first option probably needs to handle more
issues like: 
1. Security / Privacy 
2. Provisioning / Subscription 
3. User Profile (user identification) 
Etc. 

The current draft (maybe with a few small changes) - is suitable for the
second scope (common service provider). It is interesting in maintaining an
open messaging system - providing the ability to integrate between an email
server and a notification server. In this scenario, issues like
provisioning, security, persistent connection and other issues can be
handled as part of the integration in the service provider site. I think
that this draft can be a very good basis to start working on the first
option as well. 

Further, the SNAP current scope deals only with messaging notification - it
is not a general purpose notification protocol. It might be the basis for a
general purpose protocol - but, after consulting with some of the members of
the mailing list - we have decided to limit it to messaging scope (only).

The current version has a clear use-case and it was acknowledged in the two
mailing lists - but, as I see it, this issue was re-opened.

As I see it we have the following two alternatives: 
1. Stopping the current SNAP work - and starting (from scratch?) on a more
general-purpose notification protocol, (using a different set of basic
assumptions and requirements) - for solving Scope 1.

2. Go ahead with the current version - make sure that all disagreements are
handled (possibly, creating a better basis for the first option).

My opinion is that we should go with the second option - going ahead with
the current version. It answers a real need in the field, and it can be
closed by the 57th IETF meeting.

Taking the route of the first option (Re-start with a different set of
requirements) takes us few years back. Solving the larger problem (which is
not yet even well-defined) may take pretty long time, and be quite complex
(if it to solve all the new requirements). While I do not object for such an
effort to take place, I suggest it could be done in stages. Start with the
current draft (to solve a "smaller" problem) and extend it, as required,
after the new scope/requirements  are formulated and agreed upon.

Your feedback is welcome, 

Thanks, 

Noam