[08:35:57] --- IETF LEMONADE has joined
[08:42:46] --- IETF LEMONADE has left
[08:54:24] --- Glenn Parsons has joined
[08:54:41] --- Glenn Parsons has left
[08:56:56] --- alexeymelnikov has joined
[09:10:41] --- Dave Cridland has joined
[09:11:23] --- arnt has joined
[09:11:40] --- Glenn Parsons has joined
[09:12:02] <Glenn Parsons> OK ... I had been trying rooms.jabber.ietf.org .....
[09:12:18] <Glenn Parsons> Thanks ALexey for the hint :-)
[09:12:45] --- LEMONADE has joined
[09:12:46] <alexeymelnikov> There was a recent announcement on the IETF mailing list about moving Jabber rooms.
[09:13:02] <alexeymelnikov> Who is "LEMONADE"?
[09:13:05] <Glenn Parsons> I'm glad someone is paying attention :-)
[09:13:10] <arnt> fwiw I won't be here all the time
[09:13:30] <Glenn Parsons> LEMONADE is the Mac that is projecting in the room
[09:13:50] <Glenn Parsons> FYI, Randy is stuck in Chicago
[09:14:00] <Glenn Parsons> He'll be here later this morning
[09:14:15] <Dave Cridland> I should equally warn that it's half-term, so if I get the kids running into my office, I may be somewhat distracted.
[09:14:35] <Glenn Parsons> understood
[09:14:49] <Glenn Parsons> We are waiting for STephane....
[09:14:53] <arnt> and any obscenities are the kids typing?
[09:15:13] --- kmurchison has joined
[09:15:20] <alexeymelnikov> Arnt, you write like Yoda ;-)
[09:16:17] <Glenn Parsons> Stephane notes that it took too long to fly to Ottawa....
[09:16:21] --- eburger has joined
[09:16:23] --- alexeymelnikov has left
[09:16:23] <arnt> German. at the end the verb comes.
[09:16:29] <Glenn Parsons> ...and that we should have had the meeting in Bangkok
[09:18:08] --- greg.vaudreuil has joined
[09:18:43] <greg.vaudreuil> I'm here
[09:19:26] --- alexeymelnikov has joined
[09:22:18] <alexeymelnikov> Centra wanted to restart my computer, so I said "No".
[09:23:15] <Glenn Parsons> that should not be necessary...
[09:24:11] <eburger> Is it OK if we post only PPT's for now?
[09:24:27] <Dave Cridland> Fine by me, they generally open with Openoffice.org/
[09:24:39] <alexeymelnikov> I would be Ok.
[09:25:12] --- eburger has left
[09:28:37] <alexeymelnikov> Are we planning to quickly review Phase 1 documents?
[09:33:35] <Glenn Parsons> So is anyone on Centra?
[09:33:47] <Glenn Parsons> If not I will stop it....
[09:35:36] <Dave Cridland> Centra?
[09:35:52] <Glenn Parsons> Windoze screen sharing
[09:36:06] <Dave Cridland> Not me, then.
[09:36:21] <Glenn Parsons> it is eating up our bandwidth....
[09:37:47] <Glenn Parsons> OK I will kill Centra for now....
[09:37:59] <Glenn Parsons> Let's get going....
[09:39:24] <Glenn Parsons> Slides are all available on the Proceedings web
[09:39:29] <Glenn Parsons> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
[09:41:52] --- kmurchison has left
[09:43:04] --- kmurchison has joined
[09:45:52] --- eburger has joined
[09:46:11] --- cromwellian has joined
[09:48:48] <eburger> I see Alexey, Arnt, Ray, Dave, Greg, Mike Parsell (on the bridge), and Ken; physically here are Ray, Jerry, and Stephane
[09:49:00] <eburger> We're on Slide 4 of the Chairs' Slides
[09:49:24] --- smaes has joined
[09:49:44] <eburger> Meeting info (including agenda and slides) are linked to at the supplemental web page, http://flyingfox.cantata.com/i-d/lemonade
[09:50:07] --- Dave Cridland has left
[09:50:09] --- Dave Cridland has joined
[09:50:22] <alexeymelnikov> I found chair's slides on Phase 1 status.
[09:50:24] --- smaes has left
[09:50:38] <eburger> Slide 5 - Agenda Bashing
[09:51:00] <alexeymelnikov> In addition to that: CONDSTORE is in AUTH48 as well, so I've just replied to the responsible RFC editor that the document is Ok.
[09:51:16] <eburger> Thanks Alexey!
[09:51:35] --- smaes has joined
[09:52:25] <eburger> Any comments on agenda?
[09:52:38] <eburger> Slide 6
[09:52:48] <eburger> Any comments on discussion order?
[09:53:22] <eburger> Proposed order is: draft-ietf-lemonade-futuredelivery -> draft-vaudreuil-futuredelivery draft-ietf-lemonade-reconnect draft-ietf-lemonade-rfc2192bis draft-ietf-lemonade-convert draft-ietf-lemonade-compress -> draft-ietf-lemonade-convert draft-ietf-lemonade-search-within draft-ietf-lemonade-vfolder draft-ietf-lemonade-notifications draft-ietf-lemonade-profile-bis draft-ietf-lemonade-deployments draft-ietf-lemonade-firewall-binding -> draft-maes-lemonade-tcp-challenged-environments draft-ietf-lemonade-streaming-convert -> draft-cook-lemonade-streaming draft-ietf-lemonade-imap-sieve
[09:53:59] <Dave Cridland> I'd say move profile bis to end - it'll alter depending on other discussions.
[09:54:30] <alexeymelnikov> I tend to agree with Dave
[09:54:57] <eburger> We put it forward for Alexey, but since he agrees with Dave, to the end it goes.
[09:55:23] <alexeymelnikov> Tomorrow morning would be better to Dave, myself and Arnt, I think.
[09:55:39] <eburger> That's when I think we'll get to it.
[09:56:02] <Dave Cridland> Tomorrow am is fine by me.
[09:56:32] <alexeymelnikov> IMAP Sieve needs more reviews
[09:57:22] <eburger> I'll send issues to Barry later on IMAP Sieve
[09:57:39] <eburger> Barry was going to get Cyrus to review work, but that will come later...
[09:57:49] <alexeymelnikov> Somewhat related to this: notifications in IMAP Sieve or using VFOLDERs
[09:58:25] <eburger> New order: draft-ietf-lemonade-futuredelivery -> draft-vaudreuil-futuredelivery draft-ietf-lemonade-reconnect draft-ietf-lemonade-rfc2192bis draft-ietf-lemonade-convert draft-ietf-lemonade-compress -> draft-ietf-lemonade-convert draft-ietf-lemonade-search-within draft-ietf-lemonade-vfolder draft-ietf-lemonade-notifications draft-ietf-lemonade-deployments draft-ietf-lemonade-firewall-binding -> draft-maes-lemonade-tcp-challenged-environments draft-ietf-lemonade-streaming-convert -> draft-cook-lemonade-streaming draft-ietf-lemonade-profile-bis draft-ietf-lemonade-imap-sieve [
[09:59:03] <eburger> Slide 7
[09:59:36] <Dave Cridland> Is anyone using the sip audio successfully, by the way?
[10:00:25] <alexeymelnikov> Dave: I don't
[10:02:13] <eburger> Goal: Updates by 19 June 2006, WGLC ASAP
[10:02:29] --- cromwellian has left
[10:03:01] <eburger> 7/19 is the deadline for -00's; 7/26 is the deadline for -xx's
[10:03:01] <alexeymelnikov> Is anybody taking notes in jabber?
[10:03:07] <eburger> Me (Eric)
[10:03:16] <alexeymelnikov> Ah, Ok.
[10:03:38] <alexeymelnikov> (I will have to disappear later, so would like to read notes after that.)
[10:03:47] <eburger> Understood
[10:04:34] <alexeymelnikov> Quickreconnect needs one more revision and then it can be last called by the WG.
[10:04:47] <alexeymelnikov> So deadlines are reasonable.
[10:05:17] <eburger> Slide 8
[10:05:56] <alexeymelnikov> Are we targetting to LC *all* documents after the next revision?
[10:05:57] <eburger> Debugging bridge -- hang on...
[10:06:08] <eburger> Glenn rips phone from wall.
[10:07:07] <eburger> All that are ready :) that means pretty much everything except streaming is the target.
[10:07:16] <alexeymelnikov> IMAP URL would need more than 1 revision to get fixed.
[10:07:26] <alexeymelnikov> I will need help from Mark Crispin.
[10:08:08] <alexeymelnikov> I will send Mark note.
[10:10:56] <alexeymelnikov> Profile Phase 1 has an Informative dependency on IMAP disconnected.
[10:11:23] <alexeymelnikov> Profile Phase 1 depends normatively on CONDSTORE.
[10:14:32] --- eburger has left: Replaced by new connection
[10:15:52] <alexeymelnikov> People in Ottawa having network/jabber issues at the moment...
[10:16:06] --- smaes has left: Replaced by new connection
[10:16:11] --- smaes has joined
[10:16:13] --- eburger has joined
[10:16:54] <LEMONADE> OK
[10:17:06] <eburger> Thank you Alexey for covering for me
[10:17:25] --- cromwellian has joined
[10:17:38] <alexeymelnikov> [I need a quick coffee injection. Be back in 2 minutes.]
[10:18:03] <eburger> Slide 9
[10:19:26] <LEMONADE> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=212
[10:19:39] --- anil has joined
[10:20:37] <alexeymelnikov> [I am back]
[10:21:35] <eburger> Update to MEM (OMA) Architecture Document to be published Wednesday
[10:22:02] <eburger> OMA TS work begun; makes lemonade profile bis a formal dependency
[10:22:41] <eburger> OMA meeting 5/17-19 in Kansas was cancelled; next one still planned for Osaka for 6/12-16
[10:23:00] <eburger> Architecture group will meet in Osaka (even though all work "occurs on mail lists")
[10:23:14] <eburger> Plan is to have TS done by end of year
[10:24:27] <eburger> We should tell OMA when we get to WGLC (probably done at or before Montreal meeting - IETF 66)
[10:25:52] <eburger> Should we tell OMA about our already-RFC'ed documents? Yes; Stephane thinks we should also mention the drafts that will shortly be WGLC'ed to demonstrate progress
[10:28:03] <eburger> We will send a response tomorrow, after we know what looks close to WGLC.
[10:28:48] <eburger> Adding OMA liaison discussion to very, very end of Interim Meeting
[10:29:21] <eburger> Stephane: do we want to get a presentation from OMA about how they will be using our stuff?
[10:30:15] <eburger> Do we want to use meeting time in Montreal?
[10:30:17] <alexeymelnikov> I would personally be interested to see OMA slides on using Lemonade.
[10:30:40] --- cyrus_daboo has joined
[10:30:52] <alexeymelnikov> But this doesn't have to be a live presentation at Montreal.
[10:32:57] --- Glenn Parsons has left
[10:34:07] <eburger> Eric just sent a note to the list.
[10:34:15] <eburger> Document Issues
[10:34:27] <eburger> Future Delivery
[10:34:45] <eburger> Not much to tell: last meeting to do as an individual submission
[10:35:08] <eburger> IESG sent to IETF last call on Thursday 5/25. Should be a four-week clock.
[10:38:51] <alexeymelnikov> QuickReconnect, lemonade-0.ppt, slides 11-14
[10:39:04] <cromwellian> one of the things being discussed in the Notificiations draft is resolving the differences between message store events (chris newman's msgevents draft) with the out of band and inband event delivery mechanisms. IDLE is the inband delivery mechanism, so I am curious as to how we might use reconnect to deliver in-band events that got queued because the client temporary lost connectivity when he was in an IDLE state. But this will probably have to wait until a clear definition of IDLE (CLEARIDLE :) ) can be defined as to which message store events must generate which unsolicited responses.
[10:39:28] <Dave Cridland> IDLE isn't an in-band mechanism.
[10:40:27] <Dave Cridland> IDLE is an interesting hack to force a command to be in progress to allow EXPUNGE messages to be sent. Other than that, a server can send any other response at any time, whether the client is IDLE or not. IDLE tends to indicate the client is ready for them, but that's about it.
[10:40:51] <eburger> Slide 11
[10:41:07] <eburger> Slide 12
[10:41:16] <cromwellian> that was the point of CLEARIDLE which is that IDLE didn't mandate enough behavior, so at best, it could be a signal to wakeup and do something
[10:41:37] <cromwellian> the author of the clearidle draft wanted to make it a mechanism to deliver some message store events
[10:42:08] <Dave Cridland> Yes, Barry Leiba is doing an updated IDLE which will hopefully clarify some misconceptions. In the meantime, i've added "timely" to the IDLE bit in Profile Bis to compensate.
[10:42:23] <eburger> Slide 14
[10:42:45] <eburger> Open issues: do we make LOGOUT parameters consistent with IMAP ABNF?
[10:42:47] <cromwellian> do you think we need a separate mechanism for inband notification delivery, or do you think future idle extensions would be legit?
[10:43:01] <Dave Cridland> Ah, that's another issue. But the distinction between IDLE and the responses should be maintained, I think. Mixing the two suggests that you can't get the notifications whilst you're not IDLE.
[10:43:04] <eburger> Decide on minimum mandatory to implement number of resumable sessions. Thoughts?
[10:43:55] <Dave Cridland> You don't extend IDLE, you extend the notifications possible - the server should just send those whenever it can, which will probably be during a command - which in turn might be the command IDLE.
[10:44:24] <eburger> Stephane offers to not state a mandatory minumum
[10:45:15] --- Glenn Parsons has joined
[10:45:22] <eburger> Alexey: can write a client that konws and relies on minimum
[10:45:39] <cromwellian> oh I see. is there any problem with older clients getting sent responses for which they are not prepared, or are properly coded clients required to ignore?
[10:45:39] <eburger> Eric: doesn't really help, as *other* client can use up some of the sessions
[10:45:52] <cromwellian> I mean when not in an IDLE state
[10:46:57] <cromwellian> im thinking of a case where say, in the middle of acommand, lik fetch 1:*, some new notification respones will appear, and if this will cause some clients to blow up
[10:46:58] <Dave Cridland> Clients have to accept a response at any time. Typically, they'll do that by not bothering to check the inbound socket unless there's a command in progress, and the server has to cope with that - which is generally done by not sending responses outside of a command.
[10:47:02] <alexeymelnikov> Alexey: server can advertise how many left? (Can add a new response code)
[10:47:25] <cromwellian> maybe im being too paranoid
[10:47:39] <Dave Cridland> Oh, that case is dealt with all the time - you get EXISTS or RECENT anyway during a FETCH. EXPUNGE if it's a UID FETCH.
[10:47:56] <Dave Cridland> And a client will only get these new notifications if it asks for them, of course.
[10:49:18] <cromwellian> ok, so to summarize, an inband delivery mechanism should define a mechanism for a client to tell the server to subscribe to notifications (inband), and a list of responses the server may generate for each event
[10:49:21] <eburger> Eric: client has to deal with running out of sessions no matter what, because multiple clients can screw things up royally.
[10:49:32] <eburger> Alexey agrees - be silent
[10:50:01] <eburger> Now, for the big one: do we need server-side quick-reconnect?
[10:50:51] <eburger> What state needs to be saved? Most parameters are per-session.
[10:50:55] <eburger> (not per-client)
[10:51:12] <arnt> this is the RECONNECT draft?
[10:51:32] <eburger> It is possible for the client to keep the state
[10:51:32] <cromwellian> alexy is currently discussing reconnect
[10:51:57] <eburger> Eric: that would be good, as there would be no (or little) fate sharing. If client dies, state dies with it.
[10:51:58] <Dave Cridland> Yes. Except me and Ray are having a moment of cross-talk, which we ought to take somewhere else, really.
[10:51:59] <arnt> I don't see a very big advantage to that, but implementing it can speed up the ordinary SELECT in some fairly common cases. which is desirable for me.
[10:52:00] <cromwellian> I was discussing how do we design an inband notification mechanism
[10:52:09] <cromwellian> yeah, sorry about that
[10:53:01] <arnt> so perhaps RECONNECT is good, but not in scope for LEMONADE. not sure.
[10:53:03] <eburger> So, propose to make extension use client-side state
[10:53:04] <arnt> must be off again.
[10:53:13] <eburger> We can always add server-side state in the future
[10:54:24] <eburger> Ray: this means the client would need to send state to the server.
[10:54:35] <eburger> Question to Alexey: how much data are we talking about?
[10:54:46] <alexeymelnikov> The parameters that are passed to the SID command when a session is resumed defines pretty much all per-mailbox state.
[10:55:05] <Dave Cridland> It's not a lot of state, unless we want to persist recent state, non-permenent flags, etc.
[10:55:28] <alexeymelnikov> Eric: 3 parameters: UIDVALIDITY, HIGHESTMODSEQ and uid set
[10:55:57] <cromwellian> how does it know what folder it was in alexey? dont u need to transmit that too if it is only stored on client?
[10:56:00] <Dave Cridland> Oh, and mailbox path.
[10:56:29] <alexeymelnikov> Yes, Dave is correct, we need malbox name
[10:56:58] <Dave Cridland> Alexey: Did you mention the notion of moving/duplicating this to SELECT as well?
[10:57:30] <cromwellian> can we do a quick estimate on # of bytes on say, reestablishing to INBOX? I'm curious how mujch data is saved on this approach vs just reissuing the imap commands as normal to get back to the old state, especially when using compress=deflate
[10:58:17] <Dave Cridland> Bandwidth isn't much. Round-trips, though, is about 0-2 saved, depending on the extensions used.
[10:58:27] <alexeymelnikov> Dave: no I haven't. Minor implementation detail ;-)
[10:58:56] <cromwellian> true, roundtrips reduced, forgot about that
[10:59:08] <Dave Cridland> Alexey: Pretty major, I think. Allows for a reduction is the SASL/TLS round-trips and data, by reducing the number of IMAP sessions needed.
[11:01:02] <Dave Cridland> It's much the same difficulty to implement either server-side state of client-side state. Easier if we move it to SELECT, because then it's a generic. The only thing clients lose is RECENT, on most servers, and we risk that all the time anyway with existing servers.
[11:02:19] <Dave Cridland> Yes, it's too expensive to move it to SELECT if there's server-side state involved.
[11:02:33] <eburger> Ray: Moving to SELECT means that we then could run out of sessions way faster. If a device SELECT's multiple folders, it opens multiple sessions
[11:03:17] <eburger> Do we have consensus to not put into SELECT?
[11:03:36] <alexeymelnikov> Ray: this is no worse than the current situation, when client needs to have multiple connections to monitor changes in multiple mailboxes.
[11:04:09] <cromwellian> right, forgot about that
[11:04:14] <alexeymelnikov> In IMAP each TCP connection can have only a single mailbox selected at any time.
[11:04:21] <cromwellian> except with CLEARIDLE :) they had multiple monitoring :)
[11:06:30] <Dave Cridland> [I'm off audio at the moment.]
[11:06:59] <alexeymelnikov> With server side state client would issue:
[11:07:24] <alexeymelnikov> SID <session-id> <UIDVALIDITY> <MODSEQ> <uid list>
[11:07:37] <eburger> Ray: thinking of concept of having server send opaque token for whatever's missing to have the client send back.
[11:07:39] <alexeymelnikov> With client side state the client would do:
[11:07:47] <eburger> Ray: probably not much of a savings :(
[11:07:58] <alexeymelnikov> SELECT <mailboxname> <UIDVALIDITY> <MODSEQ> <uid list>
[11:08:19] <alexeymelnikov> So you can see it is pretty much the same
[11:08:45] <eburger> Alexi - how long will it take to write-up?
[11:08:55] <Dave Cridland> Ray: Basically if you move reconnection to SELECT *and* remove the server-side state, then you have a fast SELECT, which means that monitoring changes in non-selected mailboxes can be less intensive - the server could just send unsolicited STATUS for subscribed mailboxes, for instance, indicating to the client that a change has happened - the SELECT-and-synch becomes cheap enough for the client to run itself.
[11:09:31] <alexeymelnikov> I suggest the following:
[11:09:31] <alexeymelnikov> 1)
[11:09:33] <alexeymelnikov> go with client side state (a new draft)
[11:09:46] <cromwellian> alexey, depending on the length of the session-id string, SELECT could be shorter than SID :) cause mailbox name could be shorter than session-id
[11:09:52] <alexeymelnikov> 2) publish server side variant as Experimental
[11:10:31] <alexeymelnikov> Lemonade Phase 2 should reference the client side variant, unless it is clear that this would not be sufficient
[11:10:52] <alexeymelnikov> (And if we do Lemonade Phase 3, it can reference server side)
[11:10:56] <eburger> Sounds good.
[11:11:17] <Dave Cridland> I'm with Alexey.
[11:11:26] <cromwellian> i agree
[11:11:49] --- mrcrispin@jabber.org has joined
[11:11:58] <Glenn Parsons> why experimental?
[11:12:00] <alexeymelnikov> I don't really care about Experimental versa Standard Track
[11:12:04] <Glenn Parsons> OK
[11:12:21] <alexeymelnikov> Experimental is because "we don't know if this is going to be useful"
[11:12:35] <Dave Cridland> Easier to publish. Easy to move from Experimental to Standards Track if people actually implement it, too.
[11:12:59] <alexeymelnikov> Yes, reclassifying Experimental to Standard Track is not that difficult.
[11:13:06] <cromwellian> i guess one issue with server side state is that the list of state could be expanded in the future without any changes in clients
[11:13:18] <Glenn Parsons> The experimental state is confusing
[11:13:50] <alexeymelnikov> Ray: yes, you are correct. This is the main decision criterion.
[11:14:51] <alexeymelnikov> I personally would implement Experimental if I need it.
[11:15:10] <Dave Cridland> Ray: But we only need to worry about session state - non permanent stuff. Any persistent state (annotations, for instance) is already persisted, and covered by things like CONDSTORE.
[11:15:14] <cromwellian> couldn't we have a mechanism just like URLAUTH where we ask the server to give us a "frozen" bit of state whicfh the client saves, and then sends back on reconnect
[11:15:28] <cromwellian> so the client saves state, but it doesn't construct the state saving string, it'd opaque
[11:15:48] <cromwellian> or we could add an extra opaque token to the current list of arguments for future expansion
[11:16:21] <alexeymelnikov> Ray: I need to think about your idea.
[11:16:24] <cromwellian> SELECT mbox UIDvalidity modseq uidlist extension-state-opaque-token
[11:16:34] <Dave Cridland> Ray: An optional opaque token at the end, you mean?
[11:16:36] <eburger> Current document is server-based; new document will be client-based.
[11:16:48] <cromwellian> then you ask the server to make you one of these tokens and store it on the client
[11:16:54] <Dave Cridland> Ray: Just add another SELECT parameter for that later - doesn't have to be in this specification.
[11:17:03] --- kmurchison has left
[11:17:46] <Dave Cridland> Ray: It'll look like SELECT (CONDSTORE (SYNCH uidvalidity modseq uidlist) (SYNCHTOKEN magical)) I think.
[11:17:48] <cromwellian> I suppose we could have a reconnect-bis that adds arbitrary state
[11:18:18] <cromwellian> but maybe it is better to have the exension stuff in there now than have 2 separate drafts with completely different syntax
[11:18:28] <eburger> draft-ietf-lemonade-reconnect-client-00
[11:22:17] <eburger> Summary: Dave and Alexey realized that it is the same number of bytes and round-trips to have the client store the state for reconnect than to have the server store the state. Alexey believes it is a small number of edits to make the change to the document. Because of our short time-lines, we will not abandon the server-side RECONNECT mechanism. Rather, we will have a new document, draft-ietf-lemaonde-reconnect-client, that will describe the client-side mechanism. The work group will examine both drafts and preferably pick one approach. That approach will go standards-track while the other will die. Less preferably, we can keep both drafts, make one Experimental, and reference the standards-track document in Profile bis. Least preferably, we go with both drafts.
[11:22:21] <eburger> (sent to list)
[11:22:29] <Glenn Parsons> IMAP URL is next
[11:24:10] <eburger> Alexey - OK to start without Mark? He's on line, but not responding (probably doing the Coffee Thing)
[11:24:27] <eburger> Slide 16
[11:28:17] <Glenn Parsons> Alexey...
[11:28:32] <Glenn Parsons> what point are you suggesting MArk assit you with?
[11:28:46] <Dave Cridland> URLAUTH text, isn't it?
[11:28:51] <Dave Cridland> (See slide 18)
[11:28:58] <Glenn Parsons> ah
[11:29:03] <Glenn Parsons> jumped ahead OK
[11:30:07] <eburger> Need help from Mark on which URLAUTH text belongs in the document
[11:31:56] <alexeymelnikov> I would suggest that Mark does a revision of URLAUTHbis as a draft, it should only contain IMAP URLAUTH extension.
[11:32:17] <mrcrispin@jabber.org> Well, what is it that URLAUTH has that shouldn't be there?
[11:33:40] <alexeymelnikov> Mark: Definition of IMAP URL extensions is moving to IMAP URL bis document
[11:34:11] <alexeymelnikov> So we need to decide where definitions or URLAUTH terms go
[11:35:39] <mrcrispin@jabber.org> Nothing particularly sticks out to me, other than the change to authimapurl
[11:37:07] <alexeymelnikov> Mark: I will send you an email, describing my editorial issues.
[11:38:56] <cromwellian> an obvious extension would be CONVERT support,but not needed for message assembly/submission
[11:39:13] <eburger> Will we include examples of other extensions in URLAUTH? BINARY URLFETCH? imap-search-ret? list-extensions?
[11:39:39] <eburger> Answer: if stable, yes, if no, no. Find out by Alexey sending note to list; if he doesn't hear back from authors, assume NOT stable
[11:44:58] <eburger> We are moving to the lemonade-1 set of slides ("Update Draft Statii"), found on the Meeting Materials Web Site https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
[11:45:42] <eburger> We're adding slide numbers in our copy; you may wish to do the same.
[11:45:51] <eburger> We are on Slide 21 - CONVERT
[11:45:55] <eburger> Slide 22
[11:46:52] <eburger> Consensus for Mandatory-to-Implement is ISO-8859-n to UTF-8 for text/plain; couldn't get consensus on text/html -> text/plain, so listed as desirable.
[11:47:26] <eburger> Same for image conversions (since written up already, decided not to pull out of document, just changed requirements level)
[11:49:19] <alexeymelnikov> Russian is ISO-8859-5, please keep it in the document ;-)
[11:49:51] <mrcrispin@jabber.org> But isn't Russian primarily in KOI8-R or the Windows CP?
[11:50:26] <alexeymelnikov> I think all 3 are quite common. I usually use KOI8-R.
[11:52:03] <mrcrispin@jabber.org> Hmm. The Russian spammers seem to prefer KOI8-R or CP1251... ;-) But I agree that any software that claims to support Russian has to handle all three seamlessly.
[11:54:20] <mrcrispin@jabber.org> I'm not convinced that there is much difficulty with charset conversion *to* UTF-8. Converting *from* UTF-8 is more difficult. I've done both for years.
[11:54:49] <mrcrispin@jabber.org> It also isn't all that difficult to handle Shift-JIS, EUC, ISO 2022 for Japanese. Just programming.
[11:54:56] <alexeymelnikov> Cyrus Imapd server already supports conversion of ISO-8859-* to UTF-8. I think UWash does as well.
[11:55:48] <mrcrispin@jabber.org> In fact, UW can do US-ASCII UTF-8 UTF-7 ISO-8859-1 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-9 ISO-8859-10 ISO-8859-11 ISO-8859-13 ISO-8859-14 ISO-8859-15 ISO-8859-16 KOI8-R KOI8-U KOI8-RU TIS-620 VISCII GBK GB2312 CN-GB ISO-2022-CN CN-GB-12345 BIG5 CN-BIG5 BIG-5 ISO-2022-JP EUC-JP SHIFT_JIS SHIFT-JIS ISO-2022-JP-1 ISO-2022-JP-2 ISO-2022-KR EUC-KR KSC5601 KSC_5601 KS_C_5601-1987 KS_C_5601-1989 KS_C_5601-1992 KS_C_5601-1997 WINDOWS-874 CP874 WINDOWS-936 CP936 WINDOWS-949 CP949 X-WINDOWS-949 WINDOWS-1250 CP1250 WINDOWS-1251 CP1251 WINDOWS-1252 CP1252 WINDOWS-1253 CP1253 WINDOWS-1254 CP1254 WINDOWS-1255 CP1255 WINDOWS-1256 CP1256 WINDOWS-1257 CP1257 WINDOWS-1258 CP1258 IBM367 IBM437 IBM737 IBM775 IBM850 IBM852 IBM855 IBM857 IBM860 IBM861 IBM862 IBM863 IBM864 IBM865 IBM866 IBM869 IBM874 ANSI_X3.4-1968 UCS-2 UCS-4 UTF-16!
[11:56:11] <alexeymelnikov> Mark: Ok, I am impressed :-)
[11:56:20] <mrcrispin@jabber.org> I thought you would be.
[11:56:28] <eburger> Even though Glenn doesn't remember :), we'll stick with ISO-8859-n to UTF-8
[11:56:32] <mrcrispin@jabber.org> It's all a matter of tables...
[11:57:01] <Glenn Parsons> so what is 8859-12 I wonder :-)
[11:57:38] <mrcrispin@jabber.org> 12 is reserved for ISCII (India)
[11:58:28] <Glenn Parsons> I also support leaving text/html -> text/plain as desirable/optional
[11:59:02] <eburger> BTW, MTI is Mandatody To Implement; another TLA
[11:59:03] <mrcrispin@jabber.org> I agree with Glenn. A basic HTML->text engine is a good thing.
[12:03:45] <mrcrispin@jabber.org> back in about 5 minutes...
[12:04:04] <Glenn Parsons> we'll be breaking for lunch at noon-ish ET
[12:04:09] <Glenn Parsons> in about 5 minutes....
[12:05:16] <eburger> Section 6.1.1 for conversions: it is an Informative section, so all of the 2119 language really MUST be MAY (pardon the pun)
[12:07:46] <eburger> Getting to Lunch Time
[12:07:56] <eburger> Do we want to talk about Comression and Encryption after lunch?
[12:08:52] <eburger> Will UK attendees be rejoing us in an hour?
[12:09:00] <cromwellian> is arnt's deflate document on the agenda? did it expire?
[12:09:04] <Dave Cridland> I think I can.
[12:09:09] <Glenn Parsons> OK
[12:09:15] <Glenn Parsons> see everyone in 1 hour
[12:09:19] <Glenn Parsons> 1pm ET
[12:09:28] <Dave Cridland> 6pm UK.
[12:09:32] <Glenn Parsons> 6pm BST
[12:09:46] <Glenn Parsons> 10am PT
[12:12:47] --- resnick has joined
[12:15:02] --- cromwellian has left
[12:15:29] --- smaes has left
[12:15:50] <Dave Cridland> Pete: They've just broken for lunch.
[12:16:00] <resnick> I figured that out. :)
[12:16:08] <resnick> I'll dial in after lunch.
[12:16:14] <Dave Cridland> Oh, yeah, XMPP gives you a backlog, doesn't it?
[12:16:36] <resnick> Yup. Backwards in this case, which is unusual (i.e., the latest messages came in first).
[12:16:47] <resnick> How far along in the slides did you get?
[12:17:57] <Dave Cridland> Did up to URL (2192bis) in -0, then covered CONVERT in -1.
[12:18:24] <Dave Cridland> Profile Bis has been moved to (nearly) the end from the agenda, BTW.
[12:18:42] <resnick> OK. So we're on to compress next?
[12:18:56] <Dave Cridland> COmpression and Encryption after lunch.
[12:19:09] <resnick> Better on a full stomach. :-)
[12:20:08] <Dave Cridland> Given I've been running stream compression on IMAP and ACAP since just after Dallas and have some figures on performance, then yes, I think everyone would do better to have eaten first. :-)
[12:21:05] <resnick> And the answer is.......?
[12:21:56] <Dave Cridland> Well, I compress by 70-75%, or to between a quarter to a third of the size, using stream-based compression.
[12:22:14] <resnick> Impressive.
[12:22:45] <resnick> You're not using BINARY are you?
[12:22:48] <Dave Cridland> ACAP compresses really well, IMAP compresses pretty well. Those are down figures - up figures are worse, but I still see 50%.
[12:22:50] <Dave Cridland> Yes.
[12:22:56] <Dave Cridland> I use *everything*. :-)
[12:23:30] <resnick> If you're using BINARY, then those figures are pretty kick-ass.
[12:24:47] <Dave Cridland> Pete: But I don't get many attachments. Arnt has some interesting findings, too. Like, COMPRESS=DEFLATE can perform better than TLS-level deflate, because of the level of control an application has - ie, the APIs need improvement for TLS compression.
[12:27:10] <Dave Cridland> Pete: THis is using CONDSTORE and ESEARCH, too, and I'm down to 70% compression (or 30% of the original size) after 17k has come down the line.
[12:29:47] <mrcrispin@jabber.org> Interesting indeed. My standard answer to those who complain about IMAP's chattiness has always "IMAP is designed to be readily compressible." I didn't realize it was *that* compressible... ;-)
[12:33:21] <Dave Cridland> Mark: I did wonder if by having conversations in email about the IMAP protocol I was skewing the figures, though. ;-)
[12:38:45] --- Anil Srivastava has joined
[13:08:26] --- LEMONADE has left: Logged out
[13:12:55] <Dave Cridland> Are we post-lunch yet?
[13:13:30] <alexeymelnikov> I am :-)
[13:14:07] <eburger> Post dinner? :-) We're filtering back down. Audio should be up soon (new phone).
[13:14:13] <Dave Cridland> By several hours.
[13:14:30] <Dave Cridland> I can hear someone's sound-effects every time anyone sends a message through the phone, actually.
[13:15:08] <mrcrispin@jabber.org> That may be me, this stupid Jabber client makes noise every time someone says something. Let me see if I can mute it.
[13:15:40] <alexeymelnikov> No, I just had lunch.
[13:16:22] <Dave Cridland> Alexey: You're running a little late, aren't you?
[13:16:47] <Dave Cridland> Aw. I rather liked the demented seal noise.
[13:17:40] <Dave Cridland> Well, it had my seal of approval. :-)
[13:17:42] --- smaes has joined
[13:18:06] <alexeymelnikov> Dave: yes, I've mentally in Ottawa ;-)
[13:19:09] --- kmurchison has joined
[13:20:53] <Glenn Parsons> We will resume as soon as Ray (our presenter) returns from lunch
[13:24:08] <resnick> What''s the access code for the bridge. The one in the slides doesn't seem to be working.
[13:24:09] <arnt> Pete: I had my research rudely interrupted before I got too far. a sick child does not help work. but I did find that even at its least CPU- and RAM-heavy setting, zlib compresses IMAP very well. I have a whole bunch of IMAP connections that compressed to 15% of the regular size, and most are in the 25-40% range. however, attachments sized about 10k-100k throw the compression. I wanted to try sending a flush at strategic points, and I will do it when the IESG approves draft-newman-i18n-comparator.
[13:25:30] <alexeymelnikov> Pete: the access code on the web page worked for me
[13:25:47] <Dave Cridland> Pete: There's a message on the mailing list, subject includes "ottawa", that has a bunch of access numbers and the code.
[13:26:18] <resnick> I'll try it again. Thought that's what I had.
[13:26:47] <alexeymelnikov> Right, I was actually using access code from Glenn's message.
[13:26:48] <arnt> attachments fetched with BINARY are more compression-friendly than without, although that's not a reliable conclusion. more intuition based on a very few attachments.
[13:28:08] <eburger> Pete - after you download the lemonade-1 slides (hint), you will want to add slide numbers so you can follow along.
[13:28:18] <eburger> Slide 23
[13:28:39] <resnick> Will do. I can sort of see from the iChat video.
[13:28:40] <Dave Cridland> Arnt: I found that base64 is not fully compressed away, so that would fit.
[13:29:27] <arnt> Dave Cridland: I thought it was because the backquote mechanism has 70% fewer opportunities.
[13:30:52] <resnick> Chris favored object-level?
[13:31:18] <smaes> Yes - see minutes
[13:31:25] <Dave Cridland> Pete: Chris suggested a compressed-literal construct.
[13:31:29] <smaes> Sorry jabber logs
[13:31:50] <smaes> CHris made also that suggestion that is correct
[13:32:21] <eburger> Problem: how to disambiguate C-T-E from Content-Type
[13:32:51] * eburger has changed the subject to: Compression (continued)
[13:36:22] --- randy has joined
[13:38:17] <eburger> Glen - Content-Type not well supported (experience from VPIM)
[13:38:30] <eburger> Glen - propose new MIME types
[13:42:01] <eburger> We're talking not about gzip file format, but content compressed with the DEFLATE algorithm
[13:42:31] <smaes> sorry chris statement was about encryption
[13:42:50] <resnick> Thought so.
[13:46:52] <eburger> Randy - Server advertises it can do compression; Client responds it's OK to do compression
[13:47:04] <eburger> In this situation, client will understand C-T-E: DEFLATE
[13:55:08] <resnick> Mark, is this version of the "consenting adults" reasonable?
[13:55:18] <randy> In Dallas, Ned made compelling arguments that there were no use cases for a client to *not* want data to be compressed if it was reasonable to compress; servers are in much better position to know which data to compress. Hence we need a new CAPABILITY, a way for clients to say "compress at will", and a way for clients to know that compression was done.
[13:57:05] <arnt> randy: compress=deflate sounds like that, not?
[13:57:28] <randy> yes it does
[13:57:29] <arnt> if the server doesn't want to compress, it just sends a really long string with no backquotes, done.
[13:59:45] <Dave Cridland> Arnt: Uncompressed-type DEFLATE blocks.
[14:00:27] <eburger> Summary: (1) remove compression from CONVERT draft (2) separate draft describing how CONVERT does compression (3) server automatically choses what to convert. if server converts, you get body part with something like 'deflate' content-transfer-encoding
[14:01:11] <Dave Cridland> Why are we only compressing body parts?
[14:01:23] <eburger> Client does *not* ask for compression on a body part-by-body part basis
[14:01:45] <resnick> dwd: We haven't gotten there yet. I think it should be session-level.
[14:01:54] <eburger> Server makes choice as to whether or not to compress boday parts (e.g., don't bother compressing JPEGs)
[14:02:03] <Dave Cridland> Pete: Ah, ta.
[14:02:11] <eburger> It is session level, in that
[14:02:25] <eburger> the client says "OK to compress from this point on, by your leave"
[14:02:51] <eburger> *but*, the client can always say, "It is NOT OK to compress from this point on"
[14:02:59] <Dave Cridland> Eric: My IMAP sessions compress by ~70% before I've even read an email.
[14:03:26] --- cromwellian has joined
[14:03:46] <eburger> Ah - confusion on "session"
[14:04:05] <eburger> Transport level (TLS), service level (?), object level compression
[14:08:44] --- LEMONADE has joined
[14:09:38] <Glenn Parsons> Randy & Pete discussing what is 'obejct level' and is it necessary....
[14:13:06] <Dave Cridland> This sounds like a solution searching for a problem.
[14:13:13] * resnick nods
[14:13:26] <resnick> It fills a well-needed gap.
[14:14:01] <Dave Cridland> If you're doing object-level compression, you're missing out on compressing all the IMAP protocol, ENVELOPEs, etc, that compress astonishingly well.
[14:14:13] <randy> What fills a much-needed gatp?
[14:14:21] <resnick> Object-level compression.
[14:14:23] <eburger> service level (compress=deflate?) It depends on what your definition of "it" is :)
[14:14:32] <randy> Personally, I like compress=deflate
[14:15:13] <randy> I'm just saying that if people really want object-level (so JPEGs don't get compressed) then do it such that clients only have to ask at the start of the session.
[14:15:43] <resnick> JPEGs don't get compressed with compress=deflate.
[14:19:39] <randy> Is that in imap-deflate-02?
[14:19:50] <randy> I must have missed that
[14:21:53] <randy> [[ Milk and cookies arrived! ]]
[14:22:48] <resnick> (I was saying that JPEGs don't *need* to get compressed with compress=deflate turned on.)
[14:23:12] <randy> How so?
[14:23:18] <randy> (I don't see this in the draft)
[14:23:31] <Dave Cridland> Randy: It's in RFC1952.
[14:24:53] <randy> OK, thanks
[14:25:36] <randy> Then the only possible objection to compress=deflate that I can think of is that the client must compress its commands, which potentially is more complex then decompressing
[14:28:12] <arnt> randy: people don't trust the math in RFC 195[012].
[14:30:35] <randy> Whoever is speaking is very distorted
[14:30:42] <randy> I am having a hard time making it out
[14:31:24] <randy> Arnt: in what way?
[14:31:56] <eburger> compress=deflate is in imap-deflate-02 draft
[14:32:27] <Dave Cridland> Randy: Sorry, I was saying that Arnt needs to add the ability to not compress up, because the client might not have the resources to do so, and the uplink compresses much worse (still halves the data, but it's nothing like as good as the downstream link)
[14:33:15] <Dave Cridland> Randy: Also, deflate uncompressed blocks are pre-counted, not streamed, so each send would gain 5 octets if sent within deflate.
[14:33:29] <resnick> Does anyone have any statistics that power usage for compression is *higher* than the power for radio sending all of the extra data?
[14:33:58] <arnt> no, but dave will have that when he receives his new gadget ;)
[14:34:03] <Dave Cridland> I have no data either way. Someone made the assertion in the London Interim.
[14:34:09] <eburger> My gut is the oppositite is true (radio is *much* more expensive than CPU)
[14:34:14] <resnick> Mine too.
[14:34:25] <Dave Cridland> Oh, sorry. I meant made the opposite assertion.
[14:34:51] <resnick> Right.
[14:34:58] <Dave Cridland> Ray: No, that's 5 octets per *uncompressed* block
[14:35:05] <Dave Cridland> If you're compressing, it's less.
[14:35:07] <arnt> I have to leave.
[14:35:14] <resnick> l8r Arnt.
[14:35:21] <Dave Cridland> Toodle pip, Arnt.
[14:35:47] <resnick> Any comments on the bidirectionality issue, Arnt?
[14:35:58] <resnick> (I.e., different compression for upstream and downstream)
[14:37:41] <Dave Cridland> I seem to recall some comments from Arnt saying he was open to the idea, a while back.
[14:38:45] <Dave Cridland> By the way, SASL interactions and general setup of IMAP compresses quite well.
[14:40:01] <cromwellian> compress=deflate can be done in unauthenticated state right?
[14:40:13] <Dave Cridland> I just got IMAP connection compressing by roughly 30%, and by 50% after a SELECT/resynch sequence, to give some rough figures.
[14:40:21] <Dave Cridland> Ray: Yes.
[14:40:30] <resnick> I only picked up part of that. Could someone repeat in text what Stephane said?
[14:40:51] <Dave Cridland> [I need to go put my son to bed, I'll be away for a bit]
[14:41:04] <resnick> What a good papa.
[14:41:27] <Dave Cridland> [Not really, I've shoved him on the sofa for this bit with a load of cake and a video]
[14:42:19] --- randy has left
[14:45:08] <eburger> Summary: (1) Going back to COMPRESS in its own document (not CONVERT) (2) Consensus that compression is directional, e.g., downstream compressed, upstream uncompressed (3) Basis for COMPRESS document is Arnt's imap-deflate-02 [compress=deflate]; call it draft-ietf-lemonade-compress-04 (gut existing compress text) (4) Protocol allows for client to turn it on or off at will (not per body part, but point in time in session)
[14:45:45] <resnick> That seems a little odd. How much of draft-ietf-lemonade-compress-03 will remain?
[14:45:56] <eburger> none?
[14:46:06] <eburger> Arnt new editor
[14:46:09] <Glenn Parsons> Randy called it 'gut and amend'
[14:46:14] <resnick> Then why not do draft-ietf-imap-deflate-00.txt?
[14:46:26] <resnick> /simap/lemondae
[14:46:33] <eburger> because of confusion that we have multiple compress proposals
[14:47:54] <alexeymelnikov> We can ask secretariat to remove [old] compress from the Lemonade WG web page?
[14:48:12] <alexeymelnikov> Ray: no, don't rename WITHIN
[14:48:17] <eburger> Yes (we can ask to have the old draft expunged)
[14:50:03] <alexeymelnikov> Pete: yes, this is how SASL does security layers.
[14:50:38] <alexeymelnikov> (SASL specifies exact byte when the layer starts in both directions)
[14:51:10] <cromwellian> alexey, im not renaming it, just mentioning the comment I got. otherwise, I'd have to call it "draft-....-younger-older-00.txt" which is worse :)
[14:51:16] <mrcrispin@jabber.org> not just SASL; STARTTLS too.
[14:52:14] <eburger> Note to Arnt: look to how SASL does security layers; there is an issue of pipelined commands where commands in progress are streaming a compressed result and the client says, "stop compression". We say, 'wait'.
[14:52:56] <alexeymelnikov> Arnt: and the same for stop compressing.
[14:53:00] --- anabolism@jabber.org has joined
[14:53:15] <eburger> Who is anabolism
[14:53:22] <resnick> Randy
[14:54:28] <alexeymelnikov> Posting notes to the mailing list would summarize issues for the mailing list.
[14:56:12] <alexeymelnikov> Ray: You waited for Arnt to leave to talk about VFOLDER ;-)
[14:56:36] <resnick> Maybe push that to tomorrow morning?
[14:56:39] <anabolism@jabber.org> (gut & amend or something like that is what they call it when legislators want to introduce a new bill after the deadline for doing so -- they amend an existing bill by deleting all existing text and adding new -- the old bill number remains)
[14:56:53] --- anabolism@jabber.org has left
[14:56:58] <Glenn Parsons> NExt topic
[14:57:01] --- randy has joined
[14:57:02] <Glenn Parsons> Encruption
[14:57:19] <Glenn Parsons> slide 24
[14:57:20] * eburger has changed the subject to: Encryption
[14:59:00] <Glenn Parsons> section 11 of the COVNERT-03 draft
[15:11:04] <eburger> Do dissertation of why need object encryption (business/use case) in separate draft; resurrect ENCRYPT draft.
[15:13:07] * eburger has changed the subject to: WITHIN
[15:14:03] <eburger> Slide 14
[15:15:06] <alexeymelnikov> I am wondering if WITHIN should operate with hourly resolution? For high priority messaging.
[15:15:31] <eburger> Slide 15
[15:16:00] <Dave Cridland> For my part, I'm not entirely sure why second-level resolution is a bad thing.
[15:17:12] <eburger> Take look at draft
[15:17:33] <alexeymelnikov> Ray: ABNF is still wrong ;-) (missing SP)
[15:18:36] <Dave Cridland> Yes, but maybe I'm just really stupid, but wouldn't you just note the next time a recompute was actually needed?
[15:18:53] <alexeymelnikov> Dave: yes, my thoughts exactly
[15:19:07] <Dave Cridland> Or am I being naïve, and it's not that simple?
[15:19:46] <alexeymelnikov> Military messaging might need minutes-level resolution.
[15:21:59] --- cromwellian has left
[15:22:05] <Dave Cridland> Why not?
[15:22:29] <Dave Cridland> Is there a compelling reason to have only day? Or should we go for hour? Or minute?
[15:22:33] <alexeymelnikov> Mail is not instant messaging, it doesn't need second-level precision.
[15:22:52] <mrcrispin@jabber.org> I (emphatically) agree with Alexey's comment.
[15:23:01] <alexeymelnikov> Even though mail is quite quick these days
[15:23:02] <mrcrispin@jabber.org> IMAP faced this same decision point 20 years ago.
[15:23:35] <mrcrispin@jabber.org> Hours may be OK.
[15:23:53] <Dave Cridland> Mark: I agree that *per-second* is not a demand, I'm just not clear what it should be, and I'm unclear what the difference is between complexity of hours or seconds.
[15:24:39] <mrcrispin@jabber.org> I don't think that it's complexity so much as it is server burden and the "fuzz" needed to do it right from the user's viewpoint
[15:25:21] <eburger> Consensus: go with Hours (not Seconds or Days)
[15:25:26] <Dave Cridland> Mark: Yes, but what's the distinction between 3600 seconds and an hour?
[15:25:42] <alexeymelnikov> After fixing ABNF and resolving seconds versa hours/days, the document should be ready for WGLC
[15:25:57] <randy> Just how often the server needs to recompute the view
[15:27:18] <Dave Cridland> Randy: But if you need to have the last hour, you want the last 3600 seconds. Same thing. Just that if you want the last half-hour, you can't do it. Why add a restriction that's not needed?
[15:28:57] <Dave Cridland> For computations on vfolders, I'm happy if the server is slack about updating them, as long as they MUST happen on SELECT, and at some other point (like, say, CHECK)
[15:29:17] <alexeymelnikov> Dave: NOOP
[15:29:32] <alexeymelnikov> Dave: I don't think anybody is using CHECK
[15:29:36] <Dave Cridland> Alexey: Not NOOP - some clients don't issue NOOP much. Mine hardly does at all.
[15:30:11] <alexeymelnikov> Can be FETCH/STORE as well.
[15:30:23] <mrcrispin@jabber.org> Doing it on NOOP means "do it on every command".
[15:30:39] <Dave Cridland> Mark: Yes, I'd agree - don't want to make NOOP anything more than NOOP.
[15:30:48] <alexeymelnikov> Mark: I am personally find with this. That what we do.
[15:30:59] <eburger> Slide 16: "Do we need to add Informative section on recomputing view?" Answer: Yes.
[15:31:28] <alexeymelnikov> I personally like "Implementation Considerations"
[15:33:20] <Dave Cridland> Wait... We're dealing with a potential DoS based on anonymous access readonly VFOLDERs, though. This is worse than appending huge messages.
[15:33:50] <randy> Can anonymous clients create vfolders?
[15:33:55] <randy> Do we need that?
[15:34:09] <Dave Cridland> Randy: No, but AFAIK, they can read them.
[15:34:44] <alexeymelnikov> Randy: Creating vfolders is an access control issue
[15:35:03] * eburger has changed the subject to: VFOLDER
[15:35:08] --- resnick has left: Replaced by new connection
[15:35:19] <randy> ...and because vfolders are listed like regular folders an anonymous client can see them
[15:35:22] --- cromwellian has joined
[15:35:23] <cromwellian> hello
[15:36:26] --- kmurchison has left
[15:37:34] <Glenn Parsons> Pete is in the basement - tornado siren :-)
[15:37:45] <Glenn Parsons> VFOLDER is the next topic
[15:37:50] <eburger> Slide 4
[15:40:23] <alexeymelnikov> Ray: the same issue is true if the server allows to delete a selected mailbox
[15:40:55] <alexeymelnikov> (Ray was talking about client deleting backing mailbox)
[15:41:39] <alexeymelnikov> I want to have predictable behavior for clients
[15:41:48] <Dave Cridland> [I'm off audio, now. Cooking dinner, checking occasionally.]
[15:41:49] <alexeymelnikov> Otherwise they can't rely on a feature
[15:44:27] <alexeymelnikov> Ray: I think support for dynamic attributes in VFOLDER should be a separate capability
[15:48:04] --- kmurchison has joined
[15:49:01] <alexeymelnikov> Ray is saying that Arnts wants to use VIEW+IDLE for inband notifications.
[15:50:55] <randy> I'd like to find a way to allow view+idle to be used for notifications in a way where we can require it and hence not make clients cope with servers that don't support it
[15:50:58] <alexeymelnikov> People who remember Cyrus' VIEW: it allowed to semi-dynamic views, when a message can never drop out of the view, unless the view is destroyed. That might be sufficient.
[15:51:55] <alexeymelnikov> Randy wants notifications from multiple mailboxes
[15:52:02] --- greg.vaudreuil has left
[15:52:16] <alexeymelnikov> (Sounds like a combination of CLEARIDLE and Barry's multimailbox SEARCH draft)
[15:52:30] --- greg.vaudreuil has joined
[15:53:02] <randy> Alexey--yes, I thought this sounded familiar
[15:53:53] <Anil Srivastava> if there are multiple backend folders, then which folder does the message get appended to
[15:54:29] <randy> I'd like to try and separate the two use cases: vfolder for notifications and vfolder as a subset of a folder
[15:54:35] <Glenn Parsons> now on lside 9
[15:54:44] <alexeymelnikov> Anil: yes, good point. We can designate "the main" mailbox.
[15:54:50] <randy> if we can separate them, we may be able to reduce the complexity of the extension and mandate support
[15:58:03] <Dave Cridland> For multiple mailbox notifications, an unsolicited STATUS response and a fast SELECT work much more in the spirit of IMAP, I think. Not that I'm the authority on that. That's not to say that a multiple-backend VFOLDER wouldn't be great.
[15:58:23] <eburger> back to slide 6
[15:59:24] <alexeymelnikov> Dave: multiple-backend VFOLDER can enable STATUS notifications for the included mailboxes
[15:59:36] <alexeymelnikov> I actually like that.
[16:01:31] <alexeymelnikov> If I remember correctly there was a rough consensus in Dallas not to show vfolders unless explicitly requested with LIST (VFOLDER)
[16:03:51] <alexeymelnikov> But there is an advantage to let legacy clients to see VFOLDERs.
[16:04:43] <alexeymelnikov> Cyrus Daboo mentioned that a legacy client can download the same message multiple times (in real mailbox and vfolders created from it)
[16:06:50] <alexeymelnikov> I agree to make visibility of vfolders in regular LIST to be a deployment choice.
[16:07:21] <cyrus_daboo> I can live with that too...
[16:10:39] <Anil Srivastava> I can live with that. I am assuming this also applies to any vfolder that is attached to multiple backend mailboxes and one or more of those backend mailboxes are renamed
[16:10:46] <alexeymelnikov> Ray wants to poll WG: is everybody Ok with saying that RENAME of the backing mailbox deletes all VFOLDERs that depend on this
[16:10:47] <eburger> VFOLDER behavior for when I RENAME an underlying? Should it delete the VFOLDER?
[16:11:09] <alexeymelnikov> I can live with this as well
[16:12:10] <alexeymelnikov> Anil: I am Ok with your proposal regarding multiple mailboxes.
[16:13:12] <eburger> Typing all the words :) Deleting or renaming an underlying folder kills a VFOLDER
[16:16:46] <eburger> Eric: Customer Service nightmare if folders dissapear magically; worse if someone else does the delete; yet worse if user doesn't even know they are looking at a VFOLDER, not a regular folder
[16:17:35] <eburger> Glenn: why can't we just update the VFOLDER search criteria when doing a RENAME?
[16:18:29] <eburger> Some consensus to NOT have VFOLDER dissapear when renaming underlying folder
[16:18:36] <eburger> Slide 8
[16:19:20] <alexeymelnikov> After extensive discussion people think to prefer that RENAME of the backing folder will update VFOLDERs to point to the new backing folder.
[16:19:32] <eburger> Discussing about server telling client that folder is a VFOLDER
[16:20:24] <eburger> Should we allow server to hide fact (to legacy clients)? Should we also report folders underly the VFOLDER?
[16:21:03] <eburger> From Arnt: can we do an outer join of elements that are NOT in any VFOLDER?
[16:22:08] <eburger> Soliciting text
[16:22:15] <mrcrispin@jabber.org> now that this weighty discussion is over, a lighter topic: please s/VFOLDER/VMAILBOX and s/folder/mailbox otherwise. "folder" is not an IMAP term.
[16:22:18] <eburger> Slide 10
[16:22:41] <eburger> slide 11
[16:23:25] <alexeymelnikov> Sorry Mark. I use both terms as synonyms.
[16:25:33] <mrcrispin@jabber.org> That's OK Alexey, I just care about getting the documents fixed before RFC publication.
[16:26:16] <cromwellian> vmailbox rolls off the tongue a little better than vfolder
[16:26:23] <alexeymelnikov> Mark: Is there any particular reason why "folder" is bad?
[16:27:57] * eburger has changed the subject to: Night Time :)
[16:28:04] <Glenn Parsons> Glenn suggests we start at 8am ET tomorrow
[16:28:06] <cromwellian> night
[16:28:10] <mrcrispin@jabber.org> "folder" is an ambiguous term. It implies inferiors, and can be confused with \NoSelect names. Since IMAP has chosen "mailbox", we should stay with it.
[16:28:14] --- Anil Srivastava has left
[16:28:35] <alexeymelnikov> Mark: I see.
[16:28:37] --- cromwellian has left
[16:29:02] --- smaes has left
[16:30:17] --- cyrus_daboo has left
[16:31:54] --- eburger has left
[16:33:31] <Glenn Parsons> so we will start at 8:30am ET tomorrow
[16:36:41] --- kmurchison has left
[16:39:02] --- eburger has joined
[16:50:07] --- Glenn Parsons has left
[16:52:24] --- randy has left: Logged out
[17:57:36] --- LEMONADE has left: Logged out
[18:02:23] --- resnick has joined
[18:02:58] <Dave Cridland> Pete: Nice tornado?
[18:03:28] <resnick> Passed south. Haven't heard damage reports yet.
[18:03:36] <resnick> I also had an errand to run. :))
[18:12:41] --- eburger has left
[18:44:46] --- eburger has joined
[19:32:54] --- Dave Cridland has left
[19:35:40] --- eburger has left
[20:43:13] --- alexeymelnikov has left: Replaced by new connection
[20:55:13] --- anil has left
[20:58:03] --- anil has joined
[22:17:02] --- anil has left
[22:46:45] --- eburger has joined
[23:34:17] --- eburger has left