[04:35:37] --- greg.vaudreuil has joined
[05:18:59] --- greg.vaudreuil has left
[11:23:37] --- ams has joined
[11:31:20] --- frank has joined
[11:45:32] --- greg.vaudreuil has joined
[12:06:40] --- greg.vaudreuil has left
[12:08:54] --- kmurchison has joined
[12:09:32] --- kmurchison has left
[12:28:06] --- Glenn Parsons has joined
[12:28:36] * Glenn Parsons has set the topic to: LEMONADE at IETF 68 in Prague
[12:34:32] --- kmurchison has joined
[12:36:38] --- cyrus_daboo has joined
[12:37:32] <Glenn Parsons> Audio should be here:
[12:37:35] <Glenn Parsons> http://videolab.uoregon.edu/events/ietf/ietf687.m3u
[12:37:45] <cyrus_daboo> No sound - just some clicking...
[12:38:06] <cyrus_daboo> Yes I can hear now,
[12:38:18] <Glenn Parsons> Great ... we'll start shortly.
[12:38:26] <cyrus_daboo> Thanks.
[12:41:33] <ams> i can only barely hear some murmuring in the background, and a periodic beep in the foreground.
[12:41:47] --- tonyhansen has joined
[12:42:01] <Glenn Parsons> we still have not started...
[12:42:03] <cyrus_daboo> I have the beep - Glenn did a sound c heck before and it was OK. They have the mike off right now - or sometrhing.
[12:42:18] <Glenn Parsons> 2 minute warning
[12:42:28] <cyrus_daboo> Ok - the sound that time was bad
[12:42:35] <cyrus_daboo> Lots of break up/buzzing.
[12:42:44] <kmurchison> Yes, it still sounds like everyone swalled a kazoo
[12:42:52] <kmurchison> (swallowed)
[12:43:09] <tonyhansen> welcome
[12:43:18] --- Randy has joined
[12:43:22] --- greg.vaudreuil has joined
[12:43:22] <greg.vaudreuil>
[12:43:37] <Glenn Parsons> Slides hould be here:
[12:43:38] <Glenn Parsons> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68
[12:43:49] --- frodek has joined
[12:43:51] <tonyhansen> aux website: www.standardstrack.com/ietf/lemonade
[12:43:55] <cyrus_daboo> Can Eric try another mike?
[12:43:55] --- barryleiba has joined
[12:44:20] --- Dave Cridland has joined
[12:44:46] <Dave Cridland> Those kazoos were tasty.
[12:45:13] <cyrus_daboo> Ok - audio is just bad from your room...
[12:45:35] <tonyhansen> it was bad in an earlier meeting as well
[12:45:54] <tonyhansen> agenda -- bash bash
[12:47:00] <tonyhansen> arnt is moved from today's agenda to thursday
[12:47:45] <ams> i think people are speaking too close to the mic.
[12:48:05] <ams> (because every now and then a background voice is perfectly clear.)
[12:48:19] <cyrus_daboo> I think the overall gain is just wrong somewhere - the calsify audio was loud and clear from another room.
[12:48:42] <tonyhansen> move smtp restart & imap sieve & streaming to today
[12:48:45] --- cnewman@jabber.org has joined
[12:49:10] --- sm-msk has joined
[12:49:17] <tonyhansen> keep big picture, current drafts, rohan + rohan for today
[12:49:31] <tonyhansen> move other notification agenda items to thursday
[12:49:37] --- kjetilho has joined
[12:49:40] --- eric has joined
[12:51:16] <tonyhansen> list of RFCs published and other document status
[12:51:46] --- resnick has joined
[12:51:46] --- resnick has left
[12:51:46] --- resnick has joined
[12:52:14] --- filip.navara has joined
[12:52:30] <tonyhansen> question on "AD Write-Up" state Ted: he will move these to IESG state with Chris as a tutorial for him
[12:53:32] <tonyhansen> lemonade-convert: LCed -- need new draft and another LC, Alexey taking over draft
[12:53:59] <cyrus_daboo> annotatemore is read for IESG - we are waiting for AD switch over - Alexey has done write-up.
[12:54:18] <tonyhansen> annotatemore - still needs imapext expert review? no
[12:54:25] <resnick> No.
[12:54:36] <cyrus_daboo> No - it has been through "informal" last call.
[12:55:03] <tonyhansen> msgevent - basically done, needs WGLC
[12:55:14] --- kdz has joined
[12:55:42] <tonyhansen> 2192bis -- needs 1 more draft, then WGLC
[12:55:57] <tonyhansen> lemonade-streaming -- to be discussed
[12:56:17] <tonyhansen> views -- vfolder removed, context added
[12:56:26] <tonyhansen> more details on Thursday for context
[12:57:40] <tonyhansen> object-level encryption -- oma gotta have -- is TLS sufficient? -- why do we need both?
[12:58:12] <tonyhansen> -- convert had it for a bit, then taken out -- it's an outstanding issue
[12:59:01] <Randy> I thought we dropped object-level encryption
[12:59:37] <tonyhansen> (moved out of convert, but not dropped as a WG item)
[13:00:20] <Randy> Perhaps I'm confusing it with something else, but I recall a slew of security problems, given that the intent was to allow untrusted proxies
[13:00:38] <tonyhansen> REST-based access -- a MAY in profile xmpp people have tunneling protocols over http that we might be able to leverage
[13:01:14] <tonyhansen> esearch -- why is it experimental?
[13:01:53] <Randy> What is a MAY in profile?
[13:01:54] <tonyhansen> confusion between esearch and search-res
[13:02:15] --- kjetilho has left
[13:02:17] <Dave Cridland> (ESEARCH was search-ret, rather than search-res)
[13:02:17] <tonyhansen> (randy: the need for REST-based access is a MAY)
[13:02:36] <Randy> Where in profile is that?
[13:02:57] <tonyhansen> (got me -- just reflecting the chairs' statement)
[13:03:14] <tonyhansen> IMAP Quick Reconnect
[13:03:25] --- kjetilho has joined
[13:04:29] <Dave Cridland> BOSH, the HTTP tunnelling stuff, is XEP-0124, or http://www.xmpp.org/extensions/xep-0124.html
[13:04:42] <tonyhansen> draft-ietf-lemonade-reconnect-client
[13:04:55] --- frodek has left
[13:06:25] <tonyhansen> <<discussion about REST-based reference in profile>> can it go away? Eric yes; Glenn no keep reference to BOSH?
[13:06:33] <tonyhansen> (back to quick reconnect)
[13:07:14] <Randy> We can delete reference to REST in profile, since deployments talks about tcp-challenged environments
[13:07:15] <tonyhansen> a couple minor issues: see the slides
[13:08:10] <tonyhansen> those issues were fixed, and doc is ready for IETF LC
[13:08:22] <tonyhansen> Ted: go back to "search within"
[13:08:29] --- JeffH has joined
[13:11:02] <tonyhansen> doc needs IANA Considerations words Eric will respin and AD will accept
[13:11:08] <tonyhansen> IMAP URL
[13:11:24] <tonyhansen> ready for WGLC, but last rev had some changes
[13:11:31] <tonyhansen> (see slides)
[13:12:29] --- greg.vaudreuil has left
[13:14:00] <tonyhansen> IMAP Sieve
[13:14:52] <tonyhansen> (overview -- see slides)
[13:15:39] --- ft has joined
[13:20:00] <tonyhansen> issues: main open issue is how to associate scripts with events
[13:20:52] <tonyhansen> issue: do extensions need *normative* references, vs *informative*? needs AD feedback
[13:21:20] <tonyhansen> issue: would like an example that uses only base-spec features and no extensions
[13:21:27] --- kdz has left
[13:21:39] --- frodek has joined
[13:22:28] <tonyhansen> alexey: issue with discard: its definition is different from base SIEVE spec barry: difference with whether message already exists or not; could muck with implicit keep
[13:25:32] <tonyhansen> alexey: which causes more confusion? arnt: which meaning is most meaningful to majority? barry: talks about diff in msg processing models randall: if discard doesn't mean discard.... alexey: need text added to doc to explain diffs
[13:26:09] <tonyhansen> barry: ask for help with meta-data wording
[13:26:56] --- aaronstone has joined
[13:29:09] --- kdz has joined
[13:29:40] <tonyhansen> randy: can there be more than one script? barry: imap sieve is different animal from smtp sieve randy: manage sieve 10 years old, agrees to help barry work on this issue aaron: could extend manage sieve to accept multiple arguments aaron: monologue on where sieve scripts *could* live, be useful input to this effort?
[13:30:33] <tonyhansen> barry/aaron: discussion of manage sieve vs. meta data
[13:30:52] <tonyhansen> randy: acap sieve extension?
[13:31:09] <Dave Cridland> (Actually, that was one part of ACAP I never implemented)
[13:31:28] <tonyhansen> aaron will also work with barry & randy on this issue
[13:32:00] <tonyhansen> greg: is this a dependency in the ??? draft barry: yes
[13:32:09] <Dave Cridland> (Profile Bis draft)
[13:32:17] <tonyhansen> Notifications
[13:32:32] <Randy> Dave--it had so many magic attributes
[13:32:39] <tonyhansen> (slide 13 from chairs' slides)
[13:33:09] <Dave Cridland> (Randy: Exactly. Multiple IMAP accounts on the one ACAP server were, erm, problematic)
[13:33:43] <tonyhansen> (slide 14)
[13:33:52] <tonyhansen> Eric explains slide 14
[13:34:28] <Dave Cridland> Is this the traditional time to mention it should be the lines that are coloured, not the boxes?
[13:34:35] <tonyhansen> Rohan
[13:35:08] <tonyhansen> (was that a dongling participle?)
[13:35:33] <kmurchison> Aaron/Barry: I don't think that we can ditch ManageSieve entirely in favor of a script attached to the INBOX, because this assumes that all mail is destined for the INBOX. In the case of plus-addressing (e.g. murch+cyrus@cmu.edu), this isn't the case. I think ManageSieve is still useful for putting a script in place to be executed AT final delivery time, as opposed to AFTER final delivery.
[13:35:39] <tonyhansen> Notifications -- Message Waiting for SIP (Rohan)
[13:36:16] <aaronstone> Alexey suggested using a server annotation for the 'top' sieve delivery script
[13:37:06] <cyrus_daboo> And people using POP do what exactly?
[13:37:18] <Dave Cridland> Upgrade? ;-)
[13:37:21] <tonyhansen> Rohan's slides are not currently on the meeting site, but will be later
[13:37:48] <tonyhansen> Slide: Message Flow from RFC 3842
[13:37:49] <kmurchison> Cyrus: Exactly. And this also requires SMTP/LMTP to have access to the annotations either via IMAP or out-of-band.
[13:38:36] <Randy> Qpopper includes a sieve engine that implements some actions. Not fileinto, of course.
[13:38:50] <cyrus_daboo> Ken: right and then you have all the usual authorization issues with those services accessing a user's IMAP data. Though perhaps a weird URLAUTH could cope with that...
[13:38:52] <aaronstone> What if the set of scripts held in the server annotations were the same as the set of scripts managed by managesieve? That way, you could use ManageSieve, or you could use the new-fangled imap stuff we're going to write about. POP users would obviously still use ManageSieve, while IMAP users would have a choice.
[13:38:53] <Randy> And it unfortunately is an old version of the syntax
[13:39:43] <cyrus_daboo> Sure - there is no reason why an IMAP server couldn't use ManageSIEVE itself to maintain a "cache" of the underlying SIEVE data.
[13:39:59] --- csch has joined
[13:40:28] <cyrus_daboo> In fact that would be a good way for an IMAP server from one vendor to work with a SIEVE implementation of another.
[13:41:37] --- arnt has joined
[13:41:55] <kmurchison> Aaron: That would work. FWIW, Cyrus IMAP already uses an annotation to have a sieve script run when a message gets delivered to a shared mailbox. So ignore my argument about LMTP needing to have access to annotations, because I'm already doing it ;)
[13:42:12] <aaronstone> Cyrus - I like that point, as it gives a reasonable migration path.
[13:44:28] <tonyhansen> slide: Existing notification MIME type (shows example)
[13:44:32] --- filip.navara has left
[13:48:09] <tonyhansen> slide: proposed extensions to RFC3842 for Sieve use existing package name in Event header Include sieve filter in most SUBSCRIBEs use existing content negotiation to say how you want notification content
[13:49:41] <Dave Cridland> draft-mahy-sieve-notify-sip-00
[13:50:38] --- hardie@jabber.psg.com has joined
[13:51:55] <tonyhansen> slide: message formats example of Subscribe Body and Notify Body
[13:52:51] <Dave Cridland> http://svn.resiprocate.org/viewsvn/ietf-drafts/rohan/email-event/draft-mahy-sieve-notify-sip-00.txt?view=markup&pathrev=1581
[13:56:33] <tonyhansen> Randy: what about replay of dropped packets? Rohan: every attempt is made to make things reliable
[13:58:17] <Randy> Note that the protocol requires that notifications be acked
[13:59:17] <csch> now the audio is REALLY unbearable ... (just FYI)
[13:59:50] <csch> The background voices are perfect, but the "main speaker" is almost non-understandable ...
[13:59:54] --- csch has left
[14:00:02] <cyrus_daboo> Ask him to take a step back
[14:01:15] <tonyhansen> dave: what does all this give us over leaving imap connection open? rohan: 1) division of labor 2) you might already have a device doing SIP, so cheap implementation
[14:01:39] <cyrus_daboo> It can be used for other types of service beyond IMAP (calendaring ....)
[14:02:22] <tonyhansen> glenn: meets OMA out-of-band notification requirements
[14:02:28] <Randy> I heard Rohan say that what it gives you is specific summary information
[14:04:37] <tonyhansen> chris: q on reliability: is there device backing store, do events get lost, what? lots of issues and having a good model would be useful
[14:05:53] <tonyhansen> chris: sure there'd be both SIP and XMPP transports, would be interested in keeping same model ted: how about CPIM?
[14:07:59] <tonyhansen> ted: this is useful if you're already using it same is true for xmpp msgs could aggregate things talking with multiple imap servers? could only keep single notification pipeline separate from imap connections
[14:10:14] <tonyhansen> randy: could you avoid overhead by ??? (sorry, missed it) ted: long lived connection may not be doing a lot randy: for lemonade, will already have imap connection, so why not use it? greg: you're going to use both
[14:10:43] <arnt> the advantage of ftf meetings is high communication bandwidth and low rtt.
[14:10:57] <tonyhansen> greg: this is for OOB, which might kick off inband
[14:13:31] <tonyhansen> eric: most clients with lemonade are going to be running sip anyway, so that argument counts a lot rohan: many devices will have both sip and xmpp randy: ?? chris: is this 1st step in segueing notification to notification experts?
[14:14:46] <Randy> I was saying that I agree that most lemonade clients will have sip, and that sip notifications seem very useful, because they can aggregate lots of notification sources. But I'm not sure of the benefit specifically for lemonade
[14:15:28] <tonyhansen> (I'm missing lots of this -- have to see the audio record)
[14:15:43] <Randy> sip notifications are expensive (chatty), in the specific case of lemonade, seems cheaper to just use in-band over long-lived idle tcp connections
[14:16:32] <tonyhansen> rohan: sip can be daunting offers to sit down with anyone to discuss sip question: if we do sip, is this a reasonable approach?
[14:18:01] <tonyhansen> greg: does sip notification buy object encryption? rohan: 2 security mechanisms in sip: (1) s/mime (not widely deployed) or (2) TLS
[14:20:49] --- ssilberman has joined
[14:21:07] <tonyhansen> pete has a headache rohan: sip is defined over udp, tcp, tls over tcp, sctp, udp + ipsec pete: what does OOB mean? ans: when you don't have an imap connection greg: would have two co-resident sip stacks
[14:22:42] <tonyhansen> ted: rohan offered nice stuff, has nightmare of push vs. pull all over again need to1st figure out how *any* notif mech gets out of the msg store
[14:23:35] <tonyhansen> greg: consensus on push model of notifications
[14:28:36] <tonyhansen> pete: OOB udp doesn't help any want notif when traffic channel is down anything will bring up traffic channel greg: traffic channel is separate from imap channel rohan: even if don't have tcp conns up, can leverage udp traffic channel (?) randy: many phones *seem* to run multiple apps without actually doing so, waiting for packets to kick off event chris: his customers want to have notification box, currently use jms API, happy to use sip he prefers protocols over APIs
[14:29:21] <tonyhansen> greg: SIP useful between box "Mobile Notiication Magic" box and "MUA" box, but not from IMAP store?
[14:30:00] <tonyhansen> zohan: ?
[14:30:00] --- JeffH has left: Logged out
[14:30:22] --- ssilberman has left: Disconnected.
[14:30:32] <tonyhansen> randy: answer is in architecture doc, although a bit vague
[14:31:14] --- ssilberman has joined
[14:31:22] --- ft has left
[14:33:26] <Randy> Actually, I was saying the answer should be in the notifications architecture document, but doesn't seem to be yet
[14:35:13] <Randy> Zohan asked about how clients get notifications that they are interested in, and what happens if the phone they are running on doesn't support the sip or xmpp or whatever that the notifications server is generating
[14:35:40] <tonyhansen> greg: has model question about how sieve notifications would work sieve really should be part of "mobile notification magic" chris: need filters glenn: what is missing from diagram is server to server piece greg: notification is being stuffed into imap box and shouldn't be
[14:35:52] <Randy> Ted responded that this goes back to my question about the intent of notifications: are they disposable optimizations or are they required
[14:37:47] <tonyhansen> rohan: who is doing sieve -> xmpp notification barry: steve andreas rohan: should use similar format for notifications, he can talk with steve eric: OMA has email notification format to be discussed
[14:38:15] <tonyhansen> new topic: outstanding liaison
[14:38:37] --- alexeymelnikov has joined
[14:39:32] --- hardie@jabber.psg.com has left
[14:41:51] <tonyhansen> glenn: EMN -- needs interop output OMA STI -- what was "mandatory to implement" subset? (html to text) need presentation from them on TS glenn will update liaison
[14:43:50] --- kdz has left
[14:44:32] --- Dave Cridland has left: Logged out
[14:44:36] <tonyhansen> dorothy: TS -- been trying to determine the TS (technical spec), lost some people, will be delayed
[14:44:51] --- cnewman@jabber.org has left
[14:44:54] --- Randy has left
[14:45:11] --- greg.vaudreuil has joined
[14:45:11] <greg.vaudreuil>
[14:45:23] <tonyhansen> -- adjourned --
[14:45:25] --- resnick has left
[14:45:28] --- tonyhansen has left
[14:45:29] --- barryleiba has left
[14:45:29] --- barryleiba has joined
[14:45:30] --- cyrus_daboo has left
[14:45:31] --- greg.vaudreuil has left
[14:45:34] --- eric has left
[14:45:34] --- sm-msk has left
[14:45:39] <Glenn Parsons> nest session is 9am CET on Thursday
[14:45:44] --- barryleiba has left: Logging off
[14:45:47] --- ams has left
[14:46:25] --- frank has left
[14:47:14] --- aaronstone has left
[14:50:21] --- arnt has left
[14:59:40] --- kjetilho has left
[15:01:23] --- frodek has left
[15:10:27] --- alexeymelnikov has left
[15:15:20] --- guenther has joined
[15:22:11] --- Glenn Parsons has left
[15:25:47] --- ssilberman has left
[15:32:19] --- kmurchison has left
[15:40:35] --- guenther has left
[16:06:30] --- filip.navara has joined
[18:41:41] --- arnt has joined
[19:27:36] --- arnt has left
[22:06:36] --- filip.navara has left