[09:02:55] --- resnick has joined
[09:11:44] --- resnick has left: Replaced by new connection
[09:11:44] --- resnick has joined
[09:29:52] --- resnick has left: Replaced by new connection
[09:29:53] --- resnick has joined
[09:46:42] --- resnick has left: Disconnected
[09:46:47] --- resnick has joined
[10:11:47] --- resnick has left: Disconnected
[10:11:59] --- resnick has joined
[10:14:13] --- resnick has left: Disconnected
[10:18:46] --- resnick has joined
[10:20:33] --- resnick has left: Disconnected
[10:37:33] --- resnick has joined
[11:22:20] --- resnick has left: Disconnected
[11:23:07] --- kmurchison has joined
[11:50:19] --- alexeym has joined
[12:56:52] --- hildjj has joined
[13:01:55] --- stpeter has joined
[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:07] --- mrose has joined
[13:03:11] --- rjs3 has joined
[13:03:19] <stpeter> goals, mms mapping, imap4 extensions, imap4 profile, imap4 channel, s2s notifications, next steps & milestones
[13:03:24] --- randy has joined
[13:05:06] <stpeter> s/imap4 extensions/extensions/
[13:05:40] <stpeter> 3 extensions: imap push/pull, url auth, imap compose
[13:06:08] --- resnick has joined
[13:06:43] --- abr has joined
[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:38] --- leg has joined
[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] --- resnick has left: Disconnected
[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:19] --- abr has left: Disconnected
[13:12:29] <stpeter> no comments on changes to that I-D
[13:12:36] --- abr has joined
[13:12:48] <stpeter> next: MMS Mapping
[13:13:03] <stpeter> (Randy Gellens)
[13:13:55] --- resnick has joined
[13:14:22] --- bacampbe has joined
[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:17:54] --- Eliot has joined
[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:40] --- resnick has left: Disconnected
[13:21:58] <stpeter> risk: parallel mechanisms that diverge
[13:22:07] --- resnick has joined
[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:05] --- dcrocker has joined
[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:31] --- Eliot has left: Logged out
[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:40] --- Eliot has joined
[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:24] --- Eliot has left
[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:46] --- nsb has joined
[13:45:49] <stpeter> pull: on outbound
[13:46:35] --- randy has left: Replaced by new connection
[13:46:45] --- randy has joined
[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:29] --- rjs3 has left: Disconnected
[13:52:39] <stpeter> comments from Pete Resnick
[13:52:59] --- Eliot has joined
[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:54:32] --- dcrocker has left: Disconnected
[13:54:54] --- jm has joined
[13:55:58] <stpeter> "the decision" (push vs. pull)
[13:56:08] <stpeter> no one in favor of doing both
[13:56:44] --- dcrocker has joined
[13:56:46] --- dcrocker has left
[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:06] --- Eliot has left
[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:15:44] --- rjs3 has joined
[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:16] --- resnick has left: Replaced by new connection
[14:22:20] --- resnick has joined
[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:22:58] --- resnick has left: Replaced by new connection
[14:23:00] --- resnick has joined
[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:43] --- resnick has left: Replaced by new connection
[14:35:46] --- resnick has joined
[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:00] --- dcrocker has joined
[14:44:19] <stpeter> rohan: need to be clear on what events are of interest other than "you've got mail"
[14:46:16] --- resnick has left: Disconnected
[14:51:37] --- jm has left: Disconnected
[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:31] --- resnick has joined
[14:57:32] <stpeter> will make the milestones more granular and get feedback on the list
[14:58:35] <stpeter> meeting over!
[14:58:50] --- kmurchison has left: Disconnected
[14:58:51] --- stpeter has left
[14:59:19] --- abr has left: Disconnected
[15:00:09] --- leg has left: Disconnected
[15:01:18] --- hildjj has left: Disconnected
[15:02:21] --- alexeym has left: Disconnected
[15:04:47] --- mrose has left
[15:06:19] --- resnick has left: Lost connection
[15:07:19] --- nsb has left: Disconnected
[15:07:20] --- rjs3 has left: Disconnected
[15:10:40] --- randy has left: Disconnected
[15:13:59] --- dcrocker has left: Disconnected
[15:16:08] --- bacampbe has left: Replaced by new connection
[15:16:22] --- hildjj has joined
[15:27:36] --- randy has joined
[15:38:36] --- resnick has joined
[15:48:17] --- hildjj has left
[15:58:30] --- randy has left: Disconnected
[16:31:54] --- resnick has left: Replaced by new connection
[16:32:28] --- resnick has joined
[16:59:58] --- resnick has left: Disconnected
[17:00:19] --- resnick has joined
[17:19:45] --- resnick has left: Disconnected
[17:30:53] --- resnick has joined
[17:32:29] --- resnick has left: Disconnected
[19:32:48] --- randy has joined
[20:43:26] --- randy has left: Disconnected
[20:59:09] --- resnick has joined
[21:02:30] --- resnick has left: Replaced by new connection
[21:12:35] --- tonyhansen has joined