Subject: [UM] SNAP - next steps

From: Shapira Noam <[email-masked]>
Date: Tue, 25 Feb 2003 16:22:00 +0200

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

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 28 Feb 2003 14:46:38 -0500

Here is the key issue that I am stuck on:

Original Message From: Shapira Noam [mailto:[email-masked]] Sent: Tuesday, February 25, 2003 9:22 AM
[snip]
> 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 

I would offer that situation 2 is explicitly not the kind of protocol the IETF publishes.  The issues listed for situation 1 ARE the issues listed that a real Internet solution needs to address.  I would liken this situation to the one raised by the Security Considerations draft from the IAB 
<http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt>.  From the draft:

   Internet protocol designers cannot safely assume
   that their protocols will be deployed in such an
   environment [a walled garden], for three reasons.
   First, protocols which were originally designed
   to be deployed in closed environments often are
   later deployed on the Internet, thus creating
   serious vulnerabilities.

   Second, networks which appear to be topologically
   disconnected may not be. One reason may be that
   the network has been reconfigured to allow access
   by the outside world. Moreover, firewalls are
   increasingly passing generic application layer
   protocols such as [SOAP] or [HTTP].  Network
   protocols which are based on these generic
   protocols cannot in general assume that a firewall
   will protect them.

Although the second paragraph is speaking specifically about firewalls, I would offer the issues are identical for notification protocols.  Protocol proposals, to be an IETF protocol, must address INTERNET requirements.
-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/um_archive/maillist.html