[09:49:24] --- bernard.desruisseaux has joined
[09:53:48] --- eburger has joined
[09:54:48] --- alexeymelnikov has joined
[09:54:57] <eburger> /topic notifications
[09:55:04] <alexeymelnikov> Morning
[09:55:13] <eburger> Good Morning!
[09:55:34] <bernard.desruisseaux> Good morning!
[09:58:16] --- Glenn Parsons has joined
[09:58:27] --- Dave Cridland has joined
[09:58:38] <Dave Cridland> Afternoon.
[10:01:18] <eburger> It's 7am PT, but there are only 5 of us so far, and 2 don't count. Shall we wait another 5 minutes?
[10:01:58] <alexeymelnikov> Yes
[10:02:16] <alexeymelnikov> I am not going to argue to Dave about notifications anyway ;-)
[10:04:06] --- ams has joined
[10:04:15] <ams> y
[10:04:34] <ams> oops.
[10:04:40] <eburger> Arnt - you have the "login of the day" :-)
[10:04:53] <alexeymelnikov> That is not Arnt
[10:04:57] <eburger> who is it?
[10:05:11] <eburger> (I took the "a" in ams for Arnt. My mistake)
[10:05:12] <ams> <- abhijit menon-sen
[10:05:18] <eburger> cool. Welcome!
[10:05:44] --- Lisa has joined
[10:05:46] --- arnt has joined
[10:05:54] <eburger> Good morning Lisa (yawn!)
[10:05:56] <Lisa> Morning
[10:06:00] <eburger> (Yes, I'm in CA)
[10:06:04] <Dave Cridland> Lisa: Feeling any better?
[10:06:39] --- rohan has joined
[10:06:39] <Lisa> not yet... still got a cold plus my morning coffee is not quite yet in my hands
[10:06:56] <rohan> sorry i'm late
[10:06:59] <arnt> Lisa: it will get worse, trust me.
[10:07:36] <Lisa> thanks for the good cheer :)
[10:07:56] <eburger> Don't worry Rohan; we're like bi-modal: a bunch of Europeans in the afternoon and a bunch of us in California.
[10:08:17] <eburger> 9 people total; should we wait for more to get a minyan?
[10:08:19] <arnt> lisa, well, you don't have much of a choice any more, so we can reveal the awful truth now ;)
[10:08:54] <alexeymelnikov> Arnt has to disappear in 20 minutes
[10:09:03] <eburger> Then let's get started.
[10:09:24] <eburger> I think it was Dave who had some ideas on goals and scope?
[10:09:36] <Dave Cridland> Erm.
[10:09:50] <eburger> Or was it Alexey (who agrees with you, anyway)
[10:09:53] <alexeymelnikov> Too bad there is nobody from Oracle in jabber
[10:10:06] <Dave Cridland> Well, I suppose the first thing to do is decide on exactly what sort of notifications we want to target.
[10:10:06] <alexeymelnikov> I point finger to Dave :-)
[10:10:12] <eburger> They are not on line anywhere.
[10:10:31] <eburger> So, we have new message notification...
[10:10:48] <eburger> mailbox state change notification
[10:10:55] <eburger> others?
[10:11:27] <rohan> possibly out of scope for us, but file updated notifications
[10:11:33] <alexeymelnikov> And we have new message notification with different degrees of details
[10:11:56] <arnt> this all sounds as if I'm document editor.
[10:12:08] <Dave Cridland> Well, I think Randy basically suggested that we've a spectrum of notifications here, depending on whether we're aiming for a simple MWI, or a way to avoid clients from synchronizing.
[10:12:10] <arnt> why does shit always have to happen to me?
[10:12:13] <eburger> That's because you haven't said anything :-)
[10:12:40] <eburger> I'm worried about "avoid clients from sync". Is that an open door to IMAPv5?
[10:12:48] <Dave Cridland> I'm worried about it too.
[10:13:02] <alexeymelnikov> +1
[10:13:06] <Lisa> Any reason we're not talking about the events in http://tools.ietf.org/id/draft-newman-lemonade-msgevent-00 ?
[10:13:27] <eburger> I'm glad someone is awake!
[10:13:45] <eburger> 4.1 & 4.2 are message status
[10:13:51] <Dave Cridland> The other key document in the OMA MEM REQs doc.
[10:13:52] <eburger> 4.3 is where things get weird
[10:13:59] <Glenn Parsons> or even the review of notifications for LEMONADE draft-ietf-lemonade-notifications-03.txt
[10:14:32] <arnt> (I can stay. my wife will run from her office right now and pick up childe sofie from kindergarten.)
[10:15:07] <eburger> Any thoughts on what makes sense?
[10:15:17] <eburger> (besides not abandoning poor Sofie :-)
[10:16:13] <Glenn Parsons> the draft I noted was more of the architecture...
[10:16:16] <arnt> are we talking about notifications in the context of a momentarily connected client, an unconnected user, or both? maybe it was specified before I joined.
[10:16:23] <alexeymelnikov> Account access are interesting for enterprises or ISPs, but I am not sure it is in scope for the Lemonade. At least not directly
[10:16:38] <Dave Cridland> arnt: I think we're mostly concerned with OOB notifications.
[10:16:48] <Glenn Parsons> I think the issue is really the content of the notification
[10:17:37] <rohan> there are clearly different communities of interest for the notification events mentioned in the newman draft
[10:17:55] <rohan> how does a subscriber indicate which events they care about?
[10:18:36] <Glenn Parsons> I am talking about out of band notifications
[10:18:44] <eburger> On the communities of interest: I think that the Compliance community may be better served by a different mechanism, like we have SMS + diameter in the IMS world.
[10:18:44] <Lisa> if we're talking about a BoF on email event notifications, we can indeed talk about OOB, real-time, different notification transports.
[10:18:45] <Glenn Parsons> and we were talking at one point
[10:19:05] <Glenn Parsons> about using SIEVE to configure the events....
[10:19:35] <alexeymelnikov> And there are proposals to configure events in IMAP as well
[10:19:39] <arnt> there's a fine sieve draft which seems to preempt most discussion of OOB notifications...
[10:19:43] <rohan> well certainly my draft proposes using sieve to filter newmessage and appendmessage notifications
[10:20:00] <rohan> (for SIP)
[10:20:23] <alexeymelnikov> Rohan: what is the name of your draft?
[10:20:58] <Lisa> my preference had been *not* to use SIEVE because I imagined it would be too hard to use it to turn on and off notifications at the frequency one would need. But Ted convinced me last month that there were use cases where that frequency was appropriate.
[10:21:45] <Lisa> I imagined a system where the filter (what kind of notifications to get) would be sent in a SUBSCRIBE message, which could be followed by an unsubscribe any time later, rinse, repeat.
[10:22:04] <Lisa> But I sent mail on the authentication weaknesses of both approaches (mirrored)
[10:22:31] <alexeymelnikov> Speaking specifically on Sieve: there is no requirement that the client rewrites Sieve script each time it wants to turn notification on/off. In some cases it is sufficient just to make another script active (e.g. using managesieve or other mechanism)
[10:22:34] <rohan> draft-mahy-sieve-notify-sip-00
[10:23:00] <Lisa> http://www1.ietf.org/mail-archive/web/notifications/current/msg00019.html for anybody who's not on the mailing list
[10:23:11] <Dave Cridland> alexeymelnikov: Doesn't that require a client to know which script means "notify me", and which does not? How do multiple devices know how to coordinate?
[10:23:13] <rohan> http://svn.resiprocate.org/rep/ietf-drafts/rohan/email-event/draft-mahy-sieve-notify-sip-00.html
[10:23:34] <Lisa> yeah, the multiple devices thing worries me with the SIEVE approach.
[10:24:07] <alexeymelnikov> Dave: yes, there must be some convention about script names
[10:24:38] <rohan> If you have multiple devices each with an explicit subscription model, it is easy to have orthogonal sieve filters for each subscription
[10:24:44] <Dave Cridland> Lisa: Oh, it doesn't rule out Sieve for me, it suggests that we might consider having Sieve notify a Thing, which in turn the notification subscribers talk to to turn on and off notifications as a whole.
[10:24:55] <Lisa> good
[10:25:48] <arnt> lisa, others: I mad a comment on the sieve draft that it is desirable to notify differently depending on whether the user is online via imap etc.
[10:25:53] <rohan> i suspect we have use cases for both a) all subscribers are interested in the same events, and b) each subscriber wants something different
[10:27:01] <arnt> don't want my mobile phone to beep every time I've just read a new email to tell me that that new email just arrived, so it's highly desirable to send such things only when I'm not reading mail.
[10:27:12] <Dave Cridland> rohan: I think you generate the notifications in a single per-user sieve script, then subscribe to the notifications outside of that.
[10:27:28] <arnt> what dave says makes sense to me.
[10:27:28] <Lisa> I must have missed that because I'm not sure I agree. If my calendar client has a SIEVE script set up to send new message notifications with iCalendar attachments, then it hardly matters whether my email client is online with IMAP or not, the calendar client still wants those notifications.
[10:27:43] <Dave Cridland> arnt: Yes, true, but that also requires that you don't leave your IMAP client running and connected when you leave the desk.
[10:27:57] <arnt> lisa, dave: one size never fits all.
[10:28:14] <Dave Cridland> arnt: With sufficient lycra, anything is possible. :-)
[10:28:15] <arnt> the requirements of a calendar client are not those of a human holding a mobile phone in his hand.
[10:29:20] <alexeymelnikov> Right, Sieve notify action has to be sufficiently powerful to be usable for both cases
[10:30:07] <arnt> fsck.
[10:30:07] <rohan> Dave: I don't get it. If my mobile wants to know when I get a contract proposal from acmewidgets.com and none of my email clients are running, who is running the sieve script?
[10:30:19] <Dave Cridland> rohan: The server.
[10:30:28] <arnt> the program that delivers the mail to your mailbox.
[10:30:33] <arnt> MDA
[10:30:35] <Dave Cridland> rohan: That's usually where it runs today.
[10:31:02] <rohan> then why does it matter if I subscribe the notifications with the sieve script in-band or out-of-band?
[10:31:28] <arnt> because the sieve script can do much more than just list some subscriptions. it usually does.
[10:32:02] <rohan> if i have a named script i configured out-of-band i want to be able to reference it, but surely its useful to just include one when you subscribe
[10:33:19] <rohan> i think y'all are assuming that these sieve scripts are going to be much more semi-permanently relevant to a mobile subscriber than I was imagining
[10:33:29] <arnt> yes...
[10:33:58] <arnt> sieve scripts tend to stay around for a long time.
[10:34:11] <arnt> and that makes sense. don't want to mess with mail delivery configuration very often.
[10:34:17] <Lisa> what would be a use case for a subscription that's only interesting for a short while?
[10:34:26] <arnt> notification could be much more volatile.
[10:35:01] <rohan> a) i want to be disturbed when someone sends email to me about a specific thread that I am watching carefully
[10:35:07] <Lisa> besides the notiion of turning the subscription off and on when you want to be bothered or not, I mean
[10:35:25] <rohan> b) i want to get any email from such and such user who is arriving today
[10:35:58] <rohan> c) i want to get any email canceling or updating any meeting i have the same day
[10:36:29] <rohan> exactly Lisa.
[10:37:03] <rohan> the specific details that I am interested in with these 3 examples are inherently dynamically built extremely volatile sieve scripts
[10:37:46] <alexeymelnikov> Rohan: The Sieve script can be relatively static, pulling in data from dynamic sources
[10:38:06] <alexeymelnikov> such as presence, LDAP/IMAP AnnotateMove/ACAP/WebDav
[10:38:29] <alexeymelnikov> I guess I like the idea of templating :-)
[10:38:33] <arnt> alexeymelnikov: "concerns today's date"? "user is on duty"? in sieve tests?
[10:38:45] <Lisa> I am not sure that will be everybody's most obvious choice Alexey!
[10:38:46] <Dave Cridland> The problem with dynamic filtering in SIeve is that the scripts are currently write-only, in as much as nobody's yet to machine edit them. That might be solely because a UI is too complex, of course.
[10:39:09] <rohan> it could, but is this really "better" than having my mobile make a straightforward sieve script with real data in it, sending somewhere to be used for a day or two and then deleting the script?
[10:39:13] <arnt> my friend bret would want all email concerning server downtime at his site. but he'd want to be notified only if he's on duty for that machine.
[10:39:30] <Lisa> Ideally a lot of notifications are much simpler than needing a rule language to express. E.g. SUBSCRIBE to <url> for <event-type>.
[10:39:40] <arnt> Dave Cridland: what? write only? I didn't notice that ;)
[10:39:44] <alexeymelnikov> "on duty" can be an attribute in LDAP or presence :-)
[10:39:45] <rohan> certainly the security sandbox is more straightforward with hard coded scripts
[10:40:25] <rohan> you can even limit the sieve actions in the sandbox so you can't redeliver, delete, or file email
[10:40:57] <alexeymelnikov> Rohan: right
[10:41:44] <alexeymelnikov> Can we go one level back?
[10:42:06] <rohan> please
[10:42:28] <alexeymelnikov> There were several proposals to control generation of notifications: using Sieve, using IMAP
[10:43:02] <alexeymelnikov> I personally like different for different tasks
[10:43:05] <Lisa> ... using SIP/SUBSCRIBE, using XMPP/iq
[10:43:28] <Dave Cridland> I think so far, we've mostly been discussing user-orientated notifications - these are interesting, of course - "The boss just sent you an email", etc. But I think by far the more likely facility is going to be MWI update messages. Simple stuff that says "There's unread mail in your INBOX".
[10:44:12] <alexeymelnikov> ... but I don't think there were any consensus in the Lemonade WG for using one or another
[10:44:13] <arnt> MWI?
[10:44:23] <Dave Cridland> Message Waiting Indicator.
[10:45:00] <Dave Cridland> The little envelope icon on the phone, or the blinky light, or a little number.
[10:46:18] <Dave Cridland> For user-orientated messages, I think Sieve is probably the answer, or at least as close to an answer as we'll get. For MWI-style, I think Sieve is overkill - something much simpler can be used to deliver these messages.
[10:46:26] <Dave Cridland> Or rather control them.
[10:46:31] <arnt> sure. IMO, much like lisa's calendar. needs to be structured for machine readability, needs to be reliable.
[10:46:39] <rohan> ala RFC 3842
[10:47:14] <arnt> sieve/overkill... if we need sieve anyway, what's wrong with using it for this simple task?
[10:47:21] <bernard.desruisseaux> In the case of calendars, you would want to be notified for new/rescheduled/deleted events / to-dos
[10:47:21] <rohan> RFC 3842 is already used in hundreds of SIP implementations to turn on the blinky light. we've got that one covered thanks!
[10:47:37] <eburger> I would offer that Calendar notifications are out of scope.
[10:47:43] <eburger> Why? Because they must be reliable.
[10:47:45] <bernard.desruisseaux> and you would want the ability to restrict the notifications based on the Organizer, Attendee list, scheduled time etc.
[10:47:47] <rohan> eric: why?
[10:47:50] <eburger> Notifications are best effort, at best.
[10:48:05] <eburger> Otherwise, we just re-invented IMAP.
[10:48:09] <bernard.desruisseaux> Humm...
[10:48:15] <eburger> (or SIP MESSAGE)
[10:48:32] <Lisa> I am not assuming they must be reliable, myself. And we're not talking about notifications from a calendar server, but notifications from an email server that happen to be useful to a calendar client.
[10:49:03] <rohan> for calendar notifications, it occurs to me that using a specific XMPP resource specifically for your calendaring application could be used to forward ALL your calendar-related mail
[10:49:18] <eburger> I just don't want to confuse the requirements for calendar updates with notifications
[10:49:24] <Lisa> I agree that notifications shouldn't be made to be reliable in such a way that they can replace an in-band synch mechanism.
[10:50:08] <bernard.desruisseaux> I'm not assuming notifications would actually contain the calendar data...
[10:50:22] <Lisa> that's rght
[10:51:03] <eburger> But MUST notifications be reliable?
[10:51:18] <eburger> As we'
[10:51:26] <rohan> eric: are you proposing that more specific (filtered) notifications about calendar-related emails could be in scope, but bulk delivery of calendar data is out?
[10:51:45] <eburger> I would say so (as participant).
[10:52:29] <eburger> As we've been at this for almost an hour, can we focus on message types. I think once we nail down message types, we can figure out how to control them and the actual payloads.
[10:53:24] <alexeymelnikov> Chris's draft has several message type groups:
[10:53:40] <alexeymelnikov> message state, mailbox state, account related
[10:54:27] <alexeymelnikov> Do we agree that account related (login/logouts/authenticate attempts) are out of scope for this discussion?
[10:54:48] <Dave Cridland> Yes.
[10:55:00] <arnt> yes!
[10:55:19] <alexeymelnikov> Any other top level categories that people might want to add or delete?
[10:55:25] <eburger> Lisa? Rohan?
[10:55:43] <Lisa> probably, but I haven't yet figured out the scope of each message type :)
[10:55:57] <bernard.desruisseaux> Notification / reminder for a meeting about to start in 10 minutes?
[10:56:09] <eburger> :-*
[10:56:33] <Lisa> Coming from what system, bernard?
[10:56:50] <eburger> But Bernard does bring up a point: are we doing mail notifications only, or calendaring, too? I would offer mail only for now, but that's my suggestion, not mandate.
[10:56:54] <bernard.desruisseaux> A server I would think
[10:57:10] <Lisa> A mail server or a calendar server? In the IETF's model they're separate (even if in the real world they're sometimes combined)
[10:57:13] <arnt> mail only for now, please. if we don't restrict our task, we'll never get it done.
[10:57:29] <Dave Cridland> I'd say we deal with mail, and obviously try to keep an eye on the future.
[10:57:31] <bernard.desruisseaux> I wouldn't want to restrict the delivery to email
[10:57:49] <Dave Cridland> bernard.desruisseaux: Not delivery, source.
[10:58:05] <Lisa> I'm hoping that solid work limited to email will eventually pave a path for message event schemas for other types of sources.
[10:58:31] <alexeymelnikov> Can we say that a calendar is a message matching certain criteria?
[10:58:33] <Dave Cridland> Lisa: Exactly.
[10:58:46] <rohan> Proposal: We restrict our first list of notifications to email-related notifications that can e sent via and aritrary numer of protocols
[10:59:07] <rohan> sorry my b key is dead
[10:59:16] <eburger> Glenn, Abhijit: thoughts?
[10:59:22] <alexeymelnikov> I am Ok with that
[10:59:41] <rohan> so weather is out of scope *for now*.
[10:59:59] <eburger> correct
[11:00:20] <Lisa> I was sure hoping Barry and Philip would have talked more about the proposed BoF by now -- maybe somebody else can start a charter discussion anyway?
[11:00:30] <eburger> NOT ME
[11:00:35] <arnt> there'll be a bof in prague?
[11:00:41] <Lisa> Chris wants to call it the BIFF BoF.
[11:00:46] <eburger> I say, give it to Arnt, as he is always looking for more stuff to do :-)
[11:00:58] <alexeymelnikov> Barry will be in Prague, Philip doesn't know yet
[11:01:13] <alexeymelnikov> Eric: I like that :-)
[11:03:02] <arnt> can we pop the stack a little? undigress?
[11:03:12] <eburger> Good idea.
[11:03:14] <alexeymelnikov> Please
[11:03:29] <eburger> One piece of housekeeping: I booked 2 hours. Did all of you? Will we start losing folks?
[11:03:33] <arnt> we talk about notifications related to email messages or mailboxes.
[11:03:49] <eburger> I smell consensus on e-mail notifications.
[11:04:08] <arnt> I can be here until the end, I think.
[11:04:26] <arnt> we also have consensus that they're not reliable.
[11:04:28] <arnt> right?
[11:04:30] <Lisa> My IESG meeting starts in 25 minutes
[11:04:40] <eburger> I agree (on consensus, not IESG :-))
[11:04:56] <eburger> Can we move to message types?
[11:05:07] <eburger> Do we have consensus on the list Alexey enumerated?
[11:05:21] <Lisa> The work on message types is well done so far, it's the best understood of the various pieces isn't it?
[11:05:29] <arnt> yes.
[11:05:36] <Dave Cridland> Yeah, I think we know what events can trigger notifications.
[11:05:58] <Dave Cridland> What I don't think we know is what the intent of doing so is.
[11:06:00] <arnt> but do we want structured notifications or free text?
[11:06:15] <eburger> Great. Do we want to look at the easy thing (payload, as Arnt brings up), or the hard thing (control)?
[11:06:20] <arnt> machine-readable or sms-friendly, so to speak?
[11:06:25] <eburger> How about easy thing, because it isn't obvious?
[11:06:31] <eburger> (like Arnt's comments here)
[11:06:32] <Dave Cridland> eburger: Let's do easy first.
[11:07:03] <eburger> Thinking protocol responses mostly are machine readable with human helper text
[11:07:11] <Dave Cridland> eburger: But the payload depends on the requirements, too. As in, what did we want notifications *for*.
[11:07:13] <eburger> like "500 server unavailable)
[11:07:30] <eburger> OK, so what do we want the notifications for?
[11:07:43] <Lisa> use cases? We've thrown out a few here so far.
[11:07:57] <eburger> The big question is: are they a "bit" to trigger a client to do something, or a "message" to tell the user something.
[11:07:59] <eburger> ?
[11:08:34] <Dave Cridland> eburger: Well, Randy pointed out that if you stuff sufficient information into a machine readable message, you can use them for user stuff too.
[11:08:50] <Dave Cridland> But equally, the more information you put in these things, the more security implications it has.
[11:09:58] <eburger> and... ?
[11:10:00] <rohan> i can construct plenty of cases where the notification is just as security sensitive as the message. this means that we need a way to send notifications with confidentiality, authentication, and message integrity
[11:10:21] <eburger> Unfortunately, I have to agree with Rohan.
[11:10:26] <rohan> for notifications with those properties, i think we can safely include the user stuff too
[11:10:33] <alexeymelnikov> Indeed. If it is 1 bit, it might not have to be confidentiality protected. Or at least not always
[11:10:43] <Dave Cridland> rohan: Well, it depends on how much data we're intending to stuff into them.
[11:11:06] <rohan> also, if the user stuff isn't sensitive, you can send it with an unencrypted notification
[11:11:14] <alexeymelnikov> ("Indeed" was to the previous Dave's message)
[11:11:23] <arnt> suggestion: we discuss how to do MWI and similar "bit" tasks, and leave all the "tell user about" to the sieve notify draft.
[11:11:26] <rohan> its only when the user stuff is MORE SENSITIVE that you can't include it
[11:11:43] <rohan> or when you don't want to include it for size reasons
[11:11:53] <Dave Cridland> Arnt: That sounds like a plan.
[11:12:15] <alexeymelnikov> Arnt: What other bit tasks you have in mind?
[11:12:52] <arnt> kinds of MWI, really.
[11:13:00] <rohan> re: MWI: is there a lurking missing requirement that is not covered by RFC3842?
[11:13:35] <arnt> perhaps. 3842 requires SIP.
[11:13:37] <rohan> (note: i am fine with having an XMPP equivalent for example, i just haven't seen it come up)
[11:13:42] <arnt> can we require SIP?
[11:13:47] <Dave Cridland> There are two "bit" messages I can think of. One is "There are X unread/recent messages currently in mailbox Y", and the other is "There have been updates to Y that you might want to synchronize"
[11:14:02] <Lisa> yes -- how to tell the IMAP server that it's OK to send these message to this subscriber
[11:14:27] <rohan> do we have a concrete use case where someone wants MWI, that is using a non-SIP IETF protocol?
[11:14:46] <Dave Cridland> Lisa: Well, there's "How do we send it", and RFC3842 is one option, "Who do we send it to", and "How to we control it".
[11:14:49] <Dave Cridland> rohan: Biff
[11:15:18] <alexeymelnikov> XMPP?
[11:15:31] <eburger> BACK ON TRACK.
[11:15:32] <rohan> i don't think iff is mwi. mwi to me means counts of messages in a particular status
[11:15:46] <eburger> "How to tell" is control. Let's focus on the "what" first.
[11:15:52] <Lisa> It's my understanding that while a bunch of devices are already SIP clients and will be most happy doing RFC3842-style stuff, some won't want to jump into SIP. I think calendar clients and simple desktop apps like Google Notifier are probably in the "really rather not do SIP" camp.
[11:16:38] <rohan> what are the *requirements* for google notifier?
[11:17:01] <rohan> i suspect they want to do a it more than MWI, but maybe i am wrong
[11:18:28] <Dave Cridland> Well, I think any MWI should manage to generate counts. These are used by lots of systems. Many, however, only care about the existence of messages in a certain state, but that's a subset.
[11:19:30] <Lisa> Or arrival of a certain type of message.
[11:19:57] <Dave Cridland> Lisa: Same thing. Any time the numbers change, the systems sends out a notification.
[11:20:18] <Lisa> Google Notifier seems to want to know the unread count and a bit of information about the most recent 5 unread mails (from address and 30-or-so characters from subject)
[11:20:50] <Dave Cridland> Lisa: So what it needs to do is watch for MWI messages, and when the counters change, fetch the information it needs via IMAP.
[11:20:56] <Lisa> Not the same thing :) Arrival of a message from my boss at the same time another message gets deleted doesn't change the count but it might be an interesting notification :)
[11:21:31] <Lisa> Dave: I am very sure Google Notifer doesn't use IMAP, and I suspect it probably shouldn't either.
[11:22:15] <alexeymelnikov> Lisa: right, but we are not designing requirements for Gmail either
[11:22:22] <Dave Cridland> Lisa: I'm sure it doesn't, but what I'm saying is that I think if you want to monitor actual message data, you need to get it via the protocol designed for getting it.
[11:23:08] <Lisa> Hmm. I'm not sure.
[11:23:26] <alexeymelnikov> Right. Whether the protocol for getting data happens to be an extension of the protocol used to send the notification is another matter
[11:24:07] <Lisa> If you want to reliably know what's in messages in the store, then yes I agree use the protocol designed for getting that. But putting a small amount of information in a notification, as long as the client can handle unreliability, can be quite useful.
[11:24:44] <alexeymelnikov> Is this a requirement we all can agree on?
[11:24:56] <arnt> I think so.
[11:24:59] <Dave Cridland> Lisa: It's also increasing the complexity of the protocol and its security impact.
[11:25:22] <Lisa> It's true, it's a tradeoff. I'm not insisting.
[11:25:45] <Lisa> As Rohan points out much of the secuirty impact is constant no matter what we put in.
[11:26:39] <alexeymelnikov> This might not be the case if we choose to specify a format which is not extensible (on purpose)
[11:27:57] <alexeymelnikov> So who feels strongly about having message specific data in the notification, e.g. subject?
[11:28:36] <Dave Cridland> I feel quite strongly against it.
[11:29:20] <Dave Cridland> I think we'll see deployment of systems sending the notification messages over protocols lacking in end-to-end encryption, or where such encryption is sparsely deployed, such as SMS, or XMPP.
[11:29:26] <rohan> i think it is useful and everyone in the real world will use it
[11:29:37] <Lisa> I think the answer to that *does* depend on whether the notifications are going in IMAP or email or elsewhere.
[11:29:40] <alexeymelnikov> I feel against it, but probably not that strongly. However I am not against an extensible format for notifications
[11:30:46] <alexeymelnikov> Arnt? Abhijit?
[11:30:48] <arnt> I'm in favour or allowing message data. google has shown that it's useful. if we say no, we're just volunteering to write a -bis that says yes next year.
[11:31:05] <arnt> abhijit was on the phone just now, he may still be.
[11:32:05] <ams> alexey: i tend towards being against it, but also not strongly.
[11:32:21] <eburger> Let's not confuse UI with protocol.
[11:32:33] <eburger> Protocol message: "You have a new message"
[11:32:43] <eburger> UI: "fetch first part of message, if I care"
[11:32:53] <eburger> (that said, I don't care)
[11:32:54] <Dave Cridland> eburger: Absolutely. A "Google Notifier" style application can be built without the subject line being in the notification.
[11:34:20] <arnt> Dave Cridland: a google notifier can be build using imap and idle, as can every other sort of MWI. so if imap is available, we can go home now. RAA.
[11:34:24] <Lisa> You're assuming that the recipient of notifications has some way of retrieving the first part of the message. I don't think that should be done with a "fetch" in SIP or XMPP, and the client may not even have access to the IMAP server account.
[11:34:51] <eburger> Then what would they do with the information?
[11:35:11] <rohan> i'll point out that RFC 3842 already lets you convey that user data and that this has been implemented and is in commercial use
[11:35:37] <arnt> I was just looking at that...
[11:36:16] <rohan> conveying potentially reliable counts and unreliable related user-data has proven useful in the real world
[11:36:27] <rohan> i think this is a no-brainer
[11:36:34] <arnt> can you elaborate?
[11:37:33] <rohan> in 3842 the counts are sent reliably, but the user-data (subject, from, etc..) is not sent reliably
[11:38:30] <arnt> it seems to me that 3842 and/or an XMPP equivalent is simple, accessible and a good approximation of what we need. but I haven't read 3842 closely. I also don't know whether requiring SIP is okay, or XMPP. so I'd suggest that we proceed with 3842 or 3842/xmpp, rather than trying to build our own from first principles.
[11:38:48] <arnt> we may be able to build our own better, but it'll take a lot of effort.
[11:38:49] <rohan> there is a resynchronization process which covers the summary counts, but user data is not synchronized
[11:39:56] <rohan> i agree with arnt. i am certainly willing to propose an XMPP equivalent to RFC 3842, or help someone else who wants to do it
[11:40:07] <arnt> how about we all read 3842, and if noone can present a good argument (on the list) against using it or an xmpp-based clone of it, we proceed with it?
[11:40:41] <eburger> I second the motion
[11:41:20] <ams> sounds good.
[11:41:31] <Dave Cridland> I'm okay with that.
[11:41:38] <arnt> personally, I lean towards xmpp. I've heard scary stories about implementing sip, so I think that applications taht don't need sip for any other reasons might not want it just for mwi.
[11:41:56] <arnt> but that's not a strong opinion. based only on hearsay.
[11:42:03] <eburger> This is where we'll get the OMA / 3GPP push-back. I'm sure they will *insist* on SIP.
[11:42:04] <alexeymelnikov> Ok with me
[11:42:18] <eburger> Can we declare victory?
[11:42:20] <eburger> Summary:
[11:42:29] <arnt> eric: insist on sip being available or mandated?
[11:42:29] <eburger> 1. notifications' scope is e-mail
[11:42:32] <Lisa> I've been assuming we'd need to to both, but that the same scheme and types and possibly subscription/filter syntax can be used for both.
[11:42:56] <eburger> 2. follow _model_ of 3842
[11:43:01] <eburger> 3. figure out transport later
[11:43:12] <alexeymelnikov> Also remember that Oracle had own proposal
[11:43:19] <eburger> (My name is in the Ack's of 3842, so, of course I'd like to use that)
[11:43:29] <eburger> Well, where is Stephane or Ray?
[11:44:07] <eburger> Of course, this gets taken to the list, where they can feel free to agree, disagree, or make counter-proposals.
[11:44:23] <alexeymelnikov> Fair point. I just hate to redo something already done, if there is no good reason
[11:44:32] <arnt> stephane and ray haven't been active in email recently, right?
[11:44:36] <eburger> correct
[11:44:55] <eburger> Is there more we would like to accomplish today?
[11:45:19] <arnt> as in, give arnt a draft to write? no, there isn't. have a nice day.
[11:45:25] <eburger> :-)
[11:45:40] <arnt> rohan: you're on the list, right?
[11:46:06] <eburger> Actually, I do need a stuckee to write up the 3 things agreed to above and summarize the Jabber log
[11:46:19] <rohan> yes
[11:46:24] <arnt> alexey will do that for you.
[11:46:31] <Lisa> In the long run I suspect a lot of the things we've been discussing need to go in a model document.
[11:47:17] <arnt> I have to quit now.
[11:47:34] <eburger> Let's wait 5 minutes for Arnt to go, so we can assign it to him :-)
[11:47:44] <arnt> if not, sofie (just arrived home) will hijack my keyboard. she can switch every program into strange modes.
[11:48:08] <eburger> Sometimes I think a 6-year-old can write better documents than some of our editors :-(
[11:48:26] <Dave Cridland> Eric: I have a 5 year old. Will that do?
[11:48:48] <alexeymelnikov> Dave: start training him now
[11:48:51] <Dave Cridland> Eric: Although he can only write in Welsh, which might be confusing.
[11:50:37] <eburger> OK, thanks; look to the notifications list for a summary and next steps.
[11:59:09] --- Lisa has left
[11:59:10] --- ams has left
[11:59:12] --- rohan has left
[12:08:38] --- Glenn Parsons has left
[12:12:52] --- alexeymelnikov has left
[12:14:51] --- alexeymelnikov has joined
[12:15:34] --- alexeymelnikov has left
[12:15:43] --- alexeymelnikov has joined
[12:46:09] --- bernard.desruisseaux has left
[13:19:49] --- eburger has left: Replaced by new connection
[15:51:15] --- alexeymelnikov has left
[16:38:08] --- arnt has left