[08:55:11] --- alexeymelnikov has joined
[11:13:50] --- Glenn Parsons has joined
[11:15:18] <Glenn Parsons> Testing 123
[12:00:53] <Glenn Parsons> FYI, we will be starting a 1pm Central time...
[12:02:10] <alexeymelnikov> In 50 minutes?
[12:35:44] --- kmurchison has joined
[12:53:29] <Glenn Parsons> We'll be starting ina about 5 minutes...
[12:56:52] --- resnick has joined
[13:02:06] --- resnick has left: Disconnected
[13:07:33] --- resnick has joined
[13:07:43] --- resnick has left: Disconnected
[13:09:23] <Glenn Parsons> Randy has volunteered to be jabber scribe.
[13:10:12] <alexeymelnikov> Glenn, can you tell how many people are in the room?
[13:10:42] <Glenn Parsons> 10 people so far, but I'm expecting a few more...
[13:10:59] <alexeymelnikov> who?
[13:14:25] --- resnick has joined
[13:14:28] --- Randy has joined
[13:15:12] --- smaes has joined
[13:15:19] <Glenn Parsons> Note that all minutes will be on jabber....
[13:15:21] <Randy> 10 people, including the chairs
[13:15:37] <Randy> Chairs: goal is to get drafts done before San Diego (2-3 weeks)
[13:16:03] <Randy> Chairs: then last call in November
[13:16:10] <Randy> (Agenda Bashing)
[13:16:31] <Randy> Agenda:
[13:16:36] <Randy> Pull Implementation Plan
[13:16:42] <Randy> 3GPp Liaison
[13:16:44] <Randy> IMAP profile
[13:17:00] <Randy> Random bits: notifications, channel, future delivery, various docs rwady for WGLC)
[13:17:09] <Randy> Need authors
[13:17:28] <alexeymelnikov> Authors for which bits?
[13:18:19] <resnick> Will be discussed tomorrow.
[13:18:44] <Randy> Authors needed will be discussed tomorrow (there are lots of parts of PULL, so we'll discuss what we still need)
[13:18:49] <resnick> We'll decide what docs are needed and then re-confirm authors who already existed.
[13:19:07] <Randy> Will need committment from authors to get drafts before San Diego
[13:20:16] <Randy> Pull implementation plan:
[13:20:30] <Randy> mechanism discussion: BURL/CATENATE? Other?
[13:20:40] <Glenn Parsons> FYI - meeting docs/slides are on the web: http://flyingfox.snowshore.com/i-d/lemonade/slides59-5
[13:20:44] <Randy> Pawn Ticket: separate document
[13:21:54] <Randy> Dave Crocker asks if it is worth charting out the costs, advantages, drawbacks of implementation options?
[13:22:48] <Randy> Pete asks what we would compare BURL/CATENATE to? Embedded URL?
[13:22:55] --- smaes has left: Replaced by new connection
[13:23:22] --- smaes has joined
[13:24:03] <Randy> Rob: draft-crispen-lemonade-pull discusses some of this
[13:24:34] <Randy> Randy notes that we've already spent over a year and we need to make progress, suggests that if we do a study it be done in parallel
[13:25:16] <alexeymelnikov> Randy: we've already spent more than 3 years in IMAPEXT ;-)
[13:26:10] <Randy> Alexey: mobile email/MMS is moving forward, we need to get in
[13:26:13] <Randy> (chairs walk through PULL mechanism)
[13:28:17] <alexeymelnikov> Randy: I don't disagree, this was just a cynical note
[13:28:36] <Randy> Glenn asks if you get FCC without CATENATE
[13:28:42] <Randy> Randy says not in a standard mechanaism
[13:28:58] <Randy> Glenn suggests lemonade define submission as CATENATE/BURL
[13:29:49] <Randy> Gelnn suggests "a lemonade compliant server MSUt support CATENATe/BURL"
[13:30:05] <Randy> ...a client MAY use CATENATE/BURL or normal Submission
[13:30:46] <Randy> Glenn suggests lemonade requirements are on the server; the client may use them or not
[13:31:25] <Randy> Suggestions that lemonade produces a protocol; all lemonade-compliant implementations must support it
[13:33:41] <Randy> Glenn asks if a lemonade-compliant client can download and upload if it wanted to
[13:33:56] <Randy> Robb says it has to in order to support non-lemonade servers
[13:34:12] <Randy> Randy notes that the point of lemonade is to allow clients on thin devices that can't do that
[13:36:41] <Randy> (Chairs draw pictures on board)
[13:38:52] <Randy> Pete: you use CATENATE to create a message on the IMAP server which may include pointers to other messages; the IMAP server expands these
[13:41:48] <Randy> Pete notes that the client may or may not need to fetch anything from the IMAP server prior to using CATENATE; it may be a new message
[13:44:02] --- Jean Sini has joined
[13:44:07] <Randy> Glenn asks if the response to CATENATE means that all references were located and everything is OK
[13:45:15] <Randy> Pete: semantically, assmbly occurs on CATENATE (it is of course up to the server to copy data or store pointers and use reference counting)
[13:46:04] <Randy> Glenn asks if response from BURL means that the submit server has fetched the data from IMAP
[13:47:18] <Randy> Pete notes that there are costs with that
[13:47:50] <Randy> Randy suggests that it is reasonable to impose this, along with significantly shortening the maximum timeouts for various submission commands
[13:50:07] <resnick> Randy: We may be able to pick one and change it later.
[13:50:50] <Randy> We can, for example, decide on synch and someone later can add an asynch extension
[13:51:51] <Randy> Pete suggests that we could generate a bounce since we have a return path
[13:52:08] <Randy> Glenn notes that the client would be at a loss to regenerate the content
[13:52:13] <Randy> This is different from usual bounces
[13:52:55] <Randy> Discussion of semantics for bounces
[13:53:21] <Randy> Dave says latency is an issue; we need to be robust against latency (such as between submit server and IMAP server)
[13:53:58] <Randy> Discussion of latency and reliability
[13:54:10] <Randy> Pete notes that an OK to the SMTP DATA command means the server owns the data
[13:54:20] <Randy> (has accepted responsibility for it)
[13:59:00] <Randy> Dave suggests that CATENATE needs to lock the data until it gets a reference to it
[14:01:10] <Randy> Dave suggests that CATENATE is a special message; it will be used in a reference
[14:01:32] <Randy> Pete suggests that CATENATE itself does not make the message special; it is only BURL that treats a message specially
[14:01:46] <Randy> Dave suggests that CATENATE creates a message that is single-use
[14:01:59] <Randy> Pete asks if that means the pawn ticket deletes the message
[14:02:56] <Randy> Pete suggests that CATENATE creates a reference to the message that will only be deleted by use of the pawn ticket
[14:04:11] <Randy> Correction: the creation of the pawn ticket creates a reference to the message that gets deleted by its use
[14:04:33] --- corby has joined
[14:07:07] <Randy> Glenn suggests that this is adding way too much complexity
[14:07:20] <resnick> (That was Eric)
[14:08:06] <Randy> Eric says the volumes are too high; no matter how low the probability the number will be noticable
[14:08:32] <Randy> Dave says that whenever we create protocols that ignore edge cases we lose sooner or later
[14:11:22] <Randy> comment that CATENATE in reality adds a message queue to the IMAP server
[14:14:16] <Randy> Dave notes that the reason for the complexity on the IMAP server is that we are using it to assemble messages
[14:15:22] <Randy> Pete suggests that this be deferred to the PULL authors; they need to deal with it
[14:19:54] <Randy> Glenn discusses future delivery
[14:20:29] <Randy> Glenn: we now have two queues; one on the IMAP server (the CATENATEd messages) and one on the submit server
[14:22:49] <Glenn Parsons> Time for a lemonade break....
[14:32:05] <Randy> with actual lemonade, just the thing for the Texas swelter
[14:38:47] <Randy> Eric: during break, discussed latency issues. We are doing an Internet protocol, hence it could be used on a WAN. There may be significant latencies. As a result, service providers will likely want to provision their servers and internal networks such that the latency is controlled.
[14:39:18] <Randy> Eric: conclusion: from a protocol perspective, the protocol works even if the latencies are excessive
[14:39:32] <Randy> Glenn compares this to Eudora allowing user to hit cancel after 5 minutes
[14:39:41] <Randy> Dave says this doesn't sit well with him
[14:40:29] <Randy> Question if this means we need intermediate responses during command completion
[14:41:03] <Randy> Dave says he thinks this is the wrong model if we are asking users on devices to wait a long time
[14:41:20] <Randy> Glenn says as a service provider he will engineer his system to work in 5 seconds
[14:43:11] <Randy> Pete says our charter is to solve submit without download. We can solve that without dealing with latency
[14:43:42] <Randy> Discussions on latency requirements for protocols
[14:44:35] <Randy> Robb says if he uses IMAP over his cell phone and does an operation that might take a long time, we need to require it to work faster because he is on a cell?
[14:46:25] <Randy> Pete brings up Randy's earlier suggestion that an OK from the BURL submission means everything has completed; if you want to do an asynch response you'll need to do additional protocol work (transactional PULL or perhaps PUSH)
[14:47:33] <Randy> Dave says the purpose of this effort was to not burden the MUA with moving data around; instead we are burdening MUA with delay while someone else moves data around
[14:48:21] <Randy> Glenn notes that this exists today: if you use SMTP on a cell phone today, the client must wait an ~30 minutes
[14:50:26] <Randy> Eric says more modern protocols have "100 working" responses, with timeouts between them, but the sum of them can go on forever
[14:51:31] <Randy> More discussion on need to intermediate responses
[14:51:58] <Randy> Dave says this feels wrong: the MUA goes to the work of building a message, then we ask him to wait while the MSA rebuilds it
[14:52:58] <Randy> Randy notes that the situation is the same with SMTP: the MUA goes to the work of building a message, then it sends it to an SMTP server, which needs to force it to disk, make queue entires etc, then give an OK
[14:55:09] <Randy> Eric says there is an underlying assumption that MUA is slow/constrained, while servers (IMAP and submit) are fast and robust
[14:55:36] <Randy> Randy notes this was the original assumption behind SMTP
[14:56:07] <Randy> Discussion of timeout for BURL. Pete says no need for timeout. Glenn says it should be the same as the DATA command.
[14:56:32] <Randy> Pete notes the existing SMTP timeouts were written for server-to-server, not submit
[14:56:47] <Randy> Eric asks if we can defer the issue of BURL timeout
[14:57:48] <Randy> Eric suggests intermediate responses would solve a problem for submission in generall
[14:58:53] <Randy> Eric suggests this be done in a separate draft as a submission extension
[15:00:19] <Randy> Glenn suggests that we assign a BURL timeout in the meantime, then the new submission extension can be done elsewhere
[15:00:47] <Randy> Randy suggests the intermediate response extension could be done as an individual draft
[15:01:34] <Randy> Conclusion: BURL will be synchronous; it will have a timeout; intermediate response SUBMIT extension can be done as an individual effort (or a new WG)
[15:07:20] <MRCrispin> Mark just got here, but has to go to another meeting in 10 minutes
[15:08:29] <resnick> Hi Mark. We're on 3GPP Liaison issues, but please comment on what you've seen in the Jabber log if you want and I'm sure we can comment on it.
[15:09:39] <Randy> Chairs put up MMS slide and discuss lemonade's role: potential for MM1, potential for an MM3 (MMS-voice mail)
[15:10:00] <MRCrispin> I didn't see anything that stood out, but I only glanced at it. It seems reasonable that BURL be synchronous to start, with possible future extensions for async. Anything else in particular that I should pay attention to?
[15:10:39] <resnick> That was actually the big heartburn for the first hour or so.
[15:11:05] <resnick> I think the room is OK with that conclusion, if with some concerns.
[15:12:40] <MRCrispin> I can understand why; but there is something to be said for "walk before you run." Once we make it work sync, we should be able to do async extensions -- and more importantly, have the luxury of doing it right rather than quick/dirty.
[15:13:02] <resnick> I think we're all on the same page.
[15:15:54] <MRCrispin> Sounds good to me. Seems to me the "send at future time" bird might be killed with the same stone if we're clever enough. Both are cases of "send but without me waiting for it to be sent."
[15:19:07] <MRCrispin> Just as an aside rather than anything else. One of our people here is using the Symbian version of puTTY on his Nokia cell phone to access Pine on a UNIX system to access IMAP. He says that this is faster than the built-in IMAP client on the cell phone. That ought to spur us to do a better job.
[15:19:07] <Glenn Parsons> <really Eric> Mark - good observation on the future delivery / async BURL. Food for thought.
[15:20:04] <Randy> (discussion on MMS architecture and lemonade's role)
[15:20:18] <MRCrispin> [leaving for my other meeting, will keep my Jabbar session running]
[15:20:58] <Glenn Parsons> <really Eric> tnx. cul8r
[15:21:37] <Randy> 3GPP LS: In the situation of WLAN interworking, there are interesting differences from normal cell
[15:21:55] <Randy> They ask if IP-based MM1 would be more appropriate than WAP
[15:22:38] <Randy> The LS notes WAP (OMA) MM1 and IP (lemonade?) based MM1
[15:23:15] <Randy> LS notes insecure nature of WLAN network
[15:23:29] --- resnick has left: Disconnected
[15:25:12] --- resnick has joined
[15:25:12] --- resnick has left
[15:27:36] <Randy> Glenn noted that WAP MM1 uses WAP PUSH; lemonade does not have a push concept
[15:27:46] --- resnick has joined
[15:29:58] --- resnick has left: Disconnected
[15:30:04] <Randy> Randy noted that M-IMAP does not have push
[15:30:27] <Randy> Randy noted that in some cases independent pushes was worse than periodic coordinated polling
[15:30:48] <Randy> Glenn said that was only true pre-Rel6 (all-IP)
[15:32:16] --- resnick has joined
[15:32:32] <Randy> Randy noted that you can achieve push by having long-lived TCP connection to IMAP server and using IDLE command; the IP address can be retained even if the traffic channel is not up (dormancy mode)
[15:40:39] --- Jean Sini has left
[15:40:39] --- Jean Sini has joined
[15:42:35] <Randy> Specific questions in LS. (1) Status: we can give status of our work. (2) WLAN EU send/receive MMS via WLAN interworking: our protocol requires only IP connectivity; differences between WAP and IP: mention security/authentication/encryption
[15:42:37] * resnick 's eyes glaze-over and decides it's better for his mental health to ignore this section of the discussion.
[15:48:56] <Randy> (3) forsee any work and timescale: they may want to consider adding our protocol as an MM1 in their specifications; timeline we will supply
[15:49:38] <Randy> (4) use of protocols over insecure network: see (2) -- our protocol is designed for use over insecure networks
[15:50:50] <Randy> For Pete's benefit, the chairs page through the ~80 page 3GPP document on WLAN interworking
[15:51:57] <Randy> Comment that we might want to think about the roaming case, where you switch access networks while a session in active
[15:52:14] <Randy> Comment: 802.21 covers this
[15:52:36] <Randy> Comment: may want to assume that worst case the connection is dropped and the client will reconnect
[15:53:15] <Randy> Comment: therefore notifications etc may be lost
[15:54:14] <Randy> Discussion about UE IP address changing
[15:55:50] <Randy> Comments about HIP, P-IMAP; session layer on top of changing IP address
[15:56:20] <Randy> Comments on VPN tunnel on top of changing IP address
[15:57:23] <Randy> Comment: as long as we handle the case where some data from server to client gets lost, we are OK
[15:57:40] <Randy> Comments that we need to reduce the cost of reconnecting
[15:59:56] <Randy> Stephane: we can't assume that IP addresses stay around
[16:00:51] <Randy> Glenn: servers use TCP keep-alives to know when clients go away; we need to note that they shouldn't do that
[16:01:04] <Randy> Pete: We can't have lemonade get into transport
[16:04:40] <Randy> Randy suggests we can include advice that servers not use TCP keep-alives, at least until HIP/etc. is done
[16:05:23] <Randy> Randy suggests that include a note that if TCP keep-alives are used, certain cases won't work
[16:05:44] <Randy> Pete suggests we tell PPs not to change the UE IP addresses
[16:07:05] <Randy> Suggestions that for the purpose of a response to this LS we don't need to talk about IP addresses, long-lived connecions, etc.
[16:11:15] --- Jean Sini has left
[16:12:08] <Glenn Parsons> Another lemonade break....
[16:19:09] <Glenn Parsons> FYI, the Pull diagram we discussed earlier and have agreed as a basis is posted here: http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/Lemonade_discussions_sm.ppt
[16:24:05] <Randy> P-IMAP overview presented by Stéphane Maes
[16:25:42] <Randy> Stéphane: mobile email: end-to-end secure, quasi real time prop. email events
[16:26:05] --- Jean Sini has joined
[16:26:37] <Randy> bandwith opt; lower overhead than SyncML; less chatty than IMAP; use compression to save bandwidth; group commands to reduce round-trips
[16:27:11] <Randy> adjust message flows based on network bearer
[16:27:24] <Randy> extend msg delib so no need for SMTP
[16:27:42] <Randy> interfaces with and interops with IMAP msg store
[16:27:59] <Randy> support generic event-based synch (can contain PIM events)
[16:28:07] <Randy> (above is from slides)
[16:29:19] <Randy> Stéphan: this has been deployed; there are several client companies that have been involved; at least two have deployed protototypes demoed at GSM world
[16:31:08] <Randy> StÈphan: P-IMP "macros" are fewer than M-IMAP; M-IMAP has a lot that are there for MM1 needs; not needed for email
[16:33:18] <Randy> Stéphan: also have it working with Exchange servers and POP servers and are working on Domino/Notes server
[16:34:43] <Randy> Stéphan: SyncML is server-driven; P-IMAP, like IMAP, is client-driven
[16:35:07] <Randy> Stéphan discusses use cases
[16:46:40] <Randy> Discussion on security constraints for corporate email vs IM, voice, etc.
[16:47:53] <Randy> Glenn asks which entity signs the message: the IMAP server or the submit server
[16:49:49] <Randy> Discussion on need to entrust IMAP or submit server with user's private key to be able to sign the message
[16:49:55] <Randy> Stéphan continues
[16:56:26] <Randy> Stéphan: high level requirements: push email experience/quasi-instant. synch; manage bi-direct event sync; manage msgs/folders
[16:56:29] <Randy> offline usage
[16:56:36] <Randy> (missed rest)
[16:56:46] <Randy> Stéphan: protocol highlights:
[16:57:16] <Randy> extension commands allow clients to set notification mode and device address: XSETIMAPPREF/XGETIMAPPREF
[16:57:29] <Randy> set view and notification filters: XFILTER
[16:57:35] <Randy> send out messages: XDELIVER
[16:57:54] <Randy> exchange compression capabilities: leverage compression to save bandwidth
[16:58:09] <Randy> encryption: XENCRYPTED (payload encruption)
[16:58:33] <Randy> combine often-used groups of commands into macros; group commands to reduce round-trips
[16:59:23] <Randy> support for various bindings to underlying protocols (P-IMAP over HTTPS [mandatory]; PIMAP over TCP; other networks
[17:00:15] <Randy> support for multiple notification mechanisms -- based on OMA-EN; supports in-band notifications (e.g., within HTTP or TCP bindings) and out-of-band notifications (e.g., SMS, WAP PUSH)
[17:00:28] <Randy> (above are from StÈphane's slides)
[17:02:46] --- Jean Sini has left
[17:02:52] <Randy> discussion that using HTTP "because it goes through firewalls" is harmful, since protocols get deployed and initially work, then virus writers take advantage of the new vectors, and firewall vendors respond by looking deeper into packets and mucking things up; as a result, everything breaks
[17:04:06] <Randy> Stéphan: protocol highlights
[17:04:57] <Randy> Stéphan: PIMAP flows
[17:05:21] <Randy> keep-alive HTTP binding; in-band notifications
[17:07:25] --- Jean has joined
[17:08:18] <Randy> Glenn discusses situation where a BREW application has a session but a call comes in which in current implementations terminates the data session
[17:08:27] <Randy> Client needs to reconnect
[17:08:42] <Randy> Stéphan says this is what P-IMAP addresses
[17:09:33] <Randy> BREW client should be able suspend instead of terminate
[17:13:21] <Randy> Stéphan: future work on P-IMAP
[17:13:46] <Randy> Stéphan: proposal for next steps at lemonade: start with p-imap, maybe discard HTTP
[17:14:29] <Randy> Stéphan: OMA MWG (which also has MMS group) is starting a WI on mobile email
[17:18:56] <Randy> Randy mentions "meta negotiation" concept whereby a set of meta extensions could be created, each of which would stand for multiple IMAP extensions; meta-extensions could not themselves change IMAP behavor, so a profile which changes IMAP behavor could need both a regular extension and a meta extensions
[17:21:44] <Randy> Dave: I am a device with a slow link and I want to use IMAP in this way; I am a device on a fast network and I want to use IMAP in this other way; the meta-negotiation is targeted at this?
[17:21:46] <Randy> Randy: yes
[17:22:51] <Randy> Glenn: I want to be able to verify the product against a set of options instead of against each option in combination with each other
[17:24:47] <Randy> Eric: what is the value of meta extension mechanism unless negotiating extensions is itself expensive?
[17:26:08] --- Jean has left
[17:26:25] --- Jean has joined
[17:26:36] --- resnick has left: Disconnected
[17:28:31] --- resnick has joined
[17:28:59] <Randy> (digression into OSI)
[17:29:51] <Randy> Suggestions that we not use the word "profile" because of bad connotations; Randy suggests "silhouette"
[17:30:02] <Randy> Chairs: let's split the document up
[17:31:13] <Randy> [oops! I think I've been using "Glenn" for Greg, and "Greg" for Glenn's comments. Read above with this in mind]
[17:31:23] <Randy> [Slips of the fingers]
[17:37:24] <Randy> Glenn: proposes split p-imap document into several documents, and suggests: a goals document (into existing goals document), profile (into a new document), new IMAP commands (will need to look at each, maybe one document each, maybe one per), notifications (into separate notifications work)
[17:38:09] <Randy> Glenn: also use of HTTP is a separate discussion
[17:39:09] <Randy> Glenn: issue of how many notification protocols to define (e.g., SIP, SNAP, etc.)
[17:41:49] <Randy> Glenn: tomorrow we will go over document map and reconfirm them and their editors
[17:44:55] --- smaes has left
[17:47:27] <Glenn Parsons> We will reconvene at 8:30am central tomorrow morning.
[17:47:46] --- Jean has left
[17:48:25] <corby> hi
[17:50:13] --- Glenn Parsons has left: Disconnected
[17:50:29] <Randy> (break for the day)
[17:50:37] --- Randy has left: Disconnected
[17:53:21] --- resnick has left: Disconnected
[18:13:00] --- corby has left: Disconnected
[18:35:04] --- resnick has joined
[19:34:09] --- resnick has left: Disconnected
[22:18:35] --- resnick has joined