[09:07:16] --- amelnikov has joined
[09:17:52] --- kmurchison has joined
[10:06:36] --- Q has joined
[10:12:09] --- Q has left: Disconnected
[10:13:16] --- kuewong has joined
[10:28:28] --- hardie has joined
[10:34:51] --- randy has joined
[10:36:04] --- smaes has joined
[10:36:46] <hardie> Agenda is presented.
[10:37:13] <hardie> Bashing: channel++ increased to 1 hour, moved forward.
[10:37:48] <hardie> Channel++>>Content conversion
[10:37:55] <hardie> (after pull)
[10:40:55] --- corby has joined
[10:49:36] --- smaes has left
[10:50:42] --- corby has left
[10:51:07] <hardie> Any not in B.C in the room?
[10:51:41] <amelnikov> Ted: yes
[10:52:04] <kmurchison> me too
[10:52:34] <kuewong> I'm not the room either.
[10:53:24] --- corby has joined
[10:54:57] <corby> test
[10:56:41] <hardie> Thanks. Apparently, we're on an I/O break.
[10:57:33] --- resnick has joined
[10:58:05] <hardie> disappointed coffee-less people have returned; the machine is broken.
[10:59:04] <amelnikov> Is Lyndon in the room?
[11:01:25] <hardie> Yes.
[11:01:31] <hardie> Lyndon is here.
[11:02:31] <hardie> Server-to-Server Notification requirements, MMS Mapping, and Goals in WGLC; first two to IETF last call shortly.
[11:03:12] <hardie> Slides going to the mailing list.
[11:03:25] <resnick> Thanks.
[11:03:41] <resnick> Recieved
[11:04:21] <resnick> Would someone redial me. Accidental hangup.
[11:04:37] <resnick> (Went to hit mute, hung up.)
[11:05:13] <corby> Dialing you now
[11:05:18] <resnick> thx
[11:08:11] --- smaes has joined
[11:10:02] --- corby has left: Replaced by new connection
[11:10:02] --- corby has joined
[11:10:03] --- corby has left
[11:11:23] <hardie> Action item: future delivery to wglc
[11:11:42] <hardie> action item: goals to wglc
[11:11:54] --- corby has joined
[11:12:14] <hardie> Any reviewers in the room willing to sign up as stuckee for goals draft review? A message post-facto saying "no problem" or naming the issues would be the action.
[11:13:05] <hardie> Has anyone talked to Chris Newman about an update to the BURL draft?
[11:13:29] <hardie> The Chairs will hunt down stuckees for the reviewing the goals draft.
[11:15:51] <amelnikov> I've sent some comments to Chris about BURL, but I got no reply
[11:16:49] <resnick> I've got most of the voices, but would someone give the attendance list in Jabber?
[11:17:09] <hardie> WERe they private comments or on the list?
[11:17:23] <hardie> Scope of comments?
[11:17:35] <hardie> (e.g. nits, syntax error, etc.)
[11:18:05] --- resnick has left: Disconnected
[11:18:08] --- resnick has joined
[11:19:36] <amelnikov> I've sent private comments to Chris. The major issue was interaction with PIPELINING (AUTH command must be at the end of a group, so his example with SASL PLAIN is invalid, although for the PLAIN mechanism his example makes sense)
[11:20:21] --- resnick has left
[11:20:26] --- resnick has joined
[11:21:39] --- resnick has left: Disconnected
[11:21:42] <hardie> Issue WG last call with BURL, CATENATE, and URLAUTH, making sure that update handles outstanding issues like Alexey's
[11:21:55] --- presnick has joined
[11:22:26] --- presnick has left
[11:22:51] --- resnick has joined
[11:23:36] --- resnick has left
[11:23:46] <amelnikov> CATENATE is not ready, Pete has to add examples showing how to use it with drafts
[11:24:43] <amelnikov> ... Unless the WG makes a decision saying that such examples would be elsewhere (e.g. draft-melnikov-imap-disc-05.txt)
[11:25:02] --- resnick has joined
[11:25:07] <amelnikov> However, there are few issues with moving examples to draft-melnikov-imap-disc-05.txt:
[11:25:41] <amelnikov> 1) I would like to Last Call it and adding CATENATE might delay it for long time
[11:26:24] <resnick> Are folks reading e-mail? I just sent a comment about drafts and CATENATE to the list.
[11:26:39] <amelnikov> 2). draft-melnikov-imap-disc-05.txt is talking about Disconnected clients, even though instructions how to use CATENATE with drafts are generally useful for different types of clients
[11:27:29] <amelnikov> Pete: I haven't seen anything from you on the mailing list today
[11:28:39] <resnick> Sent 15 minutes ago.
[11:28:44] <hardie> amelnikov: your comments read; discussion now on whether these three need to be done at once or not
[11:29:14] <hardie> Pete what's your opinion on the status of CATENATE?
[11:33:25] --- kuewong has left: Disconnected
[11:36:09] --- hardie has left: Disconnected
[11:36:37] --- hardie has joined
[11:37:07] <hardie> discussion seems to indicate that the best *current* plan is to leave this conceptually simple at the cost of some bit sloshing.
[11:37:12] --- kuewong has joined
[11:39:02] <amelnikov> Ted, can you elaborate? I think it is very important for a document to have conceptual examples. This helps developers and can help to catch bugs in the document.
[11:39:23] <hardie> Pete can elaborate.
[11:39:39] <hardie> Now discussing where the examples go.
[11:41:01] <hardie> Amelnikov: your comment has been read to the group.
[11:41:23] <hardie> Now discussing whether a "big picture" document needs to go out with these 3.
[11:41:45] <hardie> Mark is saying that putting too many use cases in a protocol document is that it limits later use case.
[11:42:07] <hardie> So a separate document is better.
[11:42:49] <hardie> Randy is now talking about how the split was discussed in the past: one profile document (narrowly focused on resource-constrained client), but then the extensions would be general purpose.
[11:43:16] <hardie> Greg: Do they need to be stand-alone document, or should they have an informative reference to a profile document?
[11:43:46] <hardie> Eric/Randy: profile coming at the same time would help. The profile might have some background information, but so might the extensions documents.
[11:44:21] <hardie> e.g. Catenate might have a "why were these design decisions made"
[11:44:24] <amelnikov> I don't think the WG can Last Call CATENATE until we see some text on catenating drafts
[11:44:58] <hardie> amelnikov: use case texts?
[11:45:09] <resnick> I'm staying out of this since it's a little self-interested of me to not have to write the examples. :)
[11:45:09] <amelnikov> Examples and text
[11:45:31] <hardie> amelnikov: do you have an opinion on in CATENATE vs. in profile, with a pointer?
[11:45:54] <resnick> I don't have a problem if people want me to put the discussion in CATENATE, but I'll leave the decision to everyone else.
[11:46:52] <hardie> Greg is coming around to a document that describes use cases and the design decisions.
[11:46:52] <amelnikov> Profile document is Lemonade specific. People who will just look to CATENATE may not find the text (and CATENATE is generally useful outside of Lemonade)
[11:47:34] <amelnikov> So I would prefer if the examples are in CATENATE or a separate document (not profile)
[11:48:12] <amelnikov> Anyway, can we see the examples first and then decide where to put them?
[11:49:29] <hardie> reflected to the room
[11:49:53] <hardie> Randy agrees that individual documents need some examples, and the profile is a collection specfic to the individual use.
[11:51:26] <hardie> Pete takes action item to produce examples.
[11:56:07] --- Jean has joined
[12:02:54] <resnick> Coffee break, did I hear?
[12:08:13] <hardie> you did
[12:11:24] <hardie> Now discussing "channel" and its successors
[12:15:15] <hardie> now discussing transformation
[12:18:24] --- Glenn Parsons has joined
[12:18:25] --- psa has joined
[12:20:06] <randy> Ted mentions OPES, and use in SMTP
[12:21:29] <randy> (Earlier, Jerry mentioned STI (Standard Transcoding Interface) in OMA, which is an interface from a server to a smart transcoding box that know what transformations are needed given an entire message)
[12:21:53] <randy> (Earlier: discussion on who decides what transformations are needed: client or server)
[12:22:24] --- psa has left
[12:22:27] --- kuewong has left: Disconnected
[12:26:30] <randy> Client's platform capabilities may change dynamically (e.g., add more memory to handset, download PDF viewer, upgrade client, download new codec, etc.)
[12:29:34] <randy> Discussion of security/encryption
[12:29:49] <randy> Transformation changes stored form or only form sent to client
[12:35:56] <randy> Ted suggests we create a requirements document, and then see if the work should be done here or in OPES
[12:36:49] <resnick> Sorry, I was on the other line for a moment. Yelp in Jabber if you need me and I don't respond.
[12:41:45] <randy> client fetch data via IMAP or via RTSP or something new
[12:42:07] <randy> (testing.....)
[12:43:21] <randy> discussion of how much work the group should take on: new protocol to talk to conversion server?
[12:44:27] <randy> add capability for limited conversions to IMAP?
[12:49:18] --- Jean has left
[12:49:40] <randy> rtsp with or without transcoding
[12:50:04] <randy> what about non-streaming content (e.g., word/pdf to html)
[12:50:56] <randy> use imap, rtsp, http?
[12:50:56] <Glenn Parsons> Randy, did you just say that for streaming voice mail item that we have in the charter, channel no longer is needed as we can do it simply with URLAUTH?
[12:51:10] <randy> That's what I thought I heard
[12:52:39] <randy> Stéphan suggests everything go through http (streaming, static, etc.)
[12:53:15] --- Jean has joined
[12:53:27] <randy> IMAP client learns of content in an email message; uses URLAUTH to get a URL to it; passes it via HTTP to server and requests content transformation
[12:55:21] <randy> Corby asks if this limits use to high-end terminals: if we require rtsp etc. that limits usefullness
[12:56:47] <randy> Majority of use cases will be static documents such as Word, pdf, images, etc.
[13:01:45] <hardie> Chris Newman will rev BURL by the end of the week.
[13:02:50] <randy> Lyndon says he can modify CHANNEL to support the "B" case very easily
[13:03:19] <randy> "A" case: client uses URLAUTH and asks rtsp or http server for content, with or without transformations
[13:03:33] <randy> "B" case: client asks IMAP server for content with transformations
[13:03:58] <randy> Lyndon will send email around with suggestion
[13:05:34] --- kuewong has joined
[13:11:02] <randy> Discussion about CHANNEL (original intent/use case vs what we now have)
[13:17:59] <randy> Discussion of server advertising supported media types, or client requesting preferred types
[13:19:55] <randy> Lyndon concerned that the list of server-supported formats could be too large, plus client needs to keep track of this
[13:20:14] <randy> Having client request formats in preferred order may be lower bandwidth and easier on client
[13:21:43] <randy> suggestion for server to advertise top-level conversion capabilities (image/ text/)
[13:24:48] --- Arnaud has joined
[13:36:43] --- Jean has left
[13:36:44] --- Jean has joined
[13:43:14] <resnick> Anything going on there?
[13:44:11] <corby> Just finished the notes.
[13:44:14] <hardie> We're breaking for lunch
[13:44:20] <corby> We;re about to break for lunch,
[13:45:37] --- Glenn Parsons has left: Disconnected
[13:45:39] <amelnikov> I have to leave now, bye.
[13:45:41] --- amelnikov has left
[13:45:53] --- hardie has left: Disconnected
[13:45:53] --- corby has left: Disconnected
[13:45:53] --- Jean has left
[13:45:53] --- randy has left: Disconnected
[13:50:10] --- smaes has left: Disconnected
[13:54:36] --- randy has joined
[14:03:23] --- presnick has joined
[14:03:31] --- presnick has left
[14:03:37] --- resnick has left: Logged out
[14:03:48] --- resnick has joined
[14:04:39] --- Arnaud has left: Disconnected.
[14:12:05] --- Glenn Parsons has joined
[14:26:17] <Glenn Parsons> We're back from lunch...
[14:26:55] <resnick> I'm here, but may be in and out a bit.
[14:27:30] <Glenn Parsons> Pete, shall we keep you on the phone?
[14:27:52] <resnick> Sure, I'm listening. I'll probably drop off in 1/2 hour.
[14:29:38] --- hardie has joined
[14:34:16] <randy> We're back
[14:35:25] <resnick> Can I get these slides?
[14:35:34] <randy> Stéphan presentation on "lemonade and mobile email". Link for slides to be sent to list now.
[14:36:19] --- Jean has joined
[14:39:37] <randy> Discussion of user expectation of event latency: similar to desktop experience, or better (quasi-instantaneous)
[14:40:56] <randy> Corby said RIM did focus study on cross-section of Blackberry users to determine acceptable time linit for email delivery from server to Blackberry. Users felt 30 minutes was OK except in cases of critical email.
[14:41:43] <randy> Stéphan says users expect mobile email to be as fast as SMS
[14:42:30] --- Arnaud has joined
[14:42:37] <randy> Suggestion that most users have POP clients configured to check mail every 3-6 or 5-15 minutes
[14:43:12] <randy> Pete: two cases; "A": notifications while connected (handled now); "B" notifications while disconnected (out of scope)
[14:46:10] <randy> Discussion about Notifymail
[14:46:53] <randy> Pete says he uses NOTIFYMAIL because his client does not support IDLE and hence can't get unsolicited asynch notifications of new mail
[14:48:03] <randy> Lyndon says he objects to bastardizing IMAP to work around defect in mobile network because they can't keep TCP session up for more than 30 seconds
[14:49:07] <randy> Pete: we can fix mobile networks so TCP connections don't go away, or do something out of band and that isn't an Internet protocol
[14:49:23] <randy> Ted says TCP session going away is a separate problem from connection going away
[14:50:01] <randy> Lyndon, et al say the problem is that when transport goes away you get a new IP address
[14:51:15] <randy> Randy says networks have a concept of "always on" has been around for a while
[14:51:24] --- tonyhansen has joined
[14:52:18] <randy> your IP address is maintained even when your traffic channel goes away
[14:52:26] <randy> doesn't need mobile IP or IPv6
[14:53:30] <randy> (back to slides)
[15:02:57] <randy> In slides, "wall guarded" = "walled garded"
[15:07:23] <hardie> A reference to BLOAT is made.
[15:07:27] * hardie's head hurts.
[15:07:28] <randy> Discussion of use over RFC 3252 (IP over XML/HTML)
[15:07:42] * resnick is on the other line and will be back soon
[15:07:42] <randy> BLOAT = RFC 3252
[15:07:59] <randy> *the room thanks Pete for not putting us on music-on-hold
[15:12:21] <randy> [ Oops -- In slides, "wall guarded" = "walled garden"]
[15:14:41] * resnick is back on the call
[15:14:58] <resnick> Which slide are we on?
[15:15:18] <randy> the pretty pictures
[15:15:38] <resnick> And people are now pointing at the boxes?
[15:15:42] <resnick> Or circles?
[15:15:56] <randy> yes, and using helpful terms such as "this"
[15:16:46] <randy> Discussion of possibility of direct connection between client and server (e.g., over VPN, TLS)
[15:17:22] <randy> Stéphan: problems with VPN (not available on client, VPN drops and needs to be re-established whenever connection drops)
[15:18:02] <randy> Ted: core problem is two conflicting entities that each want a walled garden: operator and enterprise
[15:25:52] <randy> Pete: our job is not to devise work around for broken operators deployments
[15:26:36] <resnick> And more to the point, that if they don't take the open standard solutions we give them, we can't help them anyway.
[15:26:46] <randy> Ted: we should not strive for bug-wards compatible, we should define the right solution
[15:28:09] <randy> Stéphan: lemonade should provide protocol for mobile email; OMA looks at rest of problem and provides what is missing, referring to lemonade
[15:29:26] <randy> Pete: we can provide pieces, that if taken together in five years would provide the perfect solution, but even today could be used, perhaps with some temporary hacks, to get to a solution
[15:30:00] <randy> Mark: we should concentrate on technology, not trying to change operator's policy or business models
[15:30:22] <randy> Greg: instant notification is important but not part of our scope
[15:31:00] --- resnick has left
[15:31:08] --- resnick has joined
[15:32:04] <randy> Ted: we can specify how an IMAP server sends notifications over TCP for a long-lived session is good, but we don't need to specify how this works when it isn't available (e.g., SMS notification)
[15:33:32] <randy> Stéphan: when we specify notifications we should do it in a general way that doesn't assume in-band, and hence can be used out-of-band
[15:33:43] <randy> Stéphan: IDLE doesn't work
[15:33:46] <randy> Discussion on IDLE
[15:34:30] <randy> Mark: not a big jump from IDLE (which says "tell me when something changes in the currently selected mailbox") to something that says "tell me when something changes in this set of mailboxes"
[15:35:17] <randy> Pete: what is the problem with IDLE other than maintanance of TCP across traffic chanel shutdowns
[15:35:18] <randy> ?
[15:35:43] <randy> Corby: if client uses IDLE over TLS, it cuts battery life by 1/4
[15:36:28] <randy> Corby: normal phone has two CPU cores: one for voice and one for data, only voice core is low-power and effecient
[15:38:02] <randy> Requests for clarifications on use of IDLE with dormant mode (so-called "always on")
[15:38:32] <randy> Statements than IDLE would be fine in such case, but domant mode is not possible today.
[15:42:04] <randy> Ted: Lyndon's point about having profile describe how to operate in different situations, such as when network provides certain capabilities and when it doesn't
[15:49:35] <resnick> "Solving the problem in the best (perhaps long term) way" and "solving the problem given the current state of affairs" are not mutually exclusive.
[15:50:12] <randy> Stéphan is concerned that if we aim at a standard that is too far down the road before it can be used, by then it will be irelevant, because others will have proprietary solutions that have become de facto standards
[15:50:13] <resnick> We can come up with some solutions that will be useful in the interim but don't lock us into stupidity for the long term.
[15:51:20] <resnick> e.g., Maybe RECONNECT is not the easiest way to deal with the "IP address going away" problem, and perhaps a protocol that could do notifications would be more convenient in the current state of affairs,
[15:51:38] <resnick> but the former is OK for the long term and the latter (instead of using IDLE) is bad for the long term.
[15:51:54] <randy> Corby: we need to also cover cheap handsets, not limit to very high-end handsets (such as Blackberry does -- focus on top 5% of company)
[15:52:21] <resnick> SPEAK LOUDER PLEASE!
[15:52:38] <resnick> ;)
[15:55:48] * resnick has to go off to an IAB Telechat
[15:55:56] <resnick> Please Jabber as much as you can.
[15:56:11] <resnick> I'll keep an eye on the Jabber room.
[15:56:29] <Glenn Parsons> Thanks for participating Pete.
[15:56:46] <resnick> Thanks. You may now hang up.
[15:58:06] --- kmurchison has left
[15:58:26] --- kuewong has left: Disconnected
[16:00:41] <randy> discussion on TCP issues
[16:00:50] <randy> Chair moves discussion to compression
[16:00:58] <randy> Discussion now covers encryption
[16:01:51] <randy> "gzip and TLS with null cypher have roughly equal number of instructions, complexity, etc."
[16:02:47] <randy> Ted asks if TLS libraries on handsets can handle null cypher
[16:04:37] <randy> Mark says his servers require TLS
[16:05:17] <randy> Lyndon says argument as to support by current hardware doesn't matter, since current hardware can't do much IMAP anyway, and new handsets are coming out rapidly
[16:05:52] <randy> Ted says there are cases where encryption exists already (IPSec or whatever) so TLS with more encryption is not wanted
[16:06:30] <randy> Stéphan says firewalls today don't permit STARTTLS
[16:15:33] <randy> Have we agreed that TLS is the right answer for compression?
[16:15:35] <randy> Corby: TLS is only partially (or not at all) implemented in terminals
[16:16:54] <randy> (sorry, we were talking about encryption: TLS is the right answer for link-level encryption)
[16:17:08] <resnick> Stephane: Firewalls don't allow the STARTTLS command to go across the same port as IMAP (143)?
[16:17:20] <randy> Greg: concerns raised on list regarding interaction of quick-reconnect and TLS
[16:17:38] <resnick> (That was a question to Stephane)
[16:17:44] <randy> Corby: TLS is ineffecient compared to application-specific compression, such as JPEG
[16:18:25] <randy> (such as when the application has JEPGs to send0
[16:18:31] <randy> )
[16:19:00] <randy> now discussing compression
[16:19:30] <randy> Lyndon: compresisng IMAP commands is swamped in noise with large MIME parts
[16:20:44] <randy> Stéphan talks about option for application-level encryption
[16:22:58] <resnick> *protocol*-application-level encryption?
[16:23:16] <resnick> (and "encryption", not "compression"?)
[16:23:37] <randy> yes and yes
[16:24:13] <resnick> And STARTTLS (on the same port) is unacceptable because....?
[16:24:31] <randy> Mark says mandatory options are very expensive and should be avoided at all costs
[16:26:32] * resnick waits for anwers to his questions (if possible)
[16:26:47] <randy> "need to give people advance warning of new requirements, such as opening ports on firewalls, non-broken TLS, etc."
[16:27:09] <randy> Stéphan wasn't saying it was impossible
[16:27:32] <randy> Corby suggests doing things as plug-ins rather than waiting for platform upgrades
[16:27:43] <resnick> "opening ports on firewalls" is not a requirement, is it?
[16:27:56] <resnick> TLS doesn't go over a different port, right?
[16:28:42] <randy> I sure hope not, I was just reporting what people were saying
[16:29:41] <resnick> For repeating to the room: "opening ports on firewalls" is not a requirement, since TLS doesn't go over a different port. Does anyone in the room not understand that?
[16:30:02] <randy> Mark asks when handsets will support open OSes; or when it will be possible to do so
[16:30:54] <randy> comments that operators don't want users changing OSes
[16:31:01] <randy> because they'd have to support it
[16:31:13] <resnick> To Mark: Given that handsets will inevitably have access to a horribly insecure telecom network, I wouldn't hold my breath.
[16:31:39] <randy> Mark says Verizon allows you to register any CDMA device
[16:31:42] <randy> comment that they will, but they won't sell you those handsets
[16:32:12] <resnick> and the fact that there's implicit trust that nobody's got a CDMA device with an open OS.
[16:32:25] <resnick> (Silly Verizon)
[16:32:43] <randy> because you could bring down the cell if you can controll, say, power output
[16:33:44] <randy> Arnaud's slides on compression
[16:35:09] <randy> draft is available, and slides are being sent to list
[16:39:51] <randy> Lyndon suggests that Mulberry is not using pipelining, and hence the numbers look worse than they would be with a smarter client
[16:49:24] <randy> Stéphan asks if the numbers allow comparison to compression of only IMAP commands, only payload, or both
[16:50:14] --- kmurchison has joined
[16:51:28] <randy> Lyndon comments that saving 4 bytes by sending "F" instead of "FETCH" is swamped by the turn-around for round-trips
[17:01:19] --- hardie has left: Disconnected
[17:01:58] --- Jean has left
[17:02:40] --- Glenn Parsons has left: Disconnected
[17:02:40] --- Arnaud has left: Disconnected.
[17:02:43] --- randy has left: Disconnected
[17:03:35] --- randy has joined
[17:03:52] --- Glenn Parsons has joined
[17:04:42] <randy> (some of my scribe notes were lost because I "sent" them while disconnected -- sorry)
[17:11:42] <randy> discussion of any benefit to compresison and/or encryption outside of TLS
[17:12:41] * resnick waits with bated breath to hear about any reasons to do so
[17:13:35] --- tonyhansen has left: Disconnected
[17:15:24] --- Glenn Parsons has left: Disconnected
[17:20:38] --- randy has left: Disconnected
[17:22:04] --- randy has joined
[17:22:59] <randy> [ lots of discussion occurred when I had no connectivity ]
[17:23:20] * resnick mumbles loudly
[17:24:00] <randy> [ I had been typing updates and attempts to capture some of the back-and-forth, along with exortations to Pete to start breathing then realized none of it was showing up ]
[17:27:02] <randy> Mark says major problems are: no way to have client ask server to redo last search, sort, etc. and show only what has changed; also no way to get a sequence (such as the result of a search) and use it for something without sending the sequence back to the server
[17:27:05] --- Arnaud has joined
[17:28:48] <randy> Ted: we can put into a profile right now that use of binary fetch is critical
[17:33:19] <randy> Conclusions: use binary fetch in absense of compression; compression argument needs further study to determine if most data is already compressed (e.g., jpegs);
[17:35:26] <randy> ...not harmful to use binary fetch in the presence of compression
[17:35:45] <randy> ...if encryption is being used with TLS, may as well turn on compression as well
[17:36:24] <resnick> And what was the conclusion of the NULL cypher discussion?
[17:36:39] <resnick> OK, but maybe not necessary?
[17:36:52] <randy> null cypher and compression?
[17:36:59] <resnick> Right.
[17:38:15] --- corby has joined
[17:38:25] <randy> Ted says double encryption often undesirable, so if encryption being done elsewhere, and TLS being used for compression, might want to use null cypher
[17:39:25] <resnick> And so if you want to do compression, TLS w/NULL cypher and compression is what LEMONADE will recommend?
[17:40:18] <randy> We need numbers to know what to recommend
[17:40:44] <randy> We need data to determine what percentage of email attachments today are already compressed, and hence if compression is needed
[17:44:26] <randy> Discussion on quick-reconnect
[17:47:38] <randy> Do we need to address the case where a connection drops? If so, do we need to address it with protocol or recommendations?
[17:49:08] <randy> Ted: quick-reconnect is useful even ignoring dropped connections
[17:49:32] <randy> Randy: is the problem reconencting after a short period, or that resynches (after however long) takes too long
[17:55:16] * resnick has to run
[17:55:19] <resnick> l8r all
[17:55:34] <randy> *bye Pete
[17:57:10] <randy> Mark makes point about how much of the full mailbox state does a client need to keep
[17:58:44] <randy> Mark suggests taking look at how online clients operate, and suggests some of their strategies would be useful for disconnected clients
[18:01:18] <randy> Discussion of quick-reconnect vs reconnection by disconnected client
[18:01:29] <randy> Mark suggests looking at Chris Yaeger's work at Sun
[18:05:07] <randy> Discussion of CONDSTORE and ANNOTATE
[18:05:45] <randy> Correction: Bill Yeager
[18:06:13] --- Glenn Parsons has joined
[18:08:37] --- corby has left: Disconnected
[18:12:29] <randy> Discussion on milestones
[18:26:05] <randy> we're done
[18:27:46] --- kmurchison has left
[18:27:57] --- Arnaud has left
[18:29:05] --- Glenn Parsons has left: Disconnected
[18:45:48] --- randy has left: Disconnected
[20:35:19] --- resnick has left