[00:11:03] --- dcrocker has joined
[00:11:04] --- dbrashear has left: Lost connection
[00:26:18] --- dcrocker has left: Replaced by new connection
[00:27:20] --- dcrocker has joined
[03:09:40] --- dcrocker has left: Replaced by new connection
[03:09:40] --- dcrocker has joined
[03:09:40] --- dcrocker has left
[08:37:43] --- corby has joined
[09:09:27] --- corby has left
[09:57:55] --- tonyhansen has joined
[10:36:14] --- tonyhansen has left: Disconnected
[10:50:29] --- tonyhansen has joined
[11:01:00] --- resnick has joined
[11:03:28] --- resnick has left: Disconnected
[11:06:50] --- resnick has joined
[11:08:19] --- robsiemb has joined
[11:10:49] --- pguenther has joined
[11:13:07] --- tonyhansen has left: Disconnected
[11:17:03] <resnick> Agenda
[11:17:07] <resnick> Summarize day 1
[11:17:12] <resnick> Goals Phase 2
[11:17:19] <resnick> (What was that last thing?)
[11:17:45] <resnick> Consensus hum heard on Barbara-the-baby.
[11:17:58] <resnick> Summary Day 1:
[11:18:08] <resnick> Alexey to update Reconnect
[11:18:13] <resnick> Mike to update ClearIdle
[11:18:29] <resnick> Stéphane to provide state numbers
[11:18:48] <resnick> Discussion of Static Coversion vs. Stream Conversion
[11:19:10] <resnick> Descriptors Negotiation Control (e.g. CONNEG)
[11:19:28] <resnick> Mike to Summarize Discussion and get to list & Lyndon
[11:19:40] <resnick> Lyndon to either update or abandon CHANNEL
[11:19:43] <resnick> New ID
[11:20:31] <resnick> Barry: CHANNEL designed for streaming. If you're doing it for media conversion, punt it and choose something else.
[11:21:15] <resnick> Pete: Convey that to Lyndon
[11:22:36] <resnick> Also day 1: Alexey and Eric working on an individual submission on Reliable Delivery.
[11:22:43] <resnick> Profile:
[11:23:04] <resnick> Need Examples
[11:23:15] <resnick> Discussion of Media Conversion (once we decide)
[11:23:20] <resnick> Quick Reconnect
[11:23:29] <resnick> Streaming
[11:25:19] <resnick> Hope to have new rev prior to 14 Feb.
[11:28:21] --- smaes has joined
[11:35:04] <resnick> Discussion starts on phase 2:
[11:36:19] --- randy has joined
[11:36:54] <resnick> Pete: Process point on whether to re-charter or close down and new group. Tabled until we see the list of potential topics.
[11:37:47] <resnick> Topics:
[11:37:54] <resnick> - S2C notification
[11:38:03] <resnick> - Firewall Traversal
[11:38:20] <resnick> - Filtering
[11:38:33] <resnick> - Transport Optimizations
[11:38:39] <resnick> Randy: What's that?
[11:38:59] <resnick> Stephane - Round-trips, BW, Data
[11:39:48] <resnick> Randy: We have to be specific. Some of the solutions are already there, but have to be identified.
[11:40:04] <resnick> Stephane: Maybe need a profile
[11:40:30] <resnick> Where does S2S go from here?
[11:41:38] <resnick> Chairs: That's in charter, so perhaps we need to just do it.
[11:42:58] <robsiemb> Pete: can we drill down on S2C?
[11:43:57] <robsiemb> Pete: in the scenarios where we have a network connction, IDLE should be enough
[11:44:05] <robsiemb> Steph: yes
[11:44:39] <robsiemb> Stephane: I would like to do SMS, or WAP push, or so on...
[11:45:05] <robsiemb> Pete: Lets leave aside nonIP, so if we have an IP connection but not IMAP, and want to be able to send a notification via IP...
[11:47:27] <robsiemb> Chairs: do we need anything more than SIP message waiting indicators?
[11:47:29] <robsiemb> .
[11:47:29] <robsiemb> .
[11:47:32] <robsiemb> []
[11:47:33] --- robsiemb has left
[11:47:37] --- robsiemb has joined
[11:48:11] * robsiemb wonders why he got kicked off
[11:48:41] <robsiemb> Discussion about separating what the message carries (IMAP notification outside of IMAP session) from transport
[11:50:49] <robsiemb> Pete: emphasis that we want to limit ourselves to IMAP events.
[11:57:14] <resnick> Discussion on whether this is just "IMAP IDLE over notifications"
[11:59:14] <robsiemb> Lisa: There are other notification protocols (general purpose) already existing.
[11:59:45] --- corby has joined
[12:01:13] <robsiemb> Pete: I think the actual requirement is not "not be done in imap" but "using a channel that [mobile] devices have set up anyway"
[12:01:22] --- dcrocker has joined
[12:07:56] <robsiemb> Phillip: I see 2 goals being discussed: lightweight transport-independent protocol for notifications, and a somewhat separate desire to do close to full sync
[12:08:30] <resnick> I think philip was more making the distinction between the transport issues and the content of the notification issues.
[12:08:58] --- corby has left
[12:09:14] --- corby has joined
[12:11:09] --- cyrus_daboo has joined
[12:12:16] <resnick> Randy: Are we just talking about "wake up" events, or are we sending re-sync info (which is much more complicated).
[12:13:01] <randy> One implication of the distinction is if the server cares if the client received the notifications, and if there are any implications for client reconnects and resynchronizations
[12:13:45] <cyrus_daboo> Note that there are several other protocols that need some form of notification capability. In particular the CalDAV protocol that uses WebDAV for calendar access is in need of something to notify of changes to events etc on the server (this is needed for bth mobile and desktop clients). So I think S2C is a much more general problem that in fact needs its own WG as it is likely to span multiple protocols.
[12:14:06] <corby> Wake-up events are much simpler to implement and can be defined in generic terms so we don't have to spec a specifc protocl (like SMS, MMS, etc.)
[12:14:29] <randy> A few people mentioned that we already have general-purpose events
[12:14:41] <randy> Corby: absolutely
[12:15:14] <robsiemb> cyrus: Lisa mentioned this that it might be ok to keep up a single xmpp session to handle this
[12:15:41] <resnick> For those not in SF: I have an iSight camera, so if anyone has an iChat AV or AIM 5.x client, I can provide sound and video to someone.
[12:16:51] <corby> One thing to consider is mobile-terminal implementers. Code space and executable foot prints are a premium. Complex packet structures will be more expensive to add into the message stack.
[12:17:58] <randy> (Discussion on use of webdav notification protocol; expression that it is too information-poor and thus forces the client to connect and ask for more information)
[12:19:56] <cyrus_daboo> Hey Pete - what do I need to do to get to you via iChatAV?
[12:24:09] <robsiemb> losing local uplink briefly
[12:24:17] --- robsiemb has left: Logged out
[12:29:33] --- dbrashear has joined
[12:34:10] --- resnick has left: Disconnected
[12:34:20] --- robsiemb has joined
[12:34:35] --- resnick has joined
[12:35:04] --- pguenther has left: Disconnected
[12:35:21] --- randy has left: Replaced by new connection
[12:35:21] --- dcrocker has left: Disconnected
[12:35:21] --- randy has joined
[12:35:43] --- pguenther has joined
[12:40:22] <resnick> The current slides are on the web site.
[12:41:17] --- resnick has left: Disconnected
[12:43:59] <cyrus_daboo> VIEW proved hard because of the interaction with SORT and THREAD, and the issue of dynamic vs static views and how to deal with updates.
[12:46:24] <randy> Discussion of filtering; comparisons to imapext VIEW/SORT
[12:46:29] <randy> and threading
[12:47:11] <randy> Rob mentions that removing a message can alter the thread in critical ways
[12:47:13] --- dcrocker has joined
[12:47:46] <cyrus_daboo> Right - the arrival or removal of a message in THREAD view can completely change threads - it might break them or merge them.
[12:48:51] <cyrus_daboo> We might want to take VIEW a little further and consider a 'Virtual Mailbox' extension to IMAP. A lot of email clients nowadays are offering client-side virtual mailbox views and having the ability to do the same via server-side would be good tooo.
[12:50:31] --- resnick has joined
[12:50:40] <cyrus_daboo> No - thread is very, very useful - don't touch it .
[12:54:16] <cyrus_daboo> With a virtual mailbox you can just use a 'virtual sequence number' to do windowing. Right now clients can use sequence numbers for windowing, though not with SORT/THREAD as well. A virtual mailbox would not have that restriction as the virtual view could be already sorted...
[12:56:58] <cyrus_daboo> good point on relational databases...
[12:57:59] <cyrus_daboo> The trouble is that might be hard to fir into the IMAP data model.
[13:00:09] <pguenther> moving on to firewall traversal
[13:01:20] <cyrus_daboo> firewalls are not just an issue wrt traversal, but also with timeouts - often firewalls will timeout an idel connection in a short time period (e.g. 10 minutes) but IMAP sessions are allowed to be idle for a long time (up to 30 minutes).
[13:02:20] <cyrus_daboo> Its a problem with NATs and firewalls and other types of gateway devices.
[13:02:43] <cyrus_daboo> Both software and hardware based firewalls do that.
[13:04:12] <randy> Phil notes that when we were talking about TCP keeping sessions across brief outages, we said th eproblem was sending keep-alives; now regarding firewalls/NATs, we
[13:04:29] <randy> we're saying if you don't send keep-alives the connection drops.
[13:05:13] <randy> Pete notes that there are a lot of issues with lower-level (below L-7) breakages
[13:05:41] <randy> Pete suggests it is a problem if a L-7 group (meaning us) works on a problem which is broken L-2/L-3
[13:08:25] --- dbrashear has left: Disconnected
[13:11:11] <cyrus_daboo> One could argue that software firewalls are a layer 7 (application) in that real end-users get to play with them and possibly mess things up.
[13:20:05] <randy> Discussion of creating document to present details of what the problems are
[13:20:33] <randy> Could be used to get groups such as 3gpp/2 that have more control over deployments
[13:21:08] <randy> Chairs ask for document by Feb 14 and ask if Dave and Stéphan can be authors
[13:23:43] <randy> Now discussing "transport optimizations"
[13:24:37] --- resnick has left: Disconnected
[13:26:57] <randy> Discussion of compression
[13:27:45] <cyrus_daboo> The client gets to set the compression in TLS so it can then decide whether or not to compress the MIME data being transported as well.
[13:30:43] --- dbrashear has joined
[13:33:01] <randy> Disucssion of need for more data to determine if compression is needed and if not, a published document to explain why
[13:33:42] <randy> Pete suggests it would be more appropriate for an IRTF group
[13:33:52] <randy> Ted suggests this group has the most interest and could do it
[13:35:20] <cyrus_daboo> I've not heard of anyone (other than Qualcomm) doing performance test...
[13:38:25] <cyrus_daboo> What about resurrecting IMC as a means for organising research/testing etc?
[13:39:02] <randy> Good idea, Cyrus
[13:39:35] <robsiemb> Discussion about procedure....
[13:39:35] <smaes> Actually we did test between IMAP and gzip.
[13:39:55] <smaes> We did not do the test as qualcomm did but I am convinced that gzip bring sa significant gain
[13:39:56] --- resnick has joined
[13:40:15] <smaes> I can't guarantee however that there may not be better ways to do so
[13:40:21] <robsiemb> Pete: This WG spends a lot of time asking "do we need x, y, z?" we need someone to tell us if these things are needed. (Specifically notifications beyond IDLE, compression, etc)
[13:40:58] <cyrus_daboo> Has anyone considered a binary encoding scheme - something similar to the WBXML <-> XML approach? Or is the idea of a binary protocol alternative too hard to swallow...
[13:41:41] <randy> Ted says we know there is pressure to do compression, but we don't know if it is stupid or not
[13:48:19] <randy> Pete suggests compression on an IMAP body-part basis seems similar to the content transformation stuff we were talking about yesterday
[13:48:37] <randy> Ted notes that the security implications for the two were very different
[13:48:44] <randy> Others note that there is overlap
[13:49:30] --- randy has left: Logged out
[13:49:35] --- randy has joined
[14:00:49] <randy> Discussion about status of s2s work
[14:01:25] --- dbrashear has left: Disconnected
[14:01:30] <cyrus_daboo> Can't you consider S2S as a subset of the general notification issue?
[14:10:25] --- smaes has left
[14:14:00] --- tonyhansen has joined
[14:22:34] <tonyhansen> are people on a break? or just the note taker?
[14:23:14] <cyrus_daboo> They have gone to lunch. At 1 pm EST there will be imapext discussions taking place on imapext jabber room.
[14:23:28] <cyrus_daboo> Sorry that was 1 pm PST (not EST).
[14:25:20] <corby> Thanx Cyrus.
[14:25:33] <corby> Cyrus: Will SIEVE have interim meetings?
[14:27:06] <cyrus_daboo> No. We were discussing whether to have a meeting at the next IETF in MSP. It may be that both chairs cannot attend (my wife has a baby due close to that time), but I think we really need to have a meeting to keep things moving forward, assuming enough people will be present.
[14:27:29] <cyrus_daboo> Also I am about to try and pick up the pace on the mailing list which has been quite for a while...
[14:27:45] <corby> Agreed. Lotsa interest in SIEVE and lotsa docs to go.
[14:28:17] <corby> k, thanks.
[14:36:38] --- tonyhansen has left: Disconnected
[14:39:59] --- cyrus_daboo has left
[15:01:50] --- corby has left
[15:02:51] <resnick> Please feel free to come over to imapext@ietf.xmpp.org.
[15:05:35] --- pguenther has left
[15:05:55] --- randy has left
[15:33:14] --- resnick has left: Disconnected
[15:33:14] --- resnick has joined
[15:33:14] --- resnick has left: Lost connection
[15:40:44] --- resnick has joined
[15:44:26] --- resnick has left: Disconnected
[15:47:37] --- robsiemb has left
[15:48:49] --- resnick has joined
[15:56:09] --- corby has joined
[15:56:29] <resnick> We're over in the imapext@ietf.xmpp.org room.
[16:01:47] --- resnick has left: Disconnected
[16:01:56] --- resnick has joined
[16:03:27] --- resnick has left
[16:03:36] --- corby has left
[16:20:43] --- dcrocker has left: Disconnected
[16:37:46] --- dcrocker has joined
[16:59:32] --- tonyhansen has joined
[19:17:55] --- tonyhansen has left: Disconnected
[21:45:39] --- dcrocker has left: Replaced by new connection
[21:45:39] --- dcrocker has joined
[21:45:40] --- dcrocker has left