RE: SNAP - next steps
Shapira Noam <[email protected]> Tue, 18 Feb 2003 19:54:48 +0200
| Newsgroups | gmane.ietf.vpim |
|---|---|
| Message-ID | <767720C6032ED511AE8C00508BE3518E0756FB6C@ISMAILWEB> |
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_01C2D776.D41B84E2 Content-Type: text/plain; charset="iso-8859-1" Ned, I am afraid I didn't explain my self well. I apologize. I didn't mean to imply that the draft should be submitted as part of the VPIM charter, nor did I say that it is should not be part of the Lemonade charter. All I was trying to do is open a technical discussion on the way SNAP should be modified technically - not process-wide. Noam -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, February 18, 2003 7:06 PM To: Shapira Noam Cc: '[email protected]'; '[email protected]'; [email protected] Subject: Re: [VPIM] 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 ------_=_NextPart_001_01C2D776.D41B84E2 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>RE: [VPIM] SNAP - next steps</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Ned,</FONT> </P> <P><FONT SIZE=3D2>I am afraid I didn't explain my self well. I = apologize.</FONT> </P> <P><FONT SIZE=3D2>I didn't mean to imply that the draft should be = submitted as part of the VPIM charter, nor did I say that it is should = not be part of the Lemonade charter.</FONT></P> <P><FONT SIZE=3D2>All I was trying to do is open a technical discussion = on the way SNAP should be modified technically - not = process-wide.</FONT></P> <P><FONT SIZE=3D2>Noam</FONT> </P> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: [email protected] [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>] = </FONT> <BR><FONT SIZE=3D2>Sent: Tuesday, February 18, 2003 7:06 PM</FONT> <BR><FONT SIZE=3D2>To: Shapira Noam</FONT> <BR><FONT SIZE=3D2>Cc: '[email protected]'; '[email protected]'; = [email protected]</FONT> <BR><FONT SIZE=3D2>Subject: Re: [VPIM] SNAP - next steps</FONT> </P> <BR> <P><FONT SIZE=3D2>> This note is sent to summarize the status of = SNAP, as I see it, and to </FONT> <BR><FONT SIZE=3D2>> start an open discussion on the list on how to = proceed with it.</FONT> </P> <P><FONT SIZE=3D2>> SNAP is now in it's sixth addition. During the = last eighteen months, </FONT> <BR><FONT SIZE=3D2>> we have worked in the SNAP and VPIM mailing = list in order to build </FONT> <BR><FONT SIZE=3D2>> what we think is a good notification protocol = for </FONT> <BR><FONT SIZE=3D2>> mailbox-related/messaging event. During this = time, the SNAP was a </FONT> <BR><FONT SIZE=3D2>> working draft that incorporated the changes = that were agreed by the </FONT> <BR><FONT SIZE=3D2>> different participants in the mailing lists. = There were some </FONT> <BR><FONT SIZE=3D2>> objections but they were resolved in the IETF = meetings. Some of the </FONT> <BR><FONT SIZE=3D2>> members in the VPIM working group have = suggested that we should go on </FONT> <BR><FONT SIZE=3D2>> and send the draft to IESG last call.</FONT> </P> <P><FONT SIZE=3D2>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.</FONT></P> <P><FONT SIZE=3D2>> In the last IETF meeting there were a set = of substantial pushback </FONT> <BR><FONT SIZE=3D2>> against SNAP that led me to conclude that the = current draft is not </FONT> <BR><FONT SIZE=3D2>> ready for last call. Some of the pushbacks = were:</FONT> <BR><FONT SIZE=3D2>> - Security model is not sufficient</FONT> <BR><FONT SIZE=3D2>> - Subscription/provisioning method - how the = servers "get to know each </FONT> <BR><FONT SIZE=3D2>> other" - on a subscriber's basis</FONT> <BR><FONT SIZE=3D2>> - extensibility of the protocol</FONT> <BR><FONT SIZE=3D2>> - The payload format</FONT> <BR><FONT SIZE=3D2>> - Etc.</FONT> </P> <P><FONT SIZE=3D2>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.</FONT></P> <P><FONT SIZE=3D2>> Some of these pushbacks were already raised and = can be reopened if the </FONT> <BR><FONT SIZE=3D2>> forum wishes to do so. Other pushbacks, as I = see it, can be pointed to </FONT> <BR><FONT SIZE=3D2>> a core problem - the scope of the SNAP. There = are two alternatives for </FONT> <BR><FONT SIZE=3D2>> SNAP scope: 1. Where the Messaging server and = the Notification server </FONT> <BR><FONT SIZE=3D2>> are provided by two different service providers = (e.g. the email server </FONT> <BR><FONT SIZE=3D2>> is held by myemail.com and the notification = service by </FONT> <BR><FONT SIZE=3D2>> notification.com). Or, 2. Where the Messaging = server and the </FONT> <BR><FONT SIZE=3D2>> Notification server are provided by the same = service provider but not </FONT> <BR><FONT SIZE=3D2>> necessarily the same manufacture (e.g. both = servers are held by </FONT> <BR><FONT SIZE=3D2>> service-provider.com but the email server = is from Email-SW-Vendor1 </FONT> <BR><FONT SIZE=3D2>> and the notification server is from = Notification-SW-Vendor2</FONT> </P> <P><FONT SIZE=3D2>> ...</FONT> </P> <P><FONT SIZE=3D2>> My opinion is that we should go with the second = option - going ahead </FONT> <BR><FONT SIZE=3D2>> with the current version. It answers a real = need in the field, and it </FONT> <BR><FONT SIZE=3D2>> can be closed by the 57th IETF meeting.</FONT> </P> <P><FONT SIZE=3D2>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.</FONT></P> <P> = = = <FONT SIZE=3D2>Ned</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C2D776.D41B84E2-- ---------------------------------------------------------- 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