[Notifications] Draft Minutes from IETF 69 meeting
Cullen Jennings <fluffy@cisco.com> Fri, 27 July 2007 22:19 UTC
Return-path: <notifications-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEY9w-0002N4-K3; Fri, 27 Jul 2007 18:19:44 -0400
Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEY9u-0002My-VT for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 18:19:42 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEY9u-0002Ml-J1 for notifications@ietf.org; Fri, 27 Jul 2007 18:19:42 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEY9t-0000pa-9m for notifications@ietf.org; Fri, 27 Jul 2007 18:19:42 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 18:19:40 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CADMMqkZAZnme/2dsb2JhbACwQQ
X-IronPort-AV: i="4.16,590,1175486400"; d="scan'208"; a="66385905:sNHT38372708"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6RMJeLh001175; Fri, 27 Jul 2007 18:19:40 -0400
Received: from [130.129.21.174] (rtp-vpn3-416.cisco.com [10.82.217.162]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6RMJZWI025105; Fri, 27 Jul 2007 22:19:40 GMT
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <FD1D6C4B-72AF-4A1C-9522-DCE02933086E@cisco.com>
Content-Transfer-Encoding: 7bit
From: Cullen Jennings <fluffy@cisco.com>
Date: Fri, 27 Jul 2007 17:19:28 -0500
To: notifications@ietf.org
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11418; t=1185574780; x=1186438780; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Draft=20Minutes=20from=20IETF=2069=20meeting |Sender:=20 |To:=20notifications@ietf.org; bh=Qut16qyAsccywwCJxb6VLmQSjuJ2i2g5fP3C3NcGUjQ=; b=c/W1iLhrU0mnydP22wQHtI0hd2zFfM+9H/6cxtMsxB3dcyqf9eqGNNpurPH5fC47gs8H8tF0 zD69zyYYh11TklKbpQYe1SR9tbZLR+Zmk+toRKhipLA8Sk7b1VdEA44x;
Authentication-Results: rtp-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472
Cc: Randall Gellens <randy@pensive.org>
Subject: [Notifications] Draft Minutes from IETF 69 meeting
X-BeenThere: notifications@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Message Notifications interest group discussion list <notifications.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/notifications>, <mailto:notifications-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/notifications>
List-Post: <mailto:notifications@ietf.org>
List-Help: <mailto:notifications-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/notifications>, <mailto:notifications-request@ietf.org?subject=subscribe>
Errors-To: notifications-bounces@ietf.org
Some draft minutes - thank you Dean for the notes. Please reply with text to fix any important mistakes, omissions, etc. before Aug 17. Thanks, Cullen ------------------------------------------------------------------------ -------------- Friday July 27, 2007 Palmer Hilton, Chicago Salon 2 Meeting chaired by Cullen Jennings, Randall Gellens Audio recording at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch7- fri-am.mp3 Attendance: roughly 30 people The key next steps is to bring together a set of use case. We would like the use cases to be separated in to priority 1 use cases that needed to be solved in the initial work a proposed WG, and priority 2 use cases that could be left to a second phase. The goal is to only have things in priority 1 where the contributor of the use case felt they the use case was absolutely critical and there was no way they could live without the use case in the first phase. These use case would be used to derive some requirements and determine if there are a bunch of common requirements that all the participants can work on or if there are N people with N different requirements. The requirements would then be used to check that Lisa's straw man architecture looked like a plausible way to meet the identified requirements. Lisa Dusseault, Scott Lawrence, Dave Crocker, Alexey Melnikov, Philip Guenhter, Robert Sparks, and Zoltan Ordogh agreed to provide text for use cases. Philip volunteered to collate them into a draft. Pete Resnick offered to provide wine to the folks providing use cases. From this point, Chris Newman would like to see us develop a draft charter then propose a WG forming BOF. Input documents would include: draft charter, use cases and start of requirements, start of architecture / model draft. ----- RAW NOTES ------------------------------------------------------------ Reported by Dean Willis Topic: Status and Agenda Bash Agenda accepted as presented. Cullen described the basic problem of the group as asynchronous notification about interesting things occurring at mail stores. Chris Newman reviewed the longstanding position of not entering this arena in the IETF. However, more recent developments in asynchronous notification services around SIP and JABBER/XMPP have made it appear more feasible. Andrew Allen asked if this work is scoped to SIP or other protocols like XMPP or anything else in CPP. Term "CPP" (Common Profile for Presence) clarified, as things like SIP events aren't necessarily CPP, even though the SIP events could ship presence. CPP isn't really the right term, but is used here as a placeholder. Topic: Analogy to CPP led by Lisa Dusseault Slides presented Noted that the filter layer would benefit from not having to do much in the way of email handling. Noted that the feature discovery mechanisms of SIP and XMPP could be used for tuning filters. Questions . . . . Pete Resnick shares discomfort with calling the notification aggregator an "hourglass". Both the email server and the client have lightweight connections. So what's the limiting factor here to keep the ends of the pipe tiny? Lisa believes the descriptive factor for the server interface is that the information sent should be reasonable for an email server to send on very message. An unstated goal is to extend this sort of architecture to other systems, such as databases. Question (Avshalom Houri): Is the scope of this group email only? Response from AD and Lisa: That remains to be determined. But the intent is to have a very simple initial design for email, knowing that it may be extended later. From Harald: The draft uses the word "folder" without defining it This may be too narrow. From Harald: The "narrow place in the architecture" might be called an "interface". Randy G suggests further that we concentrate on minimal state needed for email. Philip Noted that we have an interest in reusing the existing subscription channels of cell phones instead of holding a full imap connection all the time. There is an interesting use case when a client has lost connectivity and regains it. If the client is already going to connect to its notification service anyhow, the overhead of also connecting to the mail store to check for messages could be avoided. Tony Hansen raised question on time filtering, such as "If a mail from my boss comes in between nine and five, forward an extract to my cell phone". Suggested that we look at reliable notification on a larger scale. AD noted that this work item could be on the lemonade charter. Why isn't it? AD hopes it will be a template for other applications. But making things "generic" usually results in unachievable goals. This should be extensible, which is much easier to meet. Randall noted that we should keep it very simple, otherwise fast resync using IMAP might as well be used. Aki suggests that there is no real advantage to using UDP for notification, and that mobiles are actually better off using TCP. Debate continued on relationship to IM system. Noted that the architecture slide says "mail store", not "imap store". Noted by Zoltan that it has hard to bottle up the "state" of an email store, and easier to communicate a state change on that store. Including specifics of the data raises security issues. Dave Crocker suggests that documenting concrete scenarios as a first activity, along with constraints we believe those scenarios raise would help. Question: Do we have requirements for content protection and signing of notifications? Chris Newman holds this to be out of scope. Topic: Charter Led by Cullen Jennings Slides presented In addition to an architecture, a blast protocol, a schema, and a CPP binding, what should we produce? Crocker suggested scenarios. Discussion centered on difference between message-specific state and mail-store state, and which should be included in either blast or notification protocols. Noted that there are other things about messages, like size, encoding, etc. Rohan says he is confused as to whether the goal is the limited lemonade message data or something more elaborate. Harald thinks we are confusing requirements on blast with requirement on cpp. Blast should carry info about the cause of the event. Not so sure about CPP. Suggests also that client might be shielded from notification about statechanges caused by clients. Scott lawrence counters that users DO want immediate notification on states they change. Proposed that the BLAST protocol could be met by IMAP with subscribe. Rohan wonders if there is a watched-feature negotiation feature needed on the blast protocol. Chris Newman reminds us that the goal is to have a more generic-than- lemonade protocol on BLAST. Harald wonders why the blast protocol sends everything instead of filtering it, noting that this indicates that filtering should also be in the notification service and not in the client. Aki explains that the state controlling the "you have mail" indicator is not whether you have unread messages, but if you have unread messages that have been received since the last time the mailbox was visited. Lisa suggests that we could do things like switch from "message received" to "message received" and back again. Dave Crocker suggests we strive for a common subset that we clearly understand what they do. Cullen notes that a use-case document should be an early deliverable. Randall hopes we are NOT including MWI in the first release. Perhaps a "Something has changed and you should resynch. Zoltan asks if this connection is to be used with or without a concurrent IMAP connection? Discussion indicates that there are devices that are not IMAP clients but would like to indicate status of a mail store. Aki noted that not all email stores are imap. Dave Crocker suggests that the notification service should be very lean with no understanding of what is being sent. Zoltan asks "If you don't use IMAP, how do you activate the red light to start with?" The answer is "use a CPP subscribe mechanism". Lisa noted that it is important to not filter in the mail store in order to optimize performance. Pete Resnick refutes this, saying the message processing load on the notification service makes it need to know as much as an IMAP client would. Lisa argues that this could be at the CPP server. At heart, the concern is about what specific events are getting reported on BLAST, If everything that happens is reported, then somebody has to knot it back together. If only summary-level events are reported, then upstream becomes much easier. Cullen proposes that we work backward from use case to fan-out to notification service to blast protocol to mail store. Adam restates this as "BLAST must send not just events, but consequent states." Scott Lawrence emphasize that intelligence about data has to live were that data lives. Randall reminds us that goal was to reduce complexity on mail server, so it (BLAST) does only minimal sending of raw data -- events and current states. The notification service then determines who this goes to. Lisa reminds us that this architecture is based from buddy lists, and we have a hard time predicting now how many people might subscribe to state changes on a popular public mailbox or atom feed. But it all comes back to the use cases . . . . Chris reminds is that the mail store knows the mail store state and changes. The CPP instead is good at managing subscriptions and publications. This architectural distinction is good and necessary. Randall notes that instead of coming up with use cases, we need to narrow our scope of use cases to the minimal reasonable set. Dave Crocker suggests that what is missing from the diagram is a line between the mail store and the clients. This is apparently in the doc, not in the slides. Aki thinks that a major benefit of the blast protocol is the delegation for access to the state information from the mail store to the notification service. The access being delegated here is far more restricted than that which would be provided by full IMAP. Topic: What are Next Steps Pete worries that there may be thirty different use cases (in the room) based on the idea that BLAST does just exactly what they think it does. We have a big mismatch on the expectations and need to come to closer agreement here before. Agreed that we should settle on a narrow set of starter use cases. We also need to look at the authentication and delegation issues. Poll: Who would be willing to work on use cases: Lisa, Scott Lawrence, Dave Crocker, Alexey, Philip, Robert Sparks, Zoltan. Pete agrees to whine about other people's use cases. Philip volunteered to collate. People should also try to prioritize their use cases into "Phase 1, phase 2, phase 3". The mailing list "notifications@ietf.org" will be used for further work by this group. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications
- [Notifications] Draft Minutes from IETF 69 meeting Cullen Jennings
- Re: [Notifications] Draft Minutes from IETF 69 me… Eric Burger