Logs for lemonade@ietf.xmpp.org, 2004-11-08[09:45:13] --- amelnikov has joined [10:58:00] --- kmurchison has joined [11:18:00] --- smaes has joined [11:18:18] --- smaes has left [11:56:58] --- Glenn Parsons has joined [12:00:56] We are just about to begin... [12:01:55] --- smaes has joined [12:02:41] --- smaes has left [12:02:41] --- smaes has joined [12:03:03] --- smaes has left [12:03:03] --- randy has joined [12:03:18] --- ludomp has joined [12:03:21] --- corby has joined [12:03:44] Tony will take mintues today. [12:03:52] --- lisa has joined [12:03:53] --- resnick has joined [12:03:57] --- hardie has joined [12:04:24] --- tonyhansen has joined [12:04:32] --- kuewong has joined [12:04:34] and we're off [12:04:57] agenda was modified to accommodate those who could be here on monday, not on wed, and vice versa [12:05:29] --- cnewman has joined [12:06:09] today: mms mapping, future deliv, urlauth, burl, catenate, quick reconect; nonWG: mobile sync, clearidle, message filter [12:06:28] bash: pease move quick reconnect to wed [12:07:00] wed agenda: Mon recap, profile & goals, quick reconnect, transcoding discussion (channel) [12:07:14] sold [12:07:18] status update: [12:08:27] charter review: goals, imap ext for vm playback, submit extensions for forwarding, exts for diverse endpoints, server to server notif. protocol (not server to client), translation to/from other messaging systems [12:08:38] summary of deliverables [12:08:51] Ted: have you decided with Scott who is handling the Last Call for draft-melnikov-imap-disc-06.txt? [12:10:20] recap of interim meeting in vancouver [12:11:54] objectives: various drafts have moved forward, and some gone to LC, hopefully rest to WGLC before next ietf [12:13:04] WGLC status: server to server notif reqts: closed; mms mapping: issues to be resolved; future delivery: discussed today; goals: discussed on Wed [12:13:33] randy gellens: mms/email mapping [12:14:15] 01 includes explicit vpim support vs. 00 [12:15:22] open issue: specifies the use of presence: Bulk header; do we need it? Do we keep it? Standardize it? [12:16:50] precedence: bulk [12:17:03] Thankas [12:17:10] oops [12:18:31] --- resnick has left: Disconnected [12:19:16] discussion pro & con, mild support both ways [12:19:38] --- resnick has joined [12:20:38] resolution: remove it [12:21:18] open issue #2: sender address hiding using x-anonymous extension to MAIL FROM [12:22:53] support for standardizing the anon facility separately [12:23:58] resolution: remove it, for possible future standarization [12:24:37] Greg Vaudreuil: future delivery [12:24:57] issues: 1*9digit; resolution leave it [12:24:57] correction: resolution of 'precedence: bulk' was to leave it since it is in the registry [12:25:17] --- Sam has joined [12:25:51] issue #2: auth reqt is redundant [12:27:56] resolution: leave it to smtp-submit to move forward and remove from this doc, change smtp-submit reference to new doc (currently in queues) [12:28:12] issue #3: fix reference to rfc 2119 language [12:28:32] issue #4: is there a minimum futuredeliver time? does the server need to announce it? [12:29:26] no, doesn't add any real value [12:29:41] FYI, the presentations are on the supplementary server [12:29:46] http://flyingfox.snowshore.com/i-d/lemonade/slides61/index.html [12:29:57] But note the agenda on this page is worng :-) [12:30:16] issue #6: add DOS wording to security reqts. Chris Newman is voluteering to review it closely [12:30:35] issue #5: odd cases in max delivery interval; 0, 9999999999 [12:31:12] resoltion: require the advertisement [12:31:23] why require advertisement? [12:31:28] various nits [12:34:40] new drafts for mms and future delivery will come out soon (next week) [12:34:59] chris newman: urlauth, burl, catenate [12:35:13] --- smaes has joined [12:36:30] is urlauth ready for wglc? no, there were some comments on the list that haven't yet been resolved [12:37:03] plus the "anonymous" issue [12:37:34] burl: issue: need a rev for reference updates [12:37:45] then last call [12:38:29] glenn to ted: any issues on urlauth? there has been a draft since his comments were sent [12:38:48] glenn will ping mark [12:38:54] pete resnick: catenate [12:39:17] needs examples, plus something on what to do with response codes [12:39:39] amelnikov: Just saw your question in reviewing the discussion--it's in my queue [12:40:28] Ted: ok, thanks [12:40:39] 2119 language? pete says 2119 language isn't necessarily needed [12:41:40] randy & chris: need it for interop [12:42:56] I agree with Randy & Chris [12:45:26] discussion on i18n problems with text [12:45:31] chris -- fine as is [12:46:12] on to examples: how to deal w/ drafts? other use cases [12:46:59] clarification to pete on what examples go in catenate vs. profile doc [12:49:49] greg: why do we have catenate at all? don't urlauth and burl cover it? [12:51:10] chris: catenate allows you to put copy into sent folder and send it [12:51:42] pete: different algorithms if you have annotations, and don't [12:52:16] Catenate also allows to strip attachements and edit a draft multiple times [12:52:18] chris: forward without download as well as saving file copy [12:52:49] greg: two ways to do same thing? bothers him. catenate using burl, vs. bdat, bdat, burl [12:53:16] chris/pete: lemonade will require catenate, but not bdat [12:53:33] greg: figured bdat WOULD be required [12:55:02] chris/randy: yes, there will be more than one way to do the same thing [12:55:48] philip g.: another complexity is alexey's draft to request email address for a particular folder [12:56:14] someone: missed it [12:56:50] pete: wordsmithing [12:58:29] greg: what's preferred way to do fcc? catenate with burl? [12:58:33] chris: yes [12:59:30] greg: if do future delivery submission, is burl resolved now or then? [12:59:32] chris: then [13:01:27] pete: will go back to editing for next draft [13:01:43] Chris: why not resolve at the time of submission? [13:02:05] pete: call for examples to provide for the doc [13:02:32] --- patcain00 has joined [13:03:04] I can write some examples for Pete [13:03:16] Actually, I said the URL was resolved before the submit server sends an error response. [13:03:23] send them to pete [13:04:24] pete: profile will say: here's how to use catenate to forward w/o download. and that use of annotation would make forward w/o download more efficient, but it is not required by the profile, and may describe how to do so. [13:04:51] sub use case of editing drafts can be made more efficient with annotations [13:05:15] --- patcain00 has left [13:05:22] next: non-work group items [13:05:57] michael wener: checkpoint/clearidle [13:06:00] Thanks alexey. [13:06:52] goal: provide quasi-real-time reception of server state change; minimize client costs of full sync; minimize protocol changes; obviates RECONNECT, and server-to-client-notifications [13:07:53] current drafts don't provide clear description on how to use two together -- need both, and how play together could part of lemonade profile [13:08:43] checkpoint: ack'd delivery of imap responses, extends idle, subsumes reconnect [13:08:59] I disagree client to server notification requirements far from being all satisfied by this [13:09:21] + IDLE may have issue that requires further discussion [13:09:23] resync avoidance: avoid missed events; uses account based queuing [13:10:07] Stephane: Can you form a specific question or comment I can channel to Mike? [13:10:11] defines a 2-session access scenario for imap client; sessions are mutually aware [13:10:46] uses imapurl to export uid state between sessions [13:11:40] Not really from here. it's a comment that at this stage I do not see / agree that it minimize client costs (if disconnected then reconnects), nor does it oviate reconnect and definitively not S2C notifications. [13:11:46] checkpoint: supports both highly connected & lightly connected [13:12:23] idle context is a way of scoping both: queue life (queue is self cleaning) & responses w/ new syntax [13:13:39] pete: questions where costs of connection are? mike: both tcp level and tls level [13:15:27] randy: questions highly vs. lightly connectedness. mike: means how often have active connection [13:17:38] clearidle: provide unsolicited responses during IDLE (when in auth state) -- uses IMAPURL used to identify folders & uids -- allows multiple folders to be reviewed covers all state change need to avoid a full sync at reconnect -- all folders, folder state, mail state, expunges [13:18:20] --- dbrashear has joined [13:18:41] the two combined improves mobile mail experience: checkpoing/clearidle: user perceived smoothing of mail reception; msgfilter: focusing on what mail is of interest to user [13:18:48] --- dbrashear has left: Disconnected [13:19:47] cyrus: can you limit updates to "folders of interest"? [13:20:45] mike: it's a problem with no magic wand, can use aggregation -- needs some work [13:22:01] discussion genericizing to general server-to-client notification [13:22:19] comments about xmpp doing it, reference to jep #60 [13:23:52] clamor [13:25:29] When is s2c discussed? Wednesday no? [13:25:41] eric: discussion of inband vs. out-of-band models; sip vs. xmpp; imap was not built to do it; we should use the right kind of connection to do notification and not mix it in to imap [13:26:34] dave crocker: notification has 2 pieces -- object and transfer -- we need to speicify the objec to be sent and now how it's sent [13:27:10] glen: we want reqts of what needs to be transfered from server to client [13:27:27] mike: clearidle specifies content [13:28:05] s2c requirements [13:28:19] P-IMAP uses notification only as a wakeup [13:28:42] greg: still interested specifically in imapish events since last connect or checkpoint [13:28:56] leaving clientto decide if wants to use any additional info in notificatioon for other purpose [13:29:24] wakeup is all what is needed [13:29:34] on to msgfilter [13:29:58] goal is to constrain what events are seen [13:30:15] or, what messages are seen [13:30:44] use case #1: mail after a certain date; #2 only mail from *@customer.com [13:31:43] some syntax borrowed from old window/view drafts [13:32:13] command: FILTER SET; response: FILTER SET; response code: FILTERED [13:33:48] --- corby has left: Disconnected [13:33:57] transient mode: specify criteria via SEARCH, UID ADD/REMOVE; easy cleanup: self cleaning; filters are definitive [13:34:42] non-transient mode: protocol opaque tag [13:36:04] filters build dynamically (incrementally); rules have precedence TAG, SEARCH, UID ADD/REMOVE [13:37:18] cyrus: window had scalability problems [13:37:35] mike: same scalability problems as search command [13:39:11] cyrus: serious problems with redefining sequence numbers on the fly [13:40:32] To Cyrus: Sequence numbers are not redefined in MSGFILTER [13:40:36] mike: burden of maintaining state borne by server, but mitigated by trancience [13:41:14] alexey: example shown on screen shows sequence numbers being redefined [13:42:16] Is filter transient or persistent across session? [13:42:17] --- dbrashear has joined [13:42:27] transient [13:42:40] Tony: it wasn't clear from the draft [13:43:54] corby: what happens with collected state changes with msgfilter vis-a-vis checkpoint [13:44:01] mike: a problem [13:44:04] I don't see understand the use cases with transient only filters. The value of such type of command in my view should be to have mailbox defined on server and changed persistently via command from client [13:44:13] eric: what's next [13:44:27] --- corby has joined [13:44:46] updated drafts by december 1 (profile, reconnect); wglc for pull trio [13:45:13] we're done for the day -- to be continued on wednesday [13:45:14] --- hardie has left [13:45:25] --- ludomp has left [13:46:20] --- tonyhansen has left [13:46:41] --- corby has left [13:48:08] --- resnick has left: Disconnected [13:48:08] --- resnick has joined [13:48:08] --- resnick has left: Lost connection [13:49:00] --- lisa has left: Disconnected [13:51:42] --- Glenn Parsons has left: Disconnected [13:59:52] --- resnick has joined [14:00:06] --- resnick has left [14:03:48] --- Sam has left: Disconnected [14:05:51] --- amelnikov has left [14:06:06] --- lisa has joined [14:06:15] --- lisa has left [14:19:50] --- cnewman has left: Disconnected [14:29:47] --- Sam has joined [14:36:19] --- Sam has left [14:47:06] --- kuewong has left: Disconnected [15:05:47] --- kmurchison has left [15:44:29] --- randy has left [19:10:52] --- dbrashear has left: Disconnected [22:25:03] --- smaes has left: Disconnected