SNAP - next steps

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D75D.35B71DDE
Content-Type: text/plain;
	charset="iso-8859-1"

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

------_=_NextPart_001_01C2D75D.35B71DDE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>SNAP - next steps</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the last IETF meeting there were a =
set of&nbsp; substantial pushback against SNAP that led me to conclude =
that the current draft is not ready for last call. Some of the =
pushbacks were: </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Security model is not =
sufficient</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Subscription/provisioning method - =
how the servers &quot;get to know each other&quot; - on a subscriber's =
basis</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- extensibility of the =
protocol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- The payload format</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- Etc.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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,</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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&nbsp; but the email server is from =
Email-SW-Vendor1 and the notification server is from =
Notification-SW-Vendor2</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The difference is clear. The first =
option probably needs to handle more issues like:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1. Security / Privacy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2. Provisioning / Subscription</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">3. User Profile (user =
identification)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Etc.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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 issue</FONT><FONT =
COLOR=3D"#008000" SIZE=3D2 FACE=3D"Arial">s</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"> 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. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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).</F=
ONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As I see it we have the following two =
alternatives:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. Go ahead with the current version - =
make sure that all disagreements are handled (possibly, creating a =
better basis for the first option).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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 &quot;smaller&quot; problem) and extend it, as =
required, after the new scope/requirements&nbsp; are formulated and =
agreed upon.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Your feedback is welcome,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Noam</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D75D.35B71DDE--
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo