|
lemonade interim meeting minutes
Thanks to all who participated (both in person and via jabber) in our interim meeting in Richardson this week. I think it was a very productive meeting that puts us in the position to get documents out shortly (in the next month) on all our charter items and complete our work by the end of the year. Our intent is to review these new documents before the San Diego IETF 60 meeting so that we may discuss any issues with them at this meeting. We anticipate a WG last call on most of the documents after this meeting. After review and revisions this would allow progression to the IESG around IETF 61. A quick summary of the notable meeting results: Goals document will be augmented with profile and forward without download material Confirmed pull variant BURL/CATENATE/URLAUTH as mechanism that will be documented for the forward without download issue Drafted liaisons to 3GPP and OMA (these will be sent to the list in separate messages) Confirmed content of lemonade profile to be server & client functionality, list of IMAP commands and use cases Future delivery was agreed as a WG item S2S notification requirements is in charter and ready to progress, S2C notification requirements is not in charter but we will review an individual I-D on this topic. Details can be from the jabber logs: [13:02:10] <stpeter> <-- scribe [13:02:31] <stpeter> <lemonade_wg_meeting> [13:02:37] <hildjj> ?? log [13:02:41] <hildjj> ?? logs [13:02:43] <stpeter> agenda sent to mailing list [13:03:19] <stpeter> goals, mms mapping, imap4 extensions, imap4 profile, imap4 channel, s2s notifications, next steps & milestones [13:05:06] <stpeter> s/imap4 extensions/extensions/ [13:05:40] <stpeter> 3 extensions: imap push/pull, url auth, imap compose [13:07:12] <stpeter> charter review [13:07:40] <stpeter> lemonade goals, imap4 extensions for VM4 playback, diverse enpoints [13:07:48] <stpeter> imap4 profile for diverse endpoints [13:07:54] <stpeter> s2s notification protocol [13:08:01] <stpeter> translation to and from other messaging systems [13:08:18] <stpeter> this is only a summary of the actual charter [13:08:39] <stpeter> which is here: http://www.ietf.org/html.charters/lemonade-charter.html [13:08:49] <stpeter> requirements draft [13:08:57] <stpeter> (Kue Wong) [13:09:05] <stpeter> draft-ietf-lemonade-goals-01 [13:09:40] <stpeter> consensus that we should focus on requirements in the charter instead? [13:10:14] <stpeter> keep this doc as informational document so folks can understand goals and objectives of the WG [13:10:21] <stpeter> changes.... [13:10:31] <stpeter> de-emphasize requirements aspect [13:10:36] <stpeter> since reqs are in WG charter [13:10:51] <stpeter> more focus on context and motivation [13:11:03] <stpeter> document thinking behind lemonade design process, etc. [13:11:34] <stpeter> use cases giving rise to functionality, plus collection of suggested approaches for solutions [13:12:05] <stpeter> keep descriptive background textg [13:12:29] <stpeter> no comments on changes to that I-D [13:12:48] <stpeter> next: MMS Mapping [13:13:03] <stpeter> (Randy Gellens) [13:14:26] <stpeter> /draft-gellens-lemonade-mms-mapping-00, that is [13:15:35] <stpeter> this I-D has been accepted as a WG document [13:15:41] <stpeter> updated version pending, not submitted yet [13:16:11] <stpeter> difference: details on how to map MMS world to email world, new version should show up shortly [13:16:24] <stpeter> (delivery and disposition details) [13:16:40] <stpeter> will be draft-ietf-lemonade-mms-mapping-00 [13:16:52] <stpeter> next: IMAP push, IAMP pull [13:17:43] <stpeter> IETF 57 -- decision to pursue one solution (push or pull) [13:18:04] <stpeter> do we know enough to make this decision? [13:18:30] <stpeter> draft-lemonade-imap-submit-01 [13:18:49] <stpeter> "forward without download" [13:19:17] <stpeter> allow IMAP client to include previously-received message (or parts) without downloading, then uploading the content [13:19:38] <stpeter> slides here mostly the same as Vienna (IETF 57) slides [13:20:01] <stpeter> mindor differences in how push would work [13:20:25] <stpeter> having IMAP submit instrinsically has been the focus [13:20:41] <stpeter> two submissions mechs: existing submit, and IMAP [13:21:31] <stpeter> options: (1) deprecate Submit (2) maintain both (with extensions) (3) tie IMAP to Submit [13:21:58] <stpeter> risk: parallel mechanisms that diverge [13:22:18] <stpeter> IMAP push requires IMAP queueing [13:22:59] <stpeter> client poll to learn status, or stay online [13:23:13] <stpeter> likely impl will be to bolt sendmail to IMAP server [13:23:27] <stpeter> proxy mechanism to do IMAP push has not changed [13:23:29] <stpeter> adds complexity [13:23:47] <stpeter> admin complexity, proxy auth problem [13:24:25] <hildjj> and why would i use IMAP for an IM channel? [13:24:35] <stpeter> not sure [13:24:41] * hildjj backs away slowly [13:24:58] <stpeter> IMAP pull.... [13:25:12] <stpeter> "pawn ticket" mechanism [13:25:25] <stpeter> (mentioned in appsarea this morning) [13:25:45] <stpeter> authorize limited access to specific MAP data [13:26:00] <stpeter> per-mailbox access generation key [13:26:14] <stpeter> client can cause new secret to be generated at any time [13:26:40] <stpeter> client creates URL which can include expiration time, role, user [13:27:15] <stpeter> IMAP compose command... [13:27:23] <stpeter> allows client to assemble drafts from parts [13:27:30] <stpeter> useful with both push and pull [13:27:36] <stpeter> solution for sent mail copy [13:27:48] <stpeter> addresses future delivery: quota, cancel, revise [13:27:58] <stpeter> makes imap pull easier [13:28:01] <stpeter> URL auth [13:28:25] <stpeter> can restrict authorization -- expiration time, user identity, role identity (submit server) [13:28:28] <leg> "pawn ticket" is such a horrible name. [13:28:36] <stpeter> useful in areas outside lemonade [13:28:45] <stpeter> the scribe refuses to comment on naming ;) [13:28:58] <hildjj> what about "prawn ticket", then? [13:30:49] <stpeter> main question: where do we add the complexity, does push or pull introduce more complexity? [13:31:05] <stpeter> IMAP URL auth (Chris Newman and Mark Crisipin) [13:31:26] <stpeter> include authorization in URLs, enable forwarding of email without download [13:32:02] <stpeter> changes in this revision: [13:32:08] <stpeter> added authid and authrole [13:32:10] <stpeter> hex encoding [13:32:19] <stpeter> refined security considerations [13:32:22] <stpeter> upcoming changes.... [13:32:33] <stpeter> need to do initial changekey to get secret [13:32:41] <stpeter> make anonymous access explicit [13:32:59] <stpeter> add a hash function parameter so it can be changed to other mechs [13:33:06] <stpeter> (e.g., URLAUTH=SHA1) [13:33:12] <stpeter> default config? [13:33:27] <stpeter> i.e., config for different authroles [13:33:38] <stpeter> behavior depends on authrole [13:33:47] <resnick> Anyone got other changes for the doc? [13:33:51] <stpeter> comments [13:34:04] <stpeter> RL Bob Morgan [13:34:32] <stpeter> further generalization for different token schemes? [13:35:00] <stpeter> agreement that this would be desirable [13:35:12] <stpeter> larry [13:35:27] <stpeter> why does HMAC-MD5 need to be generated at all? [13:35:31] <stpeter> generated by the client [13:35:37] <stpeter> secret comes from server [13:35:55] <stpeter> client generates to save round trips [13:36:55] <stpeter> for class of devices using this, round trips are very expensive [13:37:57] <stpeter> randy: one change desired is to have server generated only on command [13:38:07] <stpeter> this would give us a better idea of when round trip is required, when not [13:38:27] <stpeter> when add this to IMAP server, client informed that no secret exists yet [13:38:55] <stpeter> from then on, can generate tickets [13:39:22] <stpeter> may want to add expiration dates on mailbox keys [13:39:33] <stpeter> one key per user, per mailbox? [13:39:52] <stpeter> if ACL changes, does key need to change? [13:41:37] <stpeter> Bob Morgan again: best to specify both (client generates or not) [13:41:52] <stpeter> usage will depend on context (device type, etc.) [13:42:24] <stpeter> pretty picture being shown on screen [13:42:51] <stpeter> outbound MTAs on mult machines, inbound on multiple machines, message stores on multiple machines [13:43:42] <stpeter> not having message queue on message store machine improves scalability [13:44:08] <stpeter> security concerns [13:44:15] <stpeter> imap mailbox key should be TLS prtected [13:44:22] <stpeter> can protect URL in transit [13:44:31] <stpeter> don't store URL without protection [13:44:37] <stpeter> (beware of browser history) [13:44:46] <stpeter> require out of band auth whenever possible [13:44:55] <stpeter> any comments? [13:45:42] <stpeter> the scalability concern is where the queue lives [13:45:49] <stpeter> pull: on outbound [13:47:42] <stpeter> push: queue on IMAP store? [13:48:00] <stpeter> ted hardie: is it accurate to assert that to be true? [13:48:03] <stpeter> not necessary? [13:49:39] <stpeter> concern is that people will just bolt in sendmail, but not required to put that on the same machine [13:50:54] <stpeter> push vs. pull is mainly of concern for large deployments (since it's so important where you put the message queue there) [13:51:29] <stpeter> RL Bob Morgan: design the protocol for the more complicated case [13:52:39] <stpeter> comments from Pete Resnick [13:53:04] <stpeter> want feedback on imap compose [13:53:30] <stpeter> for first pass, compose will be extended append [13:53:57] <stpeter> Pete plans to submit something after this meeting [13:54:08] <stpeter> IMAP compose applies equally to push or pull [13:55:58] <stpeter> "the decision" (push vs. pull) [13:56:08] <stpeter> no one in favor of doing both [13:56:58] <stpeter> question for Randy: do we know enough to decide now? [13:57:44] <stpeter> two main contenders: IMAP push with submit folded into IMAP, or IMAP pull with compose [13:58:00] <stpeter> can't decide if we have no editor for the IMAP push doc [13:58:41] <stpeter> WG chair can impress someone :) [13:59:09] <stpeter> ted hardie: real deployment difference [13:59:16] <stpeter> (between push and pull) [13:59:29] <stpeter> IMAP pull requires changes to IMAP server and submit server [13:59:37] <stpeter> IMAP push requires change to only one [14:02:00] <stpeter> dave crocker: only one existing proposal -- usually a telling signal [14:02:23] <stpeter> ted: we do have two proposals [14:02:28] <stpeter> but only one specification [14:04:13] <stpeter> consideration here is for internet email only [14:04:22] <stpeter> not taking requirements from MMS WAP etc. [14:04:45] <stpeter> but how protocols designed here might gateway or extend to other contexts [14:05:28] <stpeter> pete resnick: propose drop-dead date [14:05:42] <stpeter> also propose editor for *specification* of IMAP push [14:05:54] <stpeter> drop-dead dates for IMAP compose and IMAP push [14:06:08] <stpeter> if no specs by then drop-dead dates, go with IMAP pull [14:06:25] <stpeter> (but we don't have enough technical details to make decision now) [14:06:45] <stpeter> drop-dead could be several weeks [14:07:36] <stpeter> straw poll: push, pull, or wait? [14:07:39] <stpeter> first straw poll: do we, or do we not, have enough detail to decide? [14:11:45] <stpeter> deployment differences: application logic changes throughout many parts of the system, or more major changes in one place? [14:12:19] <stpeter> dave crocker: tying this to IMAP seems like a bad idea [14:14:19] <stpeter> pete resnick: IMAP pull could be used for a wide variety of things, but that's bad: better to limit the scope to email [14:15:17] <stpeter> straw poll now: do we know enough now to decide between push and pull? [14:16:39] <stpeter> hum in progress [14:19:02] <stpeter> hum conclusion: we don't know enough [14:19:10] <alexeym> IMAP poll: I don't think we should explicitly limit ourselves to email as I suspect people will like to use pull for things other than email [14:19:14] <stpeter> deadline: 10th or 15th of December [14:19:31] <alexeym> Do we have editors? [14:20:06] <stpeter> Randy to edit IMAP push [14:20:11] <stpeter> Pete doing compose [14:21:11] <stpeter> Ted volunteered to help Randy with IMAP push [14:21:19] <stpeter> deadline: 17 December [14:22:21] <stpeter> alexeym: : bring that up on the list [14:22:49] <stpeter> </the_decision> [14:22:56] <stpeter> IMAP channel and use cases [14:23:09] <stpeter> draft-ietf-lemonade-imap-channel-00 [14:23:13] <stpeter> any questions or comments? [14:23:19] <stpeter> no comments [14:23:27] <stpeter> s2s notification requirements.... [14:23:36] <stpeter> (Gev Dektor) [14:23:51] <stpeter> draft-dektor-s2s-notif-00 [14:24:17] <stpeter> sorry, draft-decktor-s2s-notif-00 [14:25:05] <stpeter> main motivation was improving on SNAP protocol [14:25:15] <stpeter> lots of issues with SNAP [14:25:22] <stpeter> scope unclear [14:25:49] <stpeter> security issues with SNAP [14:26:06] <stpeter> which entities can use SNAP? just s2s? [14:26:24] <stpeter> this work: s2s only [14:26:44] <stpeter> out of scope: MWI, SMS, WAP, end users [14:26:51] <stpeter> subscriptions out of scoipe [14:27:01] <stpeter> notification server to notification devides or gateways [14:28:03] <stpeter> in scope: complete spec [14:28:03] <stpeter> store and forward [14:28:10] <stpeter> reliability [14:28:14] <stpeter> (reliable transport) [14:28:23] <stpeter> maintain order of events [14:28:52] <stpeter> (queues, timestamps, etc. - must do somehow, protocol will specify) [14:29:28] <stpeter> dynamic structure for attributes [14:29:42] <stpeter> security: must answer all security threats [14:29:51] <stpeter> limiting scope to server to server will help [14:31:04] <stpeter> comments, questions? [14:34:40] <stpeter> lisa dusseault: why are subscriptions out of scope? [14:35:20] <stpeter> lisa: i think what is in scope is delayed acks, not store and forward [14:35:48] <stpeter> lisa: i had proto-draft in progress, so perhaps we could merge efforts [14:37:38] <stpeter> (e.g., internet-scale addressing ... URIs?) [14:41:37] <stpeter> rohan mahy: how would you summarize the semantics? [14:41:55] <stpeter> gev: data about events related to a mailbox [14:43:00] <stpeter> which events? mail added or removed? mailbox full? others? [14:44:19] <stpeter> rohan: need to be clear on what events are of interest other than "you've got mail" [14:51:45] <stpeter> motion to make this a WG item (with changes/comments from Lisa etc.) [14:51:49] <stpeter> no objections [14:52:09] <stpeter> deliverables.... [14:53:20] <stpeter> goals, extensions for VM playback, extensions for diverse endpoints, profile for diverse endpoints, s2s notification requierements, translation to and from other messaging systems [14:53:39] <stpeter> individual submissions for url auth, imap compose, etc. [14:53:44] <stpeter> new proposed dates [14:54:23] <stpeter> essentially a 6+ month push of the dates [14:57:32] <stpeter> will make the milestones more granular and get feedback on the list [14:58:35] <stpeter> meeting over! |