[03:04:40] --- fanf has joined
[03:47:39] --- llhotka has joined
[03:48:04] --- llhotka has left: offline
[03:52:23] --- greg.vaudreuil has joined
[03:57:12] --- barryleiba has joined
[03:58:09] --- kjetilho has joined
[03:59:12] --- cnewman@jabber.org has joined
[04:00:21] * Glenn Parsons has set the topic to: LEMONADE at IETF 68 Prague
[04:00:28] <fanf> ooh signs of life :-)
[04:01:13] <kjetilho> I'll be Jabber scribe
[04:01:53] --- frodek has joined
[04:02:29] * fanf can hear
[04:02:32] <Glenn Parsons> Glenn is here & can hear!
[04:02:39] --- arnt has joined
[04:02:43] <Glenn Parsons> Hello.
[04:03:17] <kjetilho> agenda bashing
[04:04:43] <Glenn Parsons> updated slides are here
[04:04:46] <Glenn Parsons> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68
[04:05:08] <Glenn Parsons> Microphone please ....
[04:05:54] --- tonyhansen has joined
[04:07:50] <kjetilho> IMAP Notify
[04:07:52] <Glenn Parsons> Is Randy at Geopriv ??? or has he just slept in :-)
[04:10:54] <kjetilho> (Randy arrived)
[04:11:07] <tonyhansen> still looks sleepy :-)
[04:11:40] --- Dave Cridland has joined
[04:11:49] --- arnt has left
[04:12:39] --- randy has joined
[04:13:24] <kjetilho> to establish shared state with server, we only need to send STATUS for each mailbox to get a base for comparison
[04:13:51] <Glenn Parsons> The question was????
[04:14:08] <greg.vaudreuil> how does notify relate to context
[04:14:26] <kjetilho> Zoltan:
[04:14:44] <kjetilho> What happens if you leave out "all"?
[04:14:51] --- tonyhansen has left
[04:15:05] <kjetilho> Arnt: syntax error. all is a search key for all messages
[04:15:36] <Dave Cridland> Greg: It doesn't, but it doesn't really need to, I think.
[04:15:40] <kjetilho> Event slide
[04:16:22] --- tonyhansen has joined
[04:16:42] <kjetilho> you can get selected headers in the response
[04:17:25] --- resnick has joined
[04:17:28] <kjetilho> SIP slide
[04:18:58] <kjetilho> Greg: Lemonade is beyond mobile devices, so 99.7% SIP may not be accurate
[04:18:58] <Glenn Parsons> LMEONADE is not just mobile, I agree.
[04:19:12] <Dave Cridland> Lemonade not just for Christmas.
[04:19:59] <Glenn Parsons> But I would also say that the 99.7% would refer to new 3G/4G mobile handsets and not the existing mobile clients
[04:20:25] <kjetilho> Randy: another difference: it requires client and server support. SIP needs more extensions
[04:20:59] <kjetilho> Eric: focus on IMAP, leave the discussion until later
[04:21:03] <greg.vaudreuil> 99.7 applies to smartphones, not necessarily "feature phones"
[04:22:32] <kjetilho> Chris: EXPUNGE. the combination is problematic, needs to be stated in draft
[04:22:55] <kjetilho> potential conflicts with msgevent
[04:23:17] <kjetilho> (hmm, I don't understand these technical finepoints)
[04:23:59] <Glenn Parsons> Which extra events are we talking about?
[04:24:24] <Glenn Parsons> How many are we talking about?
[04:24:42] <kjetilho> Chris: subscription change, mailbox create, ...
[04:25:14] <kjetilho> Alexey: we need a new response code for some of the events
[04:26:14] <kjetilho> Arnt: mailbox create/delete/rename becomes impossible to sort out without new response code
[04:27:18] <kjetilho> Chris: msgevent need to add support for the base functionality related events in notify
[04:27:22] <Glenn Parsons> I owuld put them all in MEssgae Events.
[04:27:31] <Glenn Parsons> But again how many are we talking about?
[04:28:08] <kjetilho> Barry: wants to separate into several drafts
[04:28:46] --- harald has joined
[04:28:46] <Glenn Parsons> There is no need for 3 drafts if we already know the list.
[04:29:20] <kjetilho> Barry: let them progress along track independently
[04:29:47] <Dave Cridland> Glenn: Well, I asked, although I'm not sure I got an answer for you, there.
[04:29:47] <kjetilho> Barry: msgevent has no dependencies
[04:30:22] <Glenn Parsons> The message events are for LEMONADE, I would only split if there are non-LEMONADE message events.
[04:31:38] <kjetilho> Randy volunteers to rework msgevent draft
[04:31:57] <kjetilho> Eric: hum for the need to split?
[04:32:39] <kjetilho> Chris: we agree that the missing events must be added
[04:33:05] <kjetilho> Chris: the question is if those should be in a separate draft?
[04:33:44] <kjetilho> Chris: all these events are required by lemonade. we don't want to make moving IMAP to draft harder than it already is
[04:35:38] <kjetilho> hum in favour of two documents
[04:36:25] <kjetilho> (any hums from the Jabber room?)
[04:36:49] <Glenn Parsons> I am in favour of one document....
[04:36:59] <kjetilho> msgevent is missing an IANA registry
[04:37:23] <kjetilho> Randy: we don't necessarily need a registry, just update the RFC
[04:37:27] <kjetilho> hum now
[04:37:30] <randy> and extensions registry
[04:38:00] <kjetilho> 5 for, 4 against. Randy picks which is easier
[04:39:28] <kjetilho> slide Planned changes
[04:40:05] <kjetilho> Barry: obsolete IDLE
[04:40:14] <Glenn Parsons> I would not go that far...
[04:40:42] <kjetilho> Alexey: IDLE is in profile
[04:41:16] <kjetilho> Barry: modality was a bad idea
[04:41:33] <kjetilho> Eric: take it to list
[04:41:39] <harald> barry was saying that we used to think that modality was a bad idea, but now we know better....
[04:42:00] <kjetilho> oh :-)
[04:42:21] <randy> I'm not sure it's "know better", but at least "resigned" and "less bad" :-)
[04:42:26] <greg.vaudreuil> so call notify idlebis
[04:42:28] <cnewman@jabber.org> Modality is a necessary evil, something to be used sparingly
[04:42:37] <kjetilho> Dave: we still need IDLE as a marketing term
[04:43:33] <kjetilho> Chris: when SELECTing, think of interaction with namespaces, allow "all personal mailboxes"
[04:43:48] <kjetilho> not SELECTing, when NOTIFY for selected boxes
[04:44:26] --- resnick has left
[04:45:03] <kjetilho> Arnt: planned change: when you change the notification terms, the server should drop pending notifies
[04:46:10] <kjetilho> Randy: can we optimise the STATUS traffic?
[04:48:58] <kjetilho> Arnt: sending all status implicitly is unnecessary, since not every mailbox may not be visible for the user. the STATUS may be issued when it's scrolled into view
[04:49:09] --- eburger has joined
[04:50:05] <kjetilho> Randy: quick reconnect means the client needs to send all this anyway
[04:50:27] --- resnick has joined
[04:50:28] <kjetilho> Arnt: the responses may not compress well, but the requests should
[04:50:52] <kjetilho> Randy: MODSEQ may allow us to drop responses when nothing has changed
[04:51:30] <kjetilho> Arnt: wants to try out both methods and count the octets
[04:51:36] <kjetilho> will report to list
[04:53:55] <kjetilho> Arnt: should IMAP sieve changes trigger the same kind of notifies?
[04:54:27] <kjetilho> Arnt: actually he wants to be notified by anything mentioned in fileinto in the Sieve script
[04:55:46] <kjetilho> Zoltan: if a message is delivered to INBOX, and notify is active, but a Sieve script stores it someplace else, will he get two events?
[04:56:15] <kjetilho> Arnt: no, the Sieve script will first, so it never touches INBOX
[04:56:33] <kjetilho> Barry: this needs to be clarified in the draft
[04:57:55] <kjetilho> Zoltan: are there other possible interactions? Junk filters?
[04:58:08] <kjetilho> Arnt: we only support spamfilter in Sieve
[04:58:56] <kjetilho> Chris: the msgevent draft says "delivered", so it's good enough already
[05:00:21] <kjetilho> Chris: consider if a server needs to defend himself against a client which asks for too much, should the client be told?
[05:00:52] <kjetilho> Arnt: new response code, "too much traffic, won't do it"
[05:01:17] <kjetilho> Arnt: sent when it happens, not in response to the NOTIFY command
[05:02:05] <kjetilho> Chris: we only need to add it if the client finds it useful
[05:02:14] <kjetilho> Arnt: it is useful at least for testing
[05:03:15] <kjetilho> Barry: still about Notify: if the client STORE a flag, will it get a notify about the flag change?
[05:04:05] <kjetilho> Arnt: the server should tell the client about what it did. MAY or SHOULD skip changes in that session
[05:05:42] <kjetilho> Alexey: there is a list of defaults about which events should be sent without NOTIFY
[05:05:56] <kjetilho> now next presentations
[05:07:30] <kjetilho> slide: Pieces of the puzzle, btw
[05:08:22] --- harald has left
[05:08:31] <kjetilho> Greg: may have to adjust notification model. Sieve notify is user notification, IMAP notify is client notification
[05:09:42] --- dwf has joined
[05:11:02] <kjetilho> Barry: the imap sieve already has the association between script and mailbox, not needed in metadata
[05:11:09] <kjetilho> next slide, example
[05:11:35] <kjetilho> Arnt: suggests a Boolean flag for each mailbox to turn notification on/off
[05:11:50] <greg.vaudreuil> VF interface was
[05:12:06] --- harald has joined
[05:12:10] <greg.vaudreuil> VF interface was view filter. May change to in-band notification.
[05:12:26] <greg.vaudreuil> new interface for ooimap
[05:12:42] <Glenn Parsons> NF used to be both inband and outband
[05:12:45] <greg.vaudreuil> and keep np interface, but rule it out-of-scope for lemonade bis
[05:13:15] <greg.vaudreuil> nf was the filter to teh magic notification box, not in-band
[05:13:56] <kjetilho> Barry: ok, this is fine
[05:15:36] <kjetilho> Randy: Lemonade has focused on bandwidth savings and left notifications to the client.
[05:16:26] <kjetilho> Randy: Sieve is moving away from a monolithic script which makes it easier for several clients to stack their scripts
[05:17:10] <randy> I didn't say Sieve was moving away from it, but that that was one approach to client control of notifications
[05:17:33] <kjetilho> Zoltan: don't exclude Sieve notifications to go to the client, not only the user
[05:18:30] <kjetilho> Greg: three categories 1) IMAP inbound, 2) user notification 3) server to server
[05:18:40] <kjetilho> s/inbound/inband/
[05:21:08] <kjetilho> Arnt: it's hard to limit out-of-band notifications, since we don't control the whole chain
[05:22:11] <kjetilho> Arnt: why don't we require those who wants notify to use IMAP over TCP?
[05:22:32] <kjetilho> Greg: we can make other OOB out of scope for this group
[05:22:44] <kjetilho> Randy: then we can make a lot of stuff out of scope
[05:23:03] <Glenn Parsons> I would be reluctant to make OOB client notifications out-of-scope....
[05:23:11] <Glenn Parsons> We at least need a notification format.
[05:24:04] <randy> Yes, but after the format must come the triggers
[05:24:27] <randy> Greg is suggesting that operators control triggers, as opposed to clients
[05:24:52] <kjetilho> Dave: this is good for users, but not for the clients. can we allow a notification client to log in using IMAP on your behalf, and let it send SMS etc.
[05:26:24] <kjetilho> Chris: rereads the charter excerpt for notifications
[05:26:54] <kjetilho> Eric: will IMAP servers be able to support two million connections?
[05:27:41] <kjetilho> Chris: this shouldn't a WG document
[05:28:21] <kjetilho> Eric: if it isn't an OMA req, why are we talking so much about it then?!
[05:29:35] <kjetilho> Zoltan: OMA doesn't need a general case
[05:30:01] <kjetilho> a single notification server could subscribe on behalf of every customer for the phone company
[05:31:22] <Dave Cridland> I should note for the record that the idea of using URLAUTH tokens for OOB notification servers came out of a chat I had with Philip Guenther.
[05:31:34] <kjetilho> 5 minute break
[05:31:41] <Glenn Parsons> ZZZZZZZZ
[05:38:24] <fanf> what's next on the agenda?
[05:38:58] <kjetilho> fanf: you :)
[05:39:06] <fanf> good-o
[05:40:25] --- arnt has joined
[05:40:47] <fanf> oh dear, my crufy slides are designed for firefox in full-screen mode 1024x768
[05:42:01] <Glenn Parsons> which slides are we going to look at?
[05:42:09] <kjetilho> SMTP QUICKSTART
[05:42:24] <fanf> http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2007-03-ietf/slide-0.html
[05:43:49] <kjetilho> slide: Features
[05:46:17] <kjetilho> slide: Extended QHLO
[05:46:21] <fanf> mic please
[05:46:53] <kjetilho> Andrew: there is no mandatory base features?
[05:47:31] <kjetilho> Randy: we want to get there
[05:47:32] <fanf> i am listening - nothing to add yet
[05:47:46] <kjetilho> Eric: this is not a WG document, only for review
[05:48:44] <kjetilho> Barry: does extended QHLO only come after TLS?
[05:48:54] <fanf> no the cookie is for any time the client says qhlo
[05:49:04] <fanf> so on initial connect and after tls is negotiated
[05:49:37] <fanf> the cookies will be different before and after tls because of the different capability lists, which proves that the client knows what is going on
[05:49:58] <kjetilho> slide: todo
[05:51:21] <kjetilho> Barry: how many RTT without this=?
[05:51:35] <kjetilho> Randy: 16 IIRC Tony?
[05:51:42] <fanf> it's about 8 normally
[05:52:30] <fanf> in fact exactly 8 - quickstart allows you to benefit from tls session cacheing which is currently no help with smtp
[05:52:48] <kjetilho> Dave: for servers it's harder, for clients, it's not much different
[05:53:12] <kjetilho> Chris: is it a cookie for the client or the capability list?
[05:53:30] <kjetilho> answer: it's really the capability list in compressed form
[05:53:40] <fanf> it's a cookie for the client too to protect against spammers spewing commands
[05:54:13] <fanf> the server would generate the cookie by hashing the cap list, client ip address, and a secret - so no client tracking
[05:54:57] <kjetilho> Alexey: leave that to the implementation
[05:55:01] <fanf> alexei's point is very pertinent :-)
[05:55:27] <kjetilho> Chris: interleaving TLS is hard.
[05:55:42] <kjetilho> Dave: we don't really interleave, we just pipeline
[05:55:46] <fanf> i have prototyped the tls adjustments
[05:56:32] <kjetilho> Chris: watch the wording
[05:56:52] <kjetilho> next topic
[05:56:57] <fanf> the difficulty is that the client sends the starttls command nd tls hello, then receives the 220 reply and tls server hello
[05:57:11] <Dave Cridland> fanf: Me too, but only on IMAP, oddly. The hardest thing is of course sending.
[05:58:49] <Glenn Parsons> What slides are we on now?
[05:58:57] <kjetilho> MUST implement
[05:59:05] <Dave Cridland> Alexey's profile-bis ones, MUST implement.
[06:00:26] <kjetilho> Greg: why store views on servers?
[06:00:34] <kjetilho> Alexey: to share between clients
[06:01:12] <kjetilho> Eric: we may have to pull smtp quickstart out
[06:01:23] <kjetilho> Eric: how fast can we prototype?
[06:01:31] <kjetilho> Alexey: quite fast, let's try
[06:02:32] <kjetilho> Alexey: dash before Streaming means NOT included
[06:02:59] <kjetilho> Greg: always intended to be included. now that we have a draft
[06:03:18] <kjetilho> Eric: let's handle it as quickstart smtp, if it's ready for June, include it
[06:04:03] <kjetilho> Alexey: don't want Streaming, let's discuss on mailing list.
[06:04:28] <kjetilho> Eric: Streaming is just a collection of other features
[06:05:02] <kjetilho> Eric: you need a media server to make a streaming server
[06:06:12] <kjetilho> Greg: it's just a convention, not new stuff
[06:06:41] --- harald has left
[06:06:42] <kjetilho> slide: optional/undecicded
[06:08:00] <kjetilho> Chris AD: we need a server to server. IMAP NOTIFY can be used as s2s
[06:08:09] <kjetilho> and it defines a format for notifications
[06:08:24] <kjetilho> so the requirement is fulfilled
[06:09:18] <kjetilho> Eric: it is implementable, so acceptable
[06:09:29] <kjetilho> (heavy coughing from Arnt)
[06:10:35] <kjetilho> Greg: it is part of OMA profile, but not our profile
[06:11:57] <kjetilho> Alexey: the use case for IMAP sieve was OOB, so we may not need it
[06:12:42] <arnt> in ten years, when randy sees me again, he'll think "oh, I need to say my name in the mike" ;)
[06:13:09] --- harald has joined
[06:13:32] <kjetilho> Barry: IMAP Sieve can be used for s2s if you build a notification mechanism
[06:14:02] <Glenn Parsons> When / What is the notifications summit thatn Randy mentioned?
[06:15:06] <Glenn Parsons> I agree with Greg.
[06:15:10] <randy> The chair requested that interested parties converge around him immediately at the end of our session, in order to decide the time for this summit
[06:15:14] <eburger> This afternoon / evening
[06:15:19] <Dave Cridland> Glenn: It's a s3kr3t, and we can't tell you.
[06:16:10] <kjetilho> Dorothy: the deadline is June, and we still haven't decided what's goes in?
[06:16:51] <Glenn Parsons> I am suggesting that SIEVE should be in Profile-bis...
[06:17:43] <kjetilho> Eric: MUST meet milestones (on slide How To Move Forward)
[06:18:47] <kjetilho> slide: proposed milestone dates
[06:19:15] <kjetilho> Barry: what are the dates?
[06:19:24] <kjetilho> Eric: submission to IESG
[06:20:22] <kjetilho> Dorothy confirms Toronto date not a conflict with OMA meeting
[06:20:31] <kjetilho> Dave's next up
[06:20:52] <kjetilho> (Toronto date is still tentative, will be discussed on list)
[06:21:16] <kjetilho> http://dave.dridland.net/slides.html
[06:21:27] <kjetilho> eh, cridland of course
[06:22:05] <kjetilho> slide: Contexts
[06:22:49] <kjetilho> slide: Minimal implementations
[06:23:27] <kjetilho> slide: For ACAP People
[06:24:08] <randy> cridland, not dridland
[06:24:13] <kjetilho> slide: Most Importantly
[06:24:44] <kjetilho> slide: Open issues
[06:26:52] <kjetilho> Barry: you can be explicit, but allow pipeline
[06:27:02] <cnewman@jabber.org> FYI, here's the expired VIEW draft: http://tools.ietf.org/html/draft-ietf-imapext-view-00
[06:27:21] <cnewman@jabber.org> Here's the expired WINDOW draft: http://tools.ietf.org/wg/imapext/draft-ietf-imapext-window/
[06:28:10] --- harald has left
[06:29:26] <kjetilho> Chris: view and window was too complex for the perceived value
[06:29:35] --- barryleiba has left
[06:29:35] --- barryleiba has joined
[06:29:38] <kjetilho> Chris: has this changed with the mobile devices?
[06:29:54] <kjetilho> Dave: this isn't very difficult
[06:30:00] --- ams has joined
[06:30:47] <kjetilho> Dave: do we care about SORT?
[06:31:29] <kjetilho> Zoltan: how is this different from vfolder?
[06:31:56] <kjetilho> Dave: it's similar, but with different tradeoffs
[06:32:34] <kjetilho> Greg: SORT is useful, but the closing window says it's sutiable for a followup
[06:32:40] <kjetilho> Alexey: optional
[06:32:51] <kjetilho> slide: Open Issues 2
[06:34:26] <kjetilho> Greg: what does it mean to be out of sync
[06:34:42] --- barryleiba has left
[06:35:29] <kjetilho> Dave: should we attack the resync problem?
[06:36:01] <kjetilho> Zoltan: can the client tell the server how big the window is?
[06:36:04] <resnick> Jeez, this jabber log looks hauntingly familiar to some very old jabber logs.
[06:36:10] <kjetilho> Dave: yes, that's the PARTIAL
[06:36:24] * resnick watching from intarea
[06:36:55] <kjetilho> resnick, hmm, you think I'm too verbose? first time scribing
[06:37:07] --- greg.vaudreuil has left
[06:37:14] --- cnewman@jabber.org has left
[06:37:18] <resnick> :) No, I'm just saying that the same issues have come up years ago.
[06:37:23] <kjetilho> oh, good
[06:37:24] <ams> kjetil: i think he's referring to a lack of progress from long ago.
[06:37:38] <kjetilho> meeting is disbanding
[06:37:46] <Glenn Parsons> So is that the end?
[06:37:59] <kjetilho> yes
[06:38:06] <Glenn Parsons> secret notifications summit starting soon....
[06:38:13] <kjetilho> shhhh!
[06:38:17] <ams> !
[06:39:05] --- ams has left
[06:39:43] --- kjetilho has left
[06:41:07] --- randy has left
[06:41:15] --- fanf has left
[06:41:42] <Dave Cridland> S3kr3t notifications summit at 15:10+0100. (14:10 in Proper Time)
[06:42:06] --- frodek has left: Replaced by new connection
[06:42:22] --- Dave Cridland has left: Logged out
[06:42:40] --- resnick has left
[06:43:40] --- arnt has left
[06:48:51] --- dwf has left
[06:52:32] --- tonyhansen has left
[06:57:20] --- eburger has left
[07:10:17] --- Glenn Parsons has left
[09:22:16] --- arnt has joined
[09:23:15] --- arnt has left