[10:14:00] --- LOGGING STARTED
[11:51:46] --- pguenther has joined
[12:59:30] --- LOGGING STARTED
[13:03:30] --- LOGGING STARTED
[14:24:35] --- Dave Cridland has joined
[14:28:06] --- avel has joined
[14:34:52] <Dave Cridland> You're Alexandros Vellis, or another avel?
[14:35:02] <avel> Yes that is me. :-)
[14:35:20] <Dave Cridland> Ah... It's you guys that do weird stuff with Cyrus and auto-provisioning, etc?
[14:35:27] <avel> Heh. 8-)
[14:35:33] <Dave Cridland> Seem to recall something about Squirrelmail?
[14:35:34] <avel> Not _that_ weird.
[14:35:41] <avel> Yes, of course, I recognise you
[14:35:45] <Dave Cridland> Okay. s/weird/novel/
[14:36:17] <avel> I was checking the schedule and trying to find out when the meetings I'm interetested in start
[14:36:37] <Dave Cridland> Lemonade start in an hour and a half.
[14:36:39] <avel> Is lemonade about to start?
[14:36:44] <avel> Ah ok thanks. :-)
[14:36:59] <avel> (It's 21:30 here in Greece :/ )
[14:37:28] <Dave Cridland> Google for "world clock", and you'll find the top link has a meeting organiser thing that'll spit out a 24 hour time sheet between Dallas and Greece.
[14:38:01] --- greg.vaudreuil has joined
[14:40:36] <avel> Dave Cridland: I checked my mail archive and found out you were asking me about ACL support in squirrelmail
[14:40:52] <avel> By the way, it is in my checklist to support rfc2086bis, but....
[14:41:00] <avel> I haven't got round to it yet.
[14:41:05] <Dave Cridland> Ah, yes, quite possible. The LISTRIGHTS issue that came up with RIGHTS= stuff.
[14:41:39] <Dave Cridland> Yeah, Cyrus 2.3.4 will support it. 2.3.3 might even do so, I'm not sure.
[14:42:18] <Dave Cridland> 2.3.4 will also do (or does already, I never remember to check if it's released) IMAP BINARY will full APPEND support.
[14:46:31] <avel> (Good topic?)
[14:51:30] --- Glenn Parsons has joined
[14:51:41] <Dave Cridland> Hello Glenn.
[14:51:55] <Glenn Parsons> OK we don't start for another hour folks....
[14:52:13] <Dave Cridland> Hour and a half, hopefully. ;-)
[14:53:12] <Dave Cridland> avel: You sure it's 21:20 CET? It's 21:20 UCT, and I didn't think those were in sync.
[14:54:37] <Dave Cridland> Sounds seems very good in Miro. Although the NTP WG seems to be embroiled in nasty copyright issues.
[14:54:49] <avel> Dave: I'm _not_ sure. :-)
[14:58:02] <Glenn Parsons> We start at 1520 UTC -6
[15:26:55] <avel> Is anyone testing the audio feed? It has some weird echo.
[15:27:08] <avel> http://tinder.uoregon.edu:8000/ietf657.mp3
[15:27:19] <Dave Cridland> Yeah, I just noticed that. Finally got a different streaming client to work, and noted it happened on that too.
[15:51:24] --- greg.vaudreuil has left
[16:02:03] --- pguenther has joined
[16:02:32] <Dave Cridland> Hello.
[16:06:09] <pguenther> hello
[16:06:47] <Dave Cridland> Socks wet?
[16:07:08] <pguenther> darn, xmms will play the archived mp3 and even stream them, but won't play the RTP live streams
[16:07:16] <avel> Hello there!
[16:07:31] <Dave Cridland> There's RTP streams?
[16:07:37] <pguenther> I'm at home in Colorado, not at the meeting
[16:07:54] <avel> Philip - save the .m3u file in the filesystem,
[16:08:00] <pguenther> 'course, we have 6 inches of snow and its still falling...
[16:08:04] <avel> and open it in xmms with open file. It's an http stream.
[16:08:19] <Dave Cridland> I thought it was using hypertext transfer and audio streaming protocol.
[16:08:26] <pguenther> huh, that didn't work earlier
[16:08:45] * pguenther curses this d**n technology thing
[16:08:54] <pguenther> it'll never work out, I tell you
[16:09:03] <Dave Cridland> :-)
[16:09:21] <avel> Prepare to listen to strange echos etc. at times :-)
[16:10:18] <pguenther> "It doesn't help that there's a kazoo player convention upstairs..."
[16:10:39] <avel> :-)
[16:10:46] <Dave Cridland> I gave my kids a kazoo for christmas.
[16:11:37] <Dave Cridland> Actually, I gave my wife one too. And bought myself one. I had this vision we could become a sort of von trap family, except with kazoos instead of singing.
[16:12:43] <pguenther> you'll be fleeing from your neighbors instead of the Nazis
[16:13:19] --- Lyndon Nerenberg has joined
[16:13:37] <Dave Cridland> Well, the plan failed when I noticed that Wales has no common border with Switzerland.
[16:15:41] --- kmurchison has joined
[16:15:49] <avel> Greetings!
[16:17:04] <Dave Cridland> Phil, you got audio working yet?
[16:17:13] <pguenther> yep
[16:17:36] --- Glenn Parsons has left: Replaced by new connection
[16:17:36] --- Glenn Parsons has joined
[16:18:37] <Dave Cridland> Ah, just about to ask you to do that. :-)
[16:18:38] <avel> Dave he's talking to you. :-)
[16:19:00] <Dave Cridland> Yes.
[16:19:16] <Glenn Parsons> OK audio still works....
[16:20:36] <Dave Cridland> Just to let you guys know, audio has been a little shaky from time to time, so a good Jabber scribe would be really appreciated.
[16:20:45] <Glenn Parsons> We'll start in another minute
[16:20:57] <Glenn Parsons> We'll nominate a good scribe....
[16:22:40] --- smaes has joined
[16:22:58] <Dave Cridland> Stéphane, hi.
[16:23:04] --- avel has left: Lost connection
[16:23:17] <pguenther> dkim ended on time
[16:24:00] * pguenther tears his headphones off
[16:24:19] --- tonyhansen has joined
[16:24:37] --- smaes has left
[16:24:40] --- greg.vaudreuil has joined
[16:24:40] <greg.vaudreuil> test
[16:24:54] <Dave Cridland> Greg, sorry, the test failed.
[16:25:00] <Glenn Parsons> Testing 123
[16:25:02] --- frodek has joined
[16:25:04] <Glenn Parsons> Tony & Greg will tag team
[16:25:11] <Glenn Parsons> on jabber scribe duties today
[16:25:11] --- randy has joined
[16:25:16] <tonyhansen> slide 4 of presentation
[16:25:40] <tonyhansen> look on https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 for materials
[16:25:46] <greg.vaudreuil> Pardon the s'ss..... sticky keys was not an adequate excuse to avoid scribing
[16:25:49] --- tianlinyi has joined
[16:25:56] <tonyhansen> agenda bash (whack, whack)
[16:26:48] <pguenther> please repeat?
[16:27:01] <Dave Cridland> Explaining "Without TCP".
[16:27:03] <pguenther> ah
[16:27:22] <Dave Cridland> Basically the over-HTTP stuff.
[16:27:36] <Dave Cridland> But I can't hear what's being said now.
[16:27:36] <Lyndon Nerenberg> lots of people not speaking into the microphone!
[16:27:40] <pguenther> right, the continuation of the "HTTP treated differently than random TCP" as mentioned in London
[16:28:36] <tonyhansen> slide 6
[16:28:49] <tonyhansen> moved ...-xencrypted to after ...-futuredelivery
[16:29:14] <tonyhansen> ted poofed notify-s2s
[16:29:21] <tonyhansen> slide 6
[16:29:23] <tonyhansen> slide 7
[16:29:30] --- lisaDusseault@jabber.psg.com has joined
[16:29:47] <tonyhansen> profile-bis and assoc docs moved up in Q
[16:29:58] <tonyhansen> to immed after ietf-65
[16:30:26] --- gshapiro has joined
[16:30:44] --- smaes has joined
[16:30:58] --- nsb has joined
[16:31:19] <tonyhansen> chris: message event draft: only 1 implementation so far, but need input from other vendors
[16:31:43] <tonyhansen> stefane: happy
[16:32:01] <tonyhansen> alexey: notif types list good
[16:32:23] <tonyhansen> chris: do we need support for flags other than \seen?
[16:32:52] <Dave Cridland> I can't help think that if we don't have support for other flags, it'll come back to haunt us.
[16:32:54] <tonyhansen> greg: idle parity? use s2s as adjunct to idle
[16:34:04] <pguenther> draft -00 had \delete flag too, no?
[16:34:24] <pguenther> "TrashMessages" are \deleted, no?
[16:35:16] <tonyhansen> chris: yes, we had either \deleted or\expunged or something like that
[16:35:30] <tonyhansen> stefane: should review list of events
[16:35:49] <pguenther> I see events for both setting of \deleted and for expunging
[16:36:29] <tonyhansen> eric: streaming content "where's the beef, oops draft" no excuses
[16:36:48] <pguenther> (I've only heard requests for \seen and \deleted notifications, for flags, at least. I'll put comments in email to Chris...)
[16:36:55] <tonyhansen> slide 8: now 12 drafts, message event coming out
[16:37:08] <tonyhansen> and into wg draft
[16:37:23] <tonyhansen> slide 10: oma mem liaison
[16:38:01] --- bernard.desruisseaux has joined
[16:38:06] <Dave Cridland> Phil: There's a tendency I've noticed amongst people whose email clients can cope, to use flags and keywords a lot more, and folders a lot less, for managing email, so I kind of think it might prove useful if this trend continues.
[16:38:30] --- NFreed@jabber.org has joined
[16:38:39] <Dave Cridland> I've lost audio, BTW.
[16:38:45] --- NFreed@jabber.org has left: Logged out
[16:38:59] <Lyndon Nerenberg> Audio is fine here, Dave ...
[16:39:21] <tonyhansen> glen is describing liaison; hoping for shorter list of parameters for convert, or choose to go with all
[16:39:41] <pguenther> sure, better clients use more flags, but do they care about getting notifications of changes in them?
[16:40:22] <pguenther> everyone wants to see that there are unseen messages in random folders, but do they really care whether a message for which an MDN hasn't been sent ($MDNSent flag) have appeared?
[16:40:28] <Dave Cridland> Lyndon: thought it was just me. I've got it back no.
[16:40:54] --- amarine has joined
[16:41:32] <Dave Cridland> Phil: No, but finding an example for an uninteresting flag is not proof that therefore you've found all cases.
[16:41:50] <kmurchison> in a shared mailbox scenario (e.g. a helpdesk mailbox), users might want to know if a message has been replied to
[16:42:03] <tonyhansen> alexey: is implementing full list phase 2?
[16:43:14] <pguenther> dave: I agree, I was just observing that vast difference in interest levels between flags
[16:43:31] <tonyhansen> Note: if you have something you want me to channel, please say "please channel" at the beginning of the line
[16:43:42] <Dave Cridland> Phil: Oh, Ive no doubt that \Seen is the most important.
[16:43:54] <Dave Cridland> Tony: Yeah, will do.
[16:43:55] --- jr111 has joined
[16:44:09] <tonyhansen> thanks
[16:44:12] <tonyhansen> chris: suggests design team to decide on actual list.
[16:44:23] <tonyhansen> randy: start small and let people say: we need this
[16:44:41] <tonyhansen> glen: where small == 0
[16:45:14] --- robsiemb has joined
[16:45:55] <tonyhansen> eric stands, sort of, and says: once we start small, we're going to need more.
[16:45:59] <Dave Cridland> Tony, Channel: No, you need a small list of mandatory things, so there's enough to rely on.
[16:46:56] <tonyhansen> randy: object to default mandatory,
[16:47:05] <tonyhansen> stefane: what is action item?
[16:47:25] <tonyhansen> glen: action design team to work on it: chris, stefane, alexey
[16:47:41] <tonyhansen> on to round trip delay
[16:48:05] --- men123 has joined
[16:48:22] <tonyhansen> primary concern: want to minimize notification and send/receive roundtrip delay
[16:48:38] --- cyrus_daboo has joined
[16:48:54] --- Barry Leiba has joined
[16:49:13] --- jimsch1 has joined
[16:49:31] <tonyhansen> agree that this is fine.
[16:49:34] <tonyhansen> message recall is still a req't.
[16:49:56] <pguenther> haha
[16:51:56] --- cyrus_daboo has left: Replaced by new connection
[16:52:00] <tonyhansen> glen: oma said we could satisfy this using dsn's always indicating no. should message tracking be used instead. maybe oma will decide req't is not really needed.
[16:52:23] <tonyhansen> ted: let's hold off on doing anything until we get more info from oma.
[16:52:38] <tonyhansen> stefane: oma said they will discuss and get back to us.
[16:52:50] --- greg.vaudreuil has left
[16:53:02] --- robsiemb has left: Logged out
[16:53:28] --- robsiemb has joined
[16:53:32] --- bernard.desruisseaux has left
[16:53:47] <tonyhansen> stefane: wasa there a request for us to do a profile-bis overview at next oma mtg
[16:53:50] --- bernard.desruisseaux has joined
[16:54:31] <tonyhansen> chris: wants to do message recall anyway. message tracking hasn't deployed. maybe this could push it.
[16:54:39] --- corby has joined
[16:54:57] <Dave Cridland> Someone ask Chris to make it depend on ACAP, too, then. :-)
[16:55:12] <tonyhansen> glen: so we could say, let's do it anyway, but not if it's individual work
[16:55:53] <tonyhansen> stefan: for oma sti, we will come up with short list
[16:55:58] --- hardie@jabber.psg.com has joined
[16:56:01] <tonyhansen> glen: next oma mtg is apr 3
[16:56:10] --- cyrus_daboo has joined
[16:56:33] <tonyhansen> glen: talk offline about other things to present to oma
[16:56:56] <tonyhansen> slide 12: document issues with notifications/msgevent
[16:57:12] <tonyhansen> stefan's slide 6, 7
[16:59:45] <tianlinyi> where can i find the slides?
[16:59:57] <Dave Cridland> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
[17:00:19] <pguenther> enough information for the user to decide whether they want to actually request the full message?
[17:00:54] <pguenther> UIDs may be considered to be confidential information
[17:00:58] <cyrus_daboo> So isn't LPROVISION just re-inventing ACAP?
[17:01:21] <tonyhansen> (is that a comment to channel?)
[17:01:35] <tonyhansen> greg and stefan are talking about encryption
[17:01:39] <pguenther> e.g., IMAP UIDPLUS extentension notes that APPENDUID/COPYUID response codes should not be returned if you can't select the mailbox
[17:01:51] <pguenther> tony: hmm, sure
[17:01:52] <Dave Cridland> Cyrus: Yes, blatantly it's reinventing ACAP.
[17:02:45] <cyrus_daboo> No don't channel. Its just that there has been criticism in imapext that some extension are trying to 'reinvent' ACAP in IMAP, and yet that seems exactly what LPROVISION/LSETPREF/LGETPREF is doing.
[17:03:17] --- klensin has joined
[17:03:36] <tonyhansen> stefan: if more than wake up call, then uid would be passed, so even for just uid, would have to encrypt
[17:03:37] <pguenther> -/me nods
[17:03:50] <Dave Cridland> Cyrus: Except ACAP is impractical on mobiles. Or so I'm told, and the mere fact I use ACAP over GPRS quite a bit has nothign to do with it.
[17:03:55] <pguenther> paul? you mean Philip?
[17:04:02] <pguenther> apology accepted
[17:04:08] <pguenther> :)
[17:04:12] --- resnick has joined
[17:04:16] <tonyhansen> randY: what is problem with having uids in clear?
[17:04:53] <pguenther> randy: we've considered them confidential in IMAP in the past
[17:05:02] <pguenther> you can't just find the NEXTUID for a random mailbox
[17:05:19] <randy> Dave -- ACAP impractical on mobiles? That's silly! ACAP is much easier on mobiles than LDAP or almost anything else.
[17:05:30] <pguenther> now, that may be because they're useless then instead of confidentiality
[17:05:37] <pguenther> but they why the callout in UIDPLUS?
[17:05:54] <Dave Cridland> randy: That's what people tell me. And what would I know? As I say, just because it's always worked fine for me means nothing. :-)
[17:06:14] <tonyhansen> stefan: we have emn. extend that?
[17:06:41] --- greg.vaudreuil has joined
[17:06:43] <pguenther> where is EMN described/referenced?
[17:07:22] <tonyhansen> cyrus: any reason why annotate is not being used and annotatemore? stefan: annotatemore
[17:08:01] <tonyhansen> lisa: emn doc asked for emn doc also. stefan will check reference
[17:08:20] <tonyhansen> stefan: should be acc from oma
[17:08:22] <pguenther> cool, thanks
[17:08:39] <tonyhansen> stefan: on to convert
[17:09:04] --- gshapiro has left
[17:09:42] <tonyhansen> many issue: standardize baseline conversions
[17:09:49] <tonyhansen> (main issue)
[17:10:15] <tonyhansen> barry: filter. slide 14 of chairs' slides
[17:11:28] <tonyhansen> folded in comments, needs people to look at updated draft
[17:11:34] <Dave Cridland> I'll take a look at it.
[17:12:46] <tonyhansen> alexey: managesieve
[17:12:57] <resnick> Who is dwd@jabber.org?
[17:13:11] <tonyhansen> did another revision, looked at in sieve wg
[17:13:43] <Dave Cridland> Pete: That would be me.
[17:13:52] <resnick> :) Who are you?
[17:13:56] <Dave Cridland> As in Dave Cridland, if the alias isn't coming up...
[17:14:17] <resnick> It isn't for me. Jabber is behaving oddly.
[17:14:35] <pguenther> you know, the _other_ wacky Brit
[17:14:51] <pguenther> ;)
[17:15:04] <tonyhansen> stefan: decision in beijing was to use managesieve only, or position as one way, client issues
[17:15:14] <Dave Cridland> Phil: WHo's the original? Cyrus?
[17:15:53] <tonyhansen> barry: but if imapsieve points at managesieve, then issues, ...
[17:16:03] <tonyhansen> cyrus:managesieve is one way of several
[17:16:27] <tonyhansen> barry and cyrus: back and forth about managesieve
[17:16:30] <pguenther> I was thinking Alexey, given how Cyrus has lived in the United States for a while now
[17:16:47] <pguenther> between the two of them there's at least one wacky brit, no?
[17:17:02] <Dave Cridland> Phil: Alexey currently doesn't count. Cyrus still sounds like a Brit to me.
[17:17:25] <tonyhansen> eric: actual mech is oma req't. is this the only way, or one of several.
[17:18:44] <tonyhansen> stefan: need to manage filter is req't. profile issue. managesieve, xdn, can it still be done other ways? issue is how much must go into profile.
[17:19:30] <pguenther> must clients support managesieve to have an interoperable subset?
[17:20:31] <pguenther> good point, Ned
[17:20:33] <tonyhansen> ned: process issue: have to be very careful of how process is carried out, particularly with respect to making decisions and ratifying/ not-ratifying them on the list
[17:20:47] <robsiemb> why is managesieve requried to attach the scripts to folders? why not an annotation?
[17:20:55] --- robsiemb has left: Logged out
[17:21:18] --- robsiemb has joined
[17:21:19] <tonyhansen> barry will wordsmith around managesieve issue in imapsieve
[17:22:15] <tonyhansen> rob seborski: asks clarification of how managesieve is being used. can it be done with annotations? (ans: yes, could be done)
[17:22:16] <Lyndon Nerenberg> Are we looking at a particular slide?
[17:22:31] <tonyhansen> still chair's slide 14
[17:22:56] <pguenther> but what are clients going to be required to implement to interoperate?
[17:22:57] --- smaes has left
[17:23:07] <pguenther> that's the profile question, no?
[17:23:13] --- smaes has joined
[17:23:19] <tonyhansen> barry: reiterated: split description into two parts: describe what needs to be done, then how managesieve can be used
[17:23:22] <Dave Cridland> Phil: Yeah. THe Profile has to list how this stuff works.
[17:23:27] --- corby has left
[17:23:53] <robsiemb> siemborski
[17:23:53] <tonyhansen> ned: is annotatemore a bad name? we need it more. come to imapext
[17:23:55] --- corby has joined
[17:24:08] <tonyhansen> stefan's slide 18
[17:24:14] <pguenther> if the OMA doesn't want to implement MANAGESIEVE in clients, someone better say what the minimum protocol for uploading scripts is
[17:24:40] <pguenther> "Less is more?" "No, annotateless was annotatemore"
[17:24:48] --- resnick has left: Replaced by new connection
[17:24:53] <Dave Cridland> (As as an aside: We really need what ANNOTATE has to offer, it's just a real shame that nobody on the server side seems willing to implement it.)
[17:25:16] --- bernard.desruisseaux has left
[17:25:18] <tonyhansen> (see slides)
[17:25:19] <Dave Cridland> Phil: And if we don't, they will, and it'll either be DM (SyncML stuff) or XCAP.
[17:26:04] <randy> ANNOTATE has been simplified -- now even easier to implement!
[17:26:17] <tonyhansen> (phil: I think barry will cover what you asked for re uploading scripts)
[17:26:26] <tianlinyi> DM?
[17:26:47] <randy> Maybe DS, not DM
[17:26:58] <pguenther> there was some comment about preserving UIDVALIDITY in VIEW that didn't make sense to me
[17:27:00] <tonyhansen> cyrus: anyone worried of vfolder conflict on reguar clients?
[17:27:06] <Dave Cridland> randy: QUite probably. Data Sync not Device Management.
[17:27:55] <Dave Cridland> Phil: I *think* you're mistaking VIEW for VFOLDER, there.
[17:28:02] --- resnick has joined
[17:28:03] <tonyhansen> alexey: there is possible way to ??? (missed it)
[17:28:30] <pguenther> hmm, probably, checking the draft again now
[17:28:50] <tonyhansen> cyrus: won't vfolder be transparent to desktop clients? (yes) discusses options for servers.
[17:29:19] <Lyndon Nerenberg> Vfolder needs to be separate: not only because of Cyrus's caching issues, but also because of synchronization
[17:29:22] <pguenther> yeah, VFOLDER requires the virtual folder to have the same UIDVALIDITY as the underlying folder, but that breaks the IMAP guarantees for UIDVALIDITY
[17:29:39] <tonyhansen> cyrus: vfolders can be used as regular folders by current clients (design req't?)
[17:29:43] <Lyndon Nerenberg> Too many stupid clients don't do smart sync, so vfolders will make a bad situation worse.
[17:29:54] <Lyndon Nerenberg> (if they appear as regular folders)
[17:30:12] <tonyhansen> (remember: if you want me to channel a comment, please mark it as such)
[17:30:18] <Dave Cridland> There's the flip side, though - if virtual folders behave like normal folders, then existing clients can take advantage of them, the user just sets them up with a smart "tool".
[17:30:24] <Lyndon Nerenberg> yes please, tony
[17:30:31] --- bernard.desruisseaux has joined
[17:30:39] <tonyhansen> greg: (missed it)
[17:30:44] <Dave Cridland> Tony: Yes, please, if it's relevant. (Since my audio keeps cutting)
[17:30:50] <tonyhansen> eric: desktops have lots of storage, sod oes it matter?
[17:31:59] <tonyhansen> barry, cryus, eric agree, desktop has lots of ways
[17:32:07] <tonyhansen> take this to the list
[17:32:07] <pguenther> channel: to Cyrus: does that mean desktops and mobiles won't interoperate for this?
[17:32:10] <pguenther> or do we not care?
[17:32:19] <pguenther> (do the users not care that they're different?)
[17:32:34] <Dave Cridland> Online clients, incidentally, will likely suffer if vfolders based on UNSEEN aren't a little clever, since otherwise the implicit \Seen setting makes the message vanish when the first part is read...
[17:32:37] <cyrus_daboo> They interoperate - its just that desktop clients will end up with multiple cached copies of the same message wasting disk space.
[17:33:08] --- NFreed@jabber.org has joined
[17:33:15] <tonyhansen> cyrus: not interop ?, but resource ?
[17:33:20] * pguenther mumbles to himself
[17:33:48] <tonyhansen> randy: are there clients that cache everything?
[17:33:51] <tonyhansen> multiple times?
[17:34:24] <tonyhansen> greg: another use is to have same msg in multiple folders? so same problem, but with constrained storage
[17:34:45] <pguenther> dang, my audio dropped
[17:35:08] <Dave Cridland> Phil: Ah, mine's just gone weird and echoy.
[17:35:19] <pguenther> it was starting to sound like we're heading towards a global message ID namespace
[17:35:19] <randy> Scenario: mobile device creates vfolder; user gets back to office, desktop client notices new folder and shows it to user; user clicks on it; client opens it and fetches every message; now has two copies of each message
[17:35:25] <tonyhansen> cyrus: if view of seen msgs, then change view, then download again. origianl VIEW extension did it differently, maintaining uid semantics
[17:35:28] <pguenther> so that you could cache a message between folders
[17:36:08] --- NFreed@jabber.org has left: Replaced by new connection
[17:36:48] <tonyhansen> stefan: (see slide)
[17:37:58] <tonyhansen> (eric tries to edit slides, to change text to "SEARCH SEARCH BEFORE -7")
[17:38:18] <tonyhansen> alexey: would prefer old way for consistency
[17:38:23] <Dave Cridland> Nothing negative in IMAP. :-)
[17:38:23] <pguenther> argh. changing slides on the fly makes them impossible to follow...
[17:38:39] <tonyhansen> lisa: can we ask for messages sent tomorrow?
[17:38:53] <Dave Cridland> Lisa: They won't have arrived yet.
[17:39:16] <pguenther> what's the slide title?
[17:39:20] <lisaDusseault@jabber.psg.com> Actually, my question was, would a search for "emails sent since seven days ago" include emails sent tomorrow?
[17:39:21] <Dave Cridland> No, that was not the issue Arnt raised AT ALL!
[17:39:26] <robsiemb> draft-ietf-lemonade-search-within-00
[17:39:30] <pguenther> the posted slide 15 is "reconnect status"
[17:39:37] <resnick> Who is this "we" to whom Stephane refers?
[17:40:01] <pguenther> ah, those are stephane's slides
[17:40:07] <pguenther> not the chairs
[17:40:22] <Dave Cridland> Tony, channel: Arnt was explaining that VFOLDER could largely be implemented by checking for HIGHESTMODSEQ changes on each command. The UNSEEN was purely an example.
[17:40:26] <lisaDusseault@jabber.psg.com> if there's one thing I've learned from working on calendaring, it's that time is more mutable than one might think.
[17:41:00] <Dave Cridland> Tony Channel: So WITHIN causes this method to fail, you need to continuously check to see if the search results have updated.
[17:42:05] <Dave Cridland> Tony Channel: In other words, the "Answer" on this slide is not the answer to Arnt's comment.
[17:43:04] <tonyhansen> (which slide?)
[17:43:26] <Dave Cridland> Tony: No, slide 15.
[17:43:37] <Dave Cridland> Tony: Lag, sorry.
[17:44:04] <tonyhansen> stefan: if answer to unseen wasn't good enough, then slide 16 addresses it?
[17:44:30] <Dave Cridland> Channel : Yes, but without WITHIN, UNSEEN is entirely practical. Arnt has implemented VIEW, after all.
[17:45:02] <tonyhansen> agreement
[17:45:23] <pguenther> so it's the relative time aspect of WITHIN that's the problem?
[17:45:56] <Dave Cridland> Phil: Yeah, since you have two checks to do. Has HIGHESTMODSEQ changed, and What's The Time Mister Wolf?
[17:45:56] <tonyhansen> greg: wants to capture conclusions
[17:46:36] <tonyhansen> stefan/greg: unclear and need to see if we agree once it's been spelled out
[17:46:44] <pguenther> it isn't a problem with just a WITHIN search?
[17:46:58] <tonyhansen> compression
[17:47:06] <robsiemb> (chair slide 15)
[17:47:08] <pguenther> ...or I just misunderstood your response
[17:47:44] <pguenther> it's slide 14 in the posted version
[17:47:47] <Dave Cridland> Phil: No, it's purely a WITHIN issue that forces you to do two checks.
[17:48:01] <pguenther> okay, good, I'm not going insane
[17:48:12] <pguenther> well, at least not for this
[17:48:50] <Dave Cridland> Phil: Going?
[17:49:04] <tonyhansen> (see slide)
[17:49:18] <tonyhansen> greg: what does "transport=MAY" mean
[17:49:38] <tonyhansen> ned: client MUST support compress, but may decide to not use
[17:49:58] <Lyndon Nerenberg> request to chair: if we're going to discuss binary can we defer until wednesday? i have to leave in 5 minutes.
[17:50:22] <pguenther> mike!
[17:50:36] <tonyhansen> (someone "mooed")
[17:50:36] <robsiemb> (laptop moos)
[17:50:52] <randy> (that was a "Moof!", not a "Moo")
[17:51:02] <randy> (from Claris the Dogcow)
[17:51:17] <tonyhansen> stefan: discussing variations in how to do compression
[17:51:22] <Lyndon Nerenberg> (tony, are the chairs reading jabber? if not, can you relay my request?)
[17:51:37] <Glenn Parsons> Lydon, you mean binary append? At the curretn pace, we'll probably not get to it today anyway...
[17:51:44] <tonyhansen> (I relayed your request)
[17:51:58] <Lyndon Nerenberg> glenn: didn't think so :-) I'll be on wednesday morning
[17:52:15] <Glenn Parsons> Thanks Lyndon
[17:53:29] <Dave Cridland> Channel: We certainly need something other than TLS, but decompression is very cheap indeed. Moreover, compression on send saves battery, and compression either direction saves on the phone bill.
[17:53:47] <pguenther> I thought compression was a _win_ for battery, as the radio power-cost is >> than the CPU power-cost
[17:54:01] <Dave Cridland> Phil: That's my understanding too.
[17:54:03] * pguenther points at what Dave said
[17:54:37] <tonyhansen> ned: question is not whether client chooses compression: client has control
[17:55:19] <tonyhansen> ned: server's have better knowlegdge of what objects can be worth compressed
[17:55:26] <tonyhansen> ned: do we want command to turn off/on
[17:55:46] <tonyhansen> (dave: long line at mike. will channel eventually.)
[17:56:12] <Dave Cridland> I like this channelling. Makes me feel like a spook at a séance. :-)
[17:56:32] <tonyhansen> ned: little overhead if server chooses to not compress a block. blocks can be up to 64k in size.
[17:56:58] <tonyhansen> cyrus: le'ts look how http has done compression. and question of tls vs. app compression
[17:57:17] <tonyhansen> cyrus: how soon will mobiles implement compression?
[17:57:36] --- robsiemb has left: Logged out
[17:57:51] <tonyhansen> stefan: (missed it)
[17:58:00] --- robsiemb has joined
[17:58:07] <Dave Cridland> corby: Do you happen to know whether Symbian supports TLS compression yet? And if not, when?
[17:58:20] --- men123 has left
[17:58:41] <tonyhansen> ted: client may be better able to determine if it can decompress. low battery situation? tradeoff between cpu usage vs transmission usage.
[17:58:57] <lisaDusseault@jabber.psg.com> Cyrus you should send an email to the HTTP WG list for starters. I'm not aware of it being used broadly but there's a chance it's just so seamless you can't see.
[17:59:15] <pguenther> Ted's voice sounds different than I recall
[17:59:25] <pguenther> do they have torches?
[17:59:36] <randy> (Ted has an oil-burning cold)
[17:59:38] <Dave Cridland> Lisa: OpenSSL only started supporting TLS compression in 0.9.8, and that's not yet been widely deployed because of a minor API change.
[18:00:03] <tonyhansen> ted: likelihood of mobile implementing tls compression was low in recent survey
[18:01:06] <tonyhansen> eric: if in low battery situation, bigger issues take over
[18:01:07] <pguenther> here's where Dave's comment belongs
[18:01:25] <tonyhansen> (still a *long* line)
[18:01:32] <tonyhansen> (yup, I agree, can't break in)
[18:01:53] <robsiemb> and growing
[18:01:58] <tonyhansen> stefan: desision may be driven by other issues
[18:02:05] <Dave Cridland> And anyway, if you really think you can save battery, then TLS at least allows you to renegotiate the compression to off.
[18:02:48] <pguenther> the server has the effing data
[18:02:52] <randy> If you're low on battery, it would seem better to forgo the attachments
[18:02:58] <Dave Cridland> Channel what Phil says!
[18:03:01] <tonyhansen> stefan: does server really know more than the client when asking for particular attachments
[18:03:28] <tonyhansen> pete: mail client will *not* being looking at batter level, strictly on content type
[18:03:58] <Dave Cridland> Pete: Exactly!
[18:04:19] <tonyhansen> pete: server is much better able to determine compression, a priori
[18:05:43] <Dave Cridland> Cyrus/Lisa: Worth noting that the decision of whether to compress or not in HTTP rests entirely with the server, the client merely says that it can accept it.
[18:06:53] <Dave Cridland> That's actually mentioned in the compress draft. (magic compressing literal).
[18:07:02] <tonyhansen> chris: what if we define a new literal type for a compressed literal? compressed append? client can then control
[18:07:08] <pguenther> hahahahaha
[18:07:09] <tonyhansen> barry: call it "literal minus"
[18:07:17] --- nsb has left: Replaced by new connection
[18:07:19] <tonyhansen> ned: ugh
[18:07:35] --- nsb has joined
[18:07:45] <robsiemb> So then we can have a "LITERALMINUSPLUS"
[18:07:59] <cyrus_daboo> Also LITERALMINUS8
[18:08:02] <Dave Cridland> rob: Don't forget LITERAL8MINUSPLUS
[18:08:06] <robsiemb> indeed
[18:08:13] <robsiemb> BINARYLITERAL8MINUSPLUS
[18:08:21] <tonyhansen> ned: the client still has control whether compression is used! the question is: what level of control
[18:08:30] <tonyhansen> pete: can it be done if tls is used?
[18:08:37] <Dave Cridland> Literals are getting pretty close to optimal, but with a little advice from Larry Wall, I think we could perfect them. :-)
[18:08:40] <tonyhansen> ned: yes.
[18:08:58] <robsiemb> Chris also has an idea for quoted8
[18:09:20] <tonyhansen> randy: clarify client command level: client command to compress at will.
[18:09:46] <tonyhansen> stefan: do you want to turn on/off per attachment?
[18:09:51] <randy> Client tells server "compress at will"
[18:10:07] <kmurchison> rob: chris' thoughts are making my head hurt ;)
[18:10:18] <pguenther> if your client can't remember the state of it's connection, it already has problems
[18:10:20] <tonyhansen> ned: partial fetch is a command. so could do "compress on; partial fetch; compress off", and pipeline it.
[18:10:49] <tonyhansen> greg: clients may wish to store them in compressed format
[18:11:08] <randy> Ned was replying to Stephan, who wanted to know if his proposal would allow client to compress a partial fetch but not another fetch
[18:11:26] <Dave Cridland> Channel: Actually, if we mandate that parts are handed in self-contained deflate blocks, you still *can* store in memory in deflate format.
[18:11:26] <tonyhansen> greg: wants comments on taking advantage of server MIPS to do compression.
[18:11:54] <tonyhansen> ned: that's a new goal: to get an individual object in compressed form.
[18:11:55] --- cnewman@jabber.org has joined
[18:12:02] <Dave Cridland> Channel: And actually, it's more efficient comression that way.
[18:12:13] <tonyhansen> ned: wrong space: this is a job for lconvert.
[18:12:33] <Dave Cridland> Channel: Because the character of the data will be more uniform within the blocks, which results in more accurate huffman encoding.
[18:12:46] <tonyhansen> ted: go to chair's slide 11
[18:14:28] <tonyhansen> ted: if allow both , what are use cases/benefits? is tls practical?
[18:14:49] <tonyhansen> stefan: agrees with greg's suggestion.
[18:15:13] <tonyhansen> stefan: (missed it)
[18:16:14] <tonyhansen> stefan: re: lconvert, some aspects of compression are similar to conversion, and we should explore it.
[18:17:20] <tonyhansen> ned: in terms of object compression, might also want to do things like reduce image/audio parameters. however, caveat is, how do you specify what required conversions are and nailing right set for any given application
[18:18:13] <tonyhansen> randy: there is a fundamental diff btw compress/convert re losslessness
[18:19:07] <Dave Cridland> That was in response to greg, actually.
[18:19:10] <tonyhansen> randy: client doesn't care with compression, whereas conversion is significant
[18:19:35] <tonyhansen> pete: object level compression increases client complexity significantly
[18:19:36] --- Barry Leiba has left
[18:20:35] <pguenther> was there any reply to the claim that compression is always good for power?
[18:20:40] --- amarine has left
[18:20:40] <tonyhansen> pete: compression should be "I want it, don't wnat it", full stop
[18:20:53] <tonyhansen> (phil: there was agreement)
[18:21:02] <pguenther> that that's true?
[18:21:08] --- cyrus_daboo has left
[18:21:08] --- corby has left
[18:21:33] --- nsb has left
[18:21:37] --- hardie@jabber.psg.com has left
[18:22:00] <tonyhansen> eric: (summarizing)
[18:22:17] * resnick will post the issue to the list and then we can finish fighting it out
[18:22:21] --- randy has left: Logged out
[18:22:31] --- cnewman@jabber.org has left: Logged out
[18:23:13] <tonyhansen> (phil: hmmm, I recall lots of agreement when I said that out loud)
[18:23:54] --- kmurchison has left
[18:23:58] --- klensin has left
[18:24:09] <pguenther> I guess it'll be part of the discussion of Pete's post
[18:24:16] <pguenther> Tony: thank you for scribing!
[18:24:28] --- lisaDusseault@jabber.psg.com has left: Logged out
[18:24:33] --- resnick has left
[18:24:38] <Dave Cridland> Tony: Thanks.
[18:25:03] --- smaes has left
[18:25:15] --- jr111 has left
[18:25:42] <pguenther> hey, no fair discussing food near the microphones
[18:25:46] --- bernard.desruisseaux has left
[18:25:54] <Dave Cridland> Exactly, my supper was hours ago.
[18:26:35] <Dave Cridland> BTW, anyone else on remote really tempted to think up stuff for the channeler to say that looks innocent written down, but when read out aloud...
[18:27:11] <pguenther> hehe
[18:27:14] * pguenther looks innocent
[18:27:53] <pguenther> "Dave is wondering whether our refridgerator is running..." <blank look>
[18:29:02] --- greg.vaudreuil has left
[18:30:12] <Dave Cridland> Night, all, anyway.
[18:30:19] --- Dave Cridland has left
[18:33:36] --- pguenther has left
[18:40:13] --- frodek has left
[18:41:36] --- robsiemb has left
[18:41:44] --- Glenn Parsons has left
[18:42:27] --- jimsch1 has left
[18:44:12] --- tianlinyi has left
[18:44:28] --- corby has joined
[18:45:47] --- corby has left
[18:46:39] --- tonyhansen has left
[18:47:28] --- Lyndon Nerenberg has left
[19:09:07] --- Glenn Parsons has joined
[19:12:59] --- Glenn Parsons has left