Re: SNAP - next steps

> 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.

That's not how the process works. The process is that the group can forward the
document to the AD in change -- me -- and if I approve of it it will then go to
the IESG. And let me say right now that there's absolutely no way I would sign
off on this document coming from VPIM. And even if I did sign off, I view the
chances of this document being approved by the IESG in its present form as
nonexistant.

> 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.

Exactly. Additionally, the document is listed as work item for the proposed
LEMONADE working group. Nor does this work appear as a deliverable for VPIM.
While the technical issues are substantive, so are the process ones.

> 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

> ...

> 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.

I doubt very very much that this is the case. Even if you were to address the
outstanding technical issues by reducing the scope -- something I am far from
convinced is possible -- there's still the process issue to be dealt with. Like
it or not, this topic has been proposed as a work item for a new working group.
That alone argues quite forcefully for not trying to shortcut the process.

				Ned
----------------------------------------------------------
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