[08:13:19] --- resnick has left: Disconnected
[08:15:15] --- Glenn Parsons has joined
[08:25:08] --- Glenn Parsons has left: Replaced by new connection
[08:25:26] --- Glenn Parsons has joined
[08:27:24] <Glenn Parsons> We'll be starting again in about 5 minutes
[08:33:48] --- resnick has joined
[08:44:31] --- Randy has joined
[08:50:15] <alexeymelnikov> Can I ask a question about P-IMAP discussion that I've missed yesterday
[08:50:15] <Randy> (Friday morning)
[08:52:04] <Randy> (Discussion of reply LSs)
[08:54:37] <Randy> Discussion clarified that there are two LSs: one to 3GPP in response to their LS; which will inform 3GPP of our work on protocols suitable for MM1 in an insecure environment. The second is to OMA and is not in reply to anything; it is a new LS just to inform MWG that we are working on optimizing email protocols for the mobile environment
[09:05:18] --- corby has joined
[09:08:03] <Randy> Discussion on specifics of LS wording
[09:10:11] <Randy> Chairs to tweak wording of reply LS to 3GPP, then post to the list, and determine how to properly send a LS
[09:10:33] <Randy> Alexey: go ahead
[09:13:11] <Randy> Discussion on restrictions on BURL: initially limit to fetching whole message, and limit to one BURL per message
[09:14:04] --- corby has left
[09:15:19] <Randy> Discussion of this issue
[09:16:48] --- smaes has joined
[09:16:55] <Randy> Reiteration that locking went away in favor of BURL being synchronous
[09:17:13] <alexeymelnikov> My question is how compression in P-IMAP is achieved? (I am sorry, I didn't have time to read the document) Is it just using macro-commands, or is it compression layer negotiation in IMAP?
[09:17:46] <Randy> Failure mode is now deterministic: if client A uses CATENATE and BURL, and at the same time client B deletes the CATENATEd message, client A gets an error on the BURL
[09:18:16] --- corby has joined
[09:19:36] <Randy> Discussion on message flows
[09:21:09] <Randy> Eric mentions a Java utility called "CallPlot" that draws fencepost calls
[09:21:42] <Randy> Alexey: My question was how compression in P-IMAP was achieved? (I am sorry, I didn't have time to read the document) Is it just using macro-commands, or is it compression layer negotiation in IMAP?
[09:22:27] <Randy> Stéphan: macros reduce chattiness; message can be compressed with gzip on request (flag on command)
[09:24:06] <Randy> Chairs: Pull Documents: forward without download profile: Randall Gellens: draft-ietf-lemonade-imap-submit-01
[09:24:25] <Randy> Chairs: BURL: Chris Newman: draft-newman-lemonade-burl-00
[09:24:46] <Randy> Chairs: CATENATE: Pete Resnick: draft-ietf-lemonade-catenate-01
[09:25:07] <Randy> Chairs: URLAUTH: Mark Crispin? draft-crispin-imap-urlauth-06
[09:25:30] <Randy> Question: keep forward-without-download as its own draft or fold into lemonade IMAP profile
[09:27:01] <Randy> Decision: forward-without-download draft; text goes to Goals and lemonade profile
[09:27:55] <Randy> Question: do we need the three documents BURL, CATENATE, URLAUTH?
[09:28:03] <Randy> Also need profile as normative document
[09:28:04] <alexeymelnikov> Regarding compression: TLS compression is now an RFC - RFC 3749, it is cleaner to use TLS
[09:28:27] <alexeymelnikov> I think having 3 separate documents is fine
[09:28:48] <alexeymelnikov> ... because they can be used separately and outside of Lemonade
[09:29:36] <Randy> (Randy reads Alexey's comments; room agrees)
[09:30:35] <Randy> Discussion on Chris and Mark as authors
[09:32:47] <Randy> Greg White volunteers to be author of BURL
[09:32:58] <Randy> Randall Gellens volunteers to be author of URLAUTH
[09:33:25] <alexeymelnikov> I am willing to co-edit one of the documents
[09:33:51] <Randy> Alexey is given URLAUTH
[09:34:38] <Randy> Chairs: Lemonade Profile
[09:35:56] <Randy> Profile: StÈphan Maes: lemonade client & server functionality description; supported IMAP commands and extensions; user cases
[09:37:03] <alexeymelnikov> I am willing to help out with user cases, as I am already doing document regarding disconnected use.
[09:37:13] <Randy> excellent
[09:38:02] <Randy> Alexey is co-editor on URLAUTH and Profile
[09:38:57] <Randy> Discussion on IMAP commands in Profile: URLAUTH, CATENATE, STARTTLS (compression [sigcomp?])
[09:39:04] <Randy> Discussion on need for macros
[09:40:53] <Randy> IMAP commands in Profile: reduce round-trips with pipeline instead of macros
[09:41:54] <Randy> Discussion on need for consideration of disconnection; perhaps a mechanism for quick reconnect in environment prone to unexpected disconnects
[09:42:34] <Randy> e.g., require server to keep state for some amount of time after client disconnects
[09:43:43] <alexeymelnikov> Regarding the last point: I was thinking about fast reauthentication recently. This is related to SASL, but can be mentioned as well
[09:44:52] <Randy> Comment that mechanisms being looked at for disconnected operation may help this problem;
[09:47:19] <Randy> Chairs: Lemonade Profile drafts; documents for new commands?
[09:47:58] <resnick> It was pointed out to me that this isn't clear in the Jabber log: I mentioned that Chris has said he was over-committed and therefore should be asked about continued editing of BURL. Greg volunteered to take it on if Chris can't continue. Chairs will check with Chris.
[09:48:14] <Randy> message context: header to indicate focus of msg is voice, etc.
[09:48:31] <resnick> Also, chairs said that Mark wants out of URLAUTH, so Alexey and Randy volunteered to take it up.
[09:48:49] <resnick> (Just so it's clear in the log.)
[09:49:00] <alexeymelnikov> IMHO, the profile doc should just reference other documents which define IMAP extensions, etc.
[09:49:56] <Randy> chairs also noted that Chris Newman is welcome to continue as editor of BURL but if he is too busy we have Greg White
[09:50:32] <Randy> (Randy reads Alexey's two comments; the room agrees)
[09:52:00] <Randy> Need author for msg context draft; Greg wants a flag or annotation to, e.g., light MWI
[09:53:15] <Randy> Discussion: message-context exists; to learn of it, the client needs to ask for it when fetching information about the message; Greg wants it returned in a list of messages (so an appropriate icon can be displayed, etc.)
[09:53:46] <alexeymelnikov> I was writing something regarding flags that are set automatically on delivery based on some headers
[09:54:04] <Randy> Dave suggests there is likely a list of things a device needs to know in order to operate effeciently, and message context may be only one of them
[09:55:01] <Randy> Dave: need to provide limited client information it needs to decide how to operate on a message
[09:55:42] <Randy> Pete: requirement is to provide this information at the right time and with the right amount of work for the client
[09:56:01] <Randy> Dave: we need to specify what things need to be optimized; message context is one such thing, what are the others?
[09:57:04] <Randy> Discussion that the information needs to be available in the FETCH response; not convinced that ANNOTATE is the right way, but it seems appealing
[09:57:39] <Randy> Pete: the client can get back annotations in FETCH response; need draft in how to do this
[09:59:14] <Randy> Randy: need small draft to state that if the server adheres to this, it will set an annotation for a message context
[09:59:57] <Randy> Greg volunteers to write draft but expresses need for significant IMAP help by email
[10:01:09] <Randy> Chairs talk Corbi into being editor of quick reconnect draft
[10:01:18] <Randy> (Corby Wilson)
[10:02:03] <Randy> (break for lemonade)
[10:06:39] <Randy> (we're back)
[10:06:47] <Randy> Discussion on notifications draft
[10:08:17] <Randy> We have requirements for server-server notifications (Gev Decktor); need fresh rev and WG review
[10:10:02] <Randy> Randy suggests that server-client notifications and server-server were different and needed separate drafts
[10:10:07] <Randy> Dave asks what the difference is
[10:10:28] <Randy> Stéphan suggests the events are different
[10:11:19] <Randy> Randy suggests the difference is that server-server assumes connectivity; sever-client assumes intermittent connectivity
[10:11:48] <Randy> Randy suggests if the difference is only the specific events, then they are the same
[10:12:39] <Randy> Discussion on use of WAP Email Notification
[10:14:44] <Randy> Discussion on server-client notification work, Eric suggests it may take two years to get a document
[10:15:43] <Randy> Dave suggests that in server-client should come first, since it is visible and tends to pull work along; doing server-server first usually means the work doesn't get done
[10:16:13] <Randy> Dave suggests that server-client needs to be done in a very easy way so that "any idiot can implement it" and then we can move on
[10:16:55] <Randy> Eric (not as chair) suggests that IETF momentum and mind share makes it unlikely that anything other than SIP would get adopted
[10:17:22] <Randy> Eric suggests that server-server was not well-suited to SIP
[10:18:21] <Randy> Stéphan suggests we do server-client notifications in two layers, one that is independent of transport, and then we bind it to SMS or SIP or whatever
[10:19:02] <Randy> Discussion on if we need to work on server-client
[10:19:25] <Randy> Pete says when we did the charter we needed to avoid server-client
[10:19:52] <Randy> Randy suggests the requirement is actually on user experience of email; notifications may or may not be needed
[10:20:08] <Randy> Stéphan says we need a notification mjechanism
[10:23:03] <Randy> Stéphan suggests we need event notifications
[10:23:40] <Randy> Randy suggests that the real issue is latency between when new mail arrives and when the client learns of it
[10:24:54] <Randy> Randy suggests that there are a number of ways this can be addressed; that in some cases controlled, coordinated polling is more effecient on the client and the network than bursts of notifications; that if we need events they too would need to be throttled somewhere
[10:25:09] <Randy> Greg says on 2.5G networks SMS push is needed
[10:25:17] <Randy> Pete says SMS is not an IP protocol
[10:25:50] <Randy> Discussion on need to explicitly support non-IP users
[10:26:53] <Randy> StÈphan suggests we follow Randy's suggestion and present the requirement for near-instantanteous email, not server-client protocol
[10:27:33] <Randy> Eric suggests we need a requirements document and then see if we need to do something, if we can ask another group that is working on something similar to take it on
[10:29:43] <Randy> Corby notes that from phone mfgr point of view, SMS is on the way out, it will likely be SIP (or maybe something else) in the future. What is needed is an IP-based solution that works in absense of IDLE; problem with IDLE is that pricing prohibits it
[10:30:52] <Randy> Corby suggests that operators won't permit long-lived idle connections, that always-on (even with dormancy) is too expensive since PPP state, IP addresses, etc. need to be consumed
[10:31:23] <Randy> Dave suggests that this is not a good candidate for standardization in the IETF, that this be done by private people, vetted by IETF people, but not specified within the IETF
[10:32:20] <Randy> Stéphan says when they did P-IMAP they also came to the conclusion that IDLE was not suitable for many cases
[10:35:05] <Randy> Stéphan volunteers to work on server-client notifications requirement drafts
[10:35:58] <Randy> Eric suggests that the draft start as an individual submission, then if there is sufficient interest it could be a WG document later
[10:36:17] <Randy> (for now, it is individual informational)
[10:36:36] <Randy> Alexey volunteers to co-author quick-reconnect
[10:38:06] <Randy> Chairs note that server-to-client is not currently in charter
[10:38:56] <Randy> Discussion that server-client requirement is that there be gateways to allow an IP-based server to notify an non-IP client that email has arrived
[10:39:32] <Randy> Dave suggests this is a self-contained effort to enhance user-side Internet mail service
[10:41:34] <Randy> Oops: the discussion was actually on server-server
[10:41:54] <Randy> Eric suggests that those who want it taken out of the charter take it up wth the IESG
[10:43:16] <Randy> Chairs: imminent candidates for WGLC: lemonade goals draft: Kue Wong: draft-ietf-lemonade-goals-02; new revision, incorporate p-imap requirements and forward without download; nits review, then WGLC
[10:44:02] <Randy> Chairs: imminent candidates for WGLC: media size: Vladimir Shveidel: draft-sheidel-mediasize-06; not a WG document but peer review in group
[10:44:32] <Randy> Chairs: random bits: Channel: Lyndon Nerenberg? draft-ietf-lemonade-imap-channel-01; was on hold for resources
[10:45:23] <Randy> Channel allows streaming of media, also allows content adaptation
[10:45:52] <Randy> Suggestions that Channel needs revision to use URLAUTH
[10:47:01] <Randy> Future-delivery: Greg Vaudreuil: draft-vaudreuil-futuredelivery-02; was on hold for pull/push decision
[10:48:53] <Randy> Greg V and Greg White volunteer for future delivery draft
[10:50:22] <Randy> MMS mapping: Randall Gellens: draft-gellens-lemonade-mms-mapping-00;
[10:50:38] <Randy> New version needed for future delivery? Make WG document?
[10:51:48] <Randy> now wg document
[10:51:59] <Randy> (last two lines were for future delivery)
[10:52:20] --- resnick has left: Disconnected
[10:52:46] <Randy> MMS mapping: revise before San Diego (already is WG document)
[10:53:47] <Randy> Chairs: new drafts needed before San Diego: 7/12 for -00 and 7/19 for -xx
[10:54:02] <Randy> Chairs: review open issues in documents in San Diego
[10:54:32] <Randy> Chairs: revise docs after SD if needed; WGLC after SD; revisions before IETF 61; IESG submission after IETF 61
[10:54:54] <Randy> Greg suggests chairs send weekly email to list of open items
[10:55:11] --- resnick has joined
[10:57:52] --- resnick has left: Disconnected
[10:58:22] <Randy> (closing up)
[10:58:28] <Randy> Adjourned
[10:58:41] --- Randy has left: Disconnected
[10:58:50] <Glenn Parsons> We are done.
[10:59:08] <Glenn Parsons> Slides from today will be posted shortly to our web: http://flyingfox.snowshore.com/i-d/lemonade/slides59-5/
[11:02:08] --- smaes has left
[11:18:02] --- kmurchison has left
[11:23:34] --- corby has left: Disconnected
[11:32:26] --- Glenn Parsons has left: Disconnected
[12:34:28] --- alexeymelnikov has left
[16:08:43] --- MRCrispin has left