[10:03:11] --- cyrus_daboo has joined
[10:03:27] --- cyrus_daboo has left
[10:03:31] --- harald has joined
[10:03:58] --- dwillis@jabber.org has joined
[10:04:31] --- dcrocker has joined
[10:05:01] --- cnewman@jabber.org has joined
[10:05:09] --- guenther has joined
[10:05:23] --- cyrus_daboo has joined
[10:06:10] --- Adam Roach has joined
[10:06:38] --- Adam Roach has left
[10:08:19] --- Adam Roach has joined
[10:08:40] --- akiniemi has joined
[10:09:21] <akiniemi> I guess I can scribe
[10:09:36] <akiniemi> Cullen: Goal is not to do IMAP over SIP
[10:09:58] <akiniemi> Chris: this has been a long standing problem that has gone unsoved
[10:10:45] <akiniemi> Cullen: Lisa will present next a straw-man architecture for this
[10:11:03] --- tonyhansen has joined
[10:11:06] <akiniemi> Andrew: Question: is this scoped only to SIP or other CPP protocols like XMPP?
[10:11:27] <akiniemi> Cullen: Scope is all CPP (event sub-pub type) systems
[10:11:43] --- resnick has joined
[10:11:52] --- resnick has left
[10:11:55] <akiniemi> Lisa presenting the slides
[10:11:59] --- resnick has joined
[10:13:03] <akiniemi> Lisa: biff has analogy to the CPP (Common Profile for Presence)
[10:13:19] <akiniemi> Lisa: CPP = XMPP and SIMPLE so far
[10:13:40] <akiniemi> Lisa: These two have differences, and the straw-man discusses these
[10:14:53] --- alexeymelnikov has joined
[10:15:30] --- ekr has joined
[10:15:39] <akiniemi> [sorry, was plugging in power]
[10:16:24] <akiniemi> Lisa: Architecture includes the email server using a very simple BLAST (aka SPEW) protocol to send events to notification service
[10:16:29] --- randy has joined
[10:16:44] <akiniemi> Lisa: Notification service then does the fan-out to subscribers
[10:18:46] <akiniemi> Lisa: this is the choke point or abstraction between notification system and the event source
[10:19:40] <akiniemi> Lisa: vast amount of state in the email server
[10:20:09] <randy> (not "choke point")
[10:20:10] <akiniemi> Lisa: notification server has also state, and these are related
[10:20:30] <guenther> (earlier, regarding "CPP", Robert Sparks suggested that we avoid that term in general, as it has a specific meaning in the SIP world at least, requiring carrying of PIDF [sic?], which is not involved here)
[10:21:22] <akiniemi> Lisa talking about filtering of events based on what subscribers want to receive
[10:21:38] <akiniemi> Lisa: goal is to meet 80% of the cases with something simple
[10:21:59] <akiniemi> Lisa: going much further might mean a scripting language
[10:22:17] <akiniemi> Lisa: Rohan has a proposal for using Sieve scripts with subscriptions
[10:23:00] <akiniemi> Lisa talks about reliability goals
[10:23:19] <akiniemi> Lisa: reasonable accuracy of information
[10:23:49] <akiniemi> Lisa: clients must also detect activity: "You have mail!"
[10:25:44] <akiniemi> Lisa: clients trade off reliability and implementation cost
[10:26:20] <akiniemi> Lisa: event schema design is important
[10:27:36] <akiniemi> Lisa: Need to define state as well as state changes (new message vs. 108 new messages await)
[10:27:58] <akiniemi> Lisa: gmail notification bar applet seems to poll every minute!
[10:28:56] <akiniemi> Pete: to be successful, this can not be replaced by client simply connecting with email server
[10:29:29] <akiniemi> Pete: not seeing how this is kept lightweight -- both on the email server blasting notifications out, and the client collecting them
[10:30:25] <dcrocker> Using a model that has the email server send a single notice to an IM presence server, which in turn fans it out makes this start sounding like IM 2.0 (a la Web 2.0). That's not necessarily a bad thing.
[10:30:47] --- dcrocker has left
[10:33:10] <akiniemi> Cullen: would it be reasonable to set out some constraints to what data should be included?
[10:33:43] <akiniemi> [discussion follows]
[10:33:51] <akiniemi> Avshalom: is email the only usage for this?
[10:34:27] <akiniemi> Cullen: something the bof is to find out
[10:34:53] <akiniemi> Lisa: (speaking not as AD) designing the schema is easier if we focus on email service only
[10:36:25] <akiniemi> Harald: architecture draft is using term folder, but doesn't specify it
[10:39:57] <akiniemi> Randall: suggests doing something very simple (just number of messages, read, deleted)
[10:41:11] <akiniemi> Philip: using this might optimize radio usage on mobile phones
[10:43:58] <akiniemi> Tony: clients want to be able to do time based filtering etc.
[10:44:45] <akiniemi> Zoltan: wants the WG to generalize and not focus on email only
[10:45:23] <akiniemi> Lisa: Experience has been that requirements get out of control if we generalize
[10:45:58] <akiniemi> Chris: (as AD) this work is already in lemonade charter; wants this to be a template for other apps
[10:46:18] <akiniemi> Chris: but experience tells open-ended problems won't get solved
[10:55:16] <akiniemi> [scribe was at the mic]
[10:56:18] <randy> Clarification: I believe we're discussing state-change announcements from a mail store, not notifications
[10:56:22] <randy> Big difference in scope
[10:57:10] --- harald has left
[10:57:16] <randy> Also, if we include any message-specific data in the state-change announcements (such as to, from, subject, size) we get into problems if state-change announcements are lost or more than one comes in at the same time
[10:57:52] <cyrus_daboo> You also have a much bigger security problem if you start including specifics of the actual data.
[10:58:10] <randy> Cyrus -- absolutely right
[10:58:11] <resnick> <sarcasm>Everyone sure we don't want http://www.rfc-editor.org/rfc/rfc1339.txt</sarcasm>
[10:58:40] <cyrus_daboo> Security really hasn't been mentioned so far, but it is going to be a big part of this.
[10:58:40] <Adam Roach> Randy: perhaps we've confounded two concepts in what we've been doing so far, but I can't tease out any difference between the two terms "state-change announcements" and "notifications".
[10:59:24] <randy> I see an important distinction in use cases between a client that has been off for a while (overnight or long tunnel, e.g.) and a client that is around but doesn't have a TCP connection to the mail store
[10:59:53] <randy> Adam--notifications implies a general problem, with larger scope, and lots of baggage
[10:59:58] <randy> At least as I see it
[11:00:12] <akiniemi> Zoltan: question about signing and encryption of notifications
[11:00:54] --- dcrocker has joined
[11:00:55] <Adam Roach> Ah, okay. I see. So you're using one term to scope the problem down to email. Gotcha.
[11:00:59] <akiniemi> Lisa: this is what the CPP protocol should provide
[11:02:34] <akiniemi> Chris: signing and encryption or BLAST protocol is in scope; signing and encryption of the CPP protocol is out of scope
[11:02:51] <akiniemi> Cullen: deliverables discussion
[11:05:08] <akiniemi> Cullen showing the proposed draft charter
[11:05:21] <akiniemi> Cullen: goal is not to wordsmith the charter now
[11:08:44] <akiniemi> Chris: if BLAST could not be extended to carry message-specific state, it would be misdesigned
[11:10:38] <akiniemi> Rohan: is the goal to get only raw events, or something more?
[11:11:16] <akiniemi> Harald: seems we're mixing requirements of the BLAST protocol and the CPP protocol
[11:12:39] <akiniemi> Harald: I might want to get notifications of unread messages, but not the state changes caused by me reading the messages
[11:15:18] <akiniemi> Pete: why is the BLAST protocol *not* IMAP?
[11:16:14] <resnick> More precisely, *if Harald is right*, why isn't the BLAST protocol IMAP?
[11:16:44] <akiniemi> Correct.
[11:17:00] <tonyhansen> what do we want beyond "sieve with notification extensions"?
[11:17:15] --- Qian has joined
[11:17:23] <tonyhansen> where sieve is sitting in the MTA
[11:17:27] <tonyhansen> /MDA
[11:18:04] <randy> To me, Harald's point underscores my distinction between the use cases: announcing interesting kicker events to a mail client is very different from sending current state to a non-mail-client status bar
[11:18:53] <randy> Lisa's status bar does need a constantly-updated count of unread messages, so it can do down as you read mail
[11:19:22] <randy> An inactive client doesn't need to know if the unread message count goes down
[11:19:57] <akiniemi> Chris: (answering Pete's question of why BLAST is not IMAP) because this is supposed to be a template for other apps like CalDAV
[11:23:19] <alexeymelnikov> Is work on payload format (considering Harald's comment) for the CPP side in scope? What about protocol bindings for the CPP side?
[11:23:59] <alexeymelnikov> Chris told me that it is out of scope, but I would like to know what other people think.
[11:26:33] <akiniemi> Dave: working on use-cases we need to be careful of what the target market is
[11:31:28] <akiniemi> [scribe dropping packets due to thinking ;)]
[11:34:14] <alexeymelnikov> Chris: an IMAP client wouldn't want to implement CPP, while a non-IMAP client wouldn't want to implement IMAP
[11:34:26] <akiniemi> Pete: if BLAST gives out all possible events, then the complexity of the notification service increases a lot
[11:35:15] <randy> Pete's point is that the complexity goes way up if the notification hub needs to interpret raw events and determine MWI status
[11:38:29] <akiniemi> Dave: also worried about the complexity and bandwidth requirements of BLAST
[11:39:13] <akiniemi> Cullen: suggesting a bottom-up approach: first design the schema, then see what BLAST needs to provide
[11:40:50] <akiniemi> Adam: BLAST not only needs to deliver the state changes, but also the resulting configuration; otherwise if the link goes down, everything is lost
[11:42:24] --- Qian has left
[11:42:31] <akiniemi> Scott: intelligence needs to be where the data is
[11:42:33] --- Qian has joined
[11:46:23] <akiniemi> Lisa: architecture supports the presented use-cases
[11:50:04] <alexeymelnikov> Chris: mailstore is good in manipulating mail state and changes to mail state, CPP systems are good in deciding what to send, where and how. They have different speciality. If we start moving CPP functions to mailstore, complexity of the system goes up
[11:51:02] <alexeymelnikov> Randy: we need to "come down" with use cases, not generate more of them
[11:53:51] <randy> Several people commented on the roles of the entities: mail store sends raw events and simple aggregate state, notification determines which clients are authorized to get the information and which have subscribed to it, and sends to them
[11:56:30] --- cnewman@jabber.org has left
[11:57:13] <akiniemi> Aki: one of the benefits of the BLAST protocol is that it would allow delegating limited access to the client's mail store to the notification service
[11:58:11] <akiniemi> Eric: this is important work
[11:58:21] <randy> Aki--I proposed that in Prague, wrote it up, and sent it to the list, take a look and see if it is what you are thinking of
[11:58:43] <akiniemi> Thanks for the pointer Randall. I'll go look it up.
[11:58:53] <randy> Aki--the proposal takes advantage of the URLauth extension to IMAP to allow for the delegation
[11:59:41] <randy> It was sent to ietf-notifications on March 22 with subject "Notifications Pictures"
[12:03:04] <randy> Pete points out that it all comes down to what is carried in BLAST
[12:04:12] <akiniemi> Cullen looking for people to work on the use-cases
[12:04:56] <Qian> from user's view, I just want get notification of urgent emails or emails from special buddies. not each email or count of email, I cannot remember the number.
[12:09:05] <akiniemi> Cullen: aiming at a WG-forming BoF in Vancouver
[12:09:47] <akiniemi> Mailing list is at: notifications@ietf.org
[12:09:53] --- cyrus_daboo has left
[12:10:17] --- akiniemi has left
[12:11:20] --- dcrocker has left
[12:11:24] --- guenther has left
[12:11:27] --- Qian has left
[12:11:44] --- alexeymelnikov has left
[12:12:31] --- randy has left
[12:19:05] --- dwillis@jabber.org has left
[12:20:19] --- resnick has left
[12:20:44] --- ekr has left
[12:21:07] --- Adam Roach has left: Computer went to sleep
[12:32:32] --- tonyhansen has left: Replaced by new connection