[08:17:44] --- alexeymelnikov has joined
[08:18:17] --- alexeymelnikov has left
[08:18:37] --- alexeymelnikov has joined
[08:19:35] --- alexeymelnikov has left
[09:11:19] --- alexeymelnikov has joined
[09:39:22] --- slim has joined
[09:43:43] --- slim has left
[11:56:21] --- LOGGING STARTED
[11:59:23] --- alexeymelnikov has joined
[12:12:42] --- sam.silberman has joined
[12:15:10] --- alexeymelnikov has left
[12:36:53] --- sam.silberman has left
[14:44:01] --- dwf has joined
[14:44:38] --- dwf has left
[16:04:13] --- aaronstone has joined
[16:07:11] --- Joakim has joined
[16:20:51] --- Glenn Parsons has joined
[16:21:25] <Glenn Parsons> Just kicked the last chairs of the dias ... we'll start in a couple of minutes
[16:21:46] --- barryleiba@gmail.com has joined
[16:21:57] --- arnt has joined
[16:22:18] --- Darryl has joined
[16:25:22] --- frodek has joined
[16:25:42] --- randy has joined
[16:26:28] --- guenther has joined
[16:27:45] --- hardie@jabber.qualcomm.com has joined
[16:27:53] --- resnick has joined
[16:28:01] --- cyrus_daboo has joined
[16:28:18] <hardie@jabber.qualcomm.com> 2nd session
[16:28:26] --- kmurchison has joined
[16:28:36] --- pck has joined
[16:28:42] * guenther mumbles about jabbering
[16:28:48] <hardie@jabber.qualcomm.com> If you need a comment reflected to the room, please preface with room:
[16:28:49] <guenther> Lemonade, ROUND 2
[16:28:55] <guenther> agenda bash
[16:28:59] <hardie@jabber.qualcomm.com> Wait, am I minuting?
[16:29:30] <guenther> Pete: change last items (interop, next steps) to be shorter
[16:29:42] <guenther> 10min: agenda bash
[16:29:49] <guenther> 10 min: message events (randy)
[16:29:58] <guenther> 10min IMAP sieve (barry)
[16:30:06] <guenther> 10min notifications
[16:30:18] <guenther> ...<slide changed before I could finish>
[16:31:01] <guenther> ted: yes
[16:31:19] <guenther> I was only so-so at recording decisions yesterday
[16:31:28] <guenther> randy:
[16:31:41] <guenther> draft-ietf-lemonade-msgevents-04
[16:31:45] <guenther> open issues:
[16:31:58] <guenther> 1) anchor 11: should optional vs mandatory be in this document
[16:32:26] <guenther> randy: proposes to leave text as is, delete the anchor, and close it
[16:33:02] <guenther> 2) anchor 23: have the admin mailbox events been deployed
[16:33:32] <guenther> draft says that most events are deployed and then lists the exceptions
[16:33:43] <guenther> should mailbox admin events been deployed?
[16:33:47] <guenther> s/
[16:33:53] <guenther> s/should/have/
[16:35:08] <guenther> Chris: not deployed in their product
[16:35:21] <guenther> randy will update list
[16:35:34] --- tonyhansen has joined
[16:35:41] <guenther> randy will submit updated draft and instant lastcall
[16:35:58] <guenther> barry: imap-sieve
[16:36:10] <guenther> partially discussed in sieve meeting
[16:36:36] <guenther> major changes:
[16:36:44] <guenther> require metadata and environment
[16:36:58] <guenther> clarify flag/annotation state (show new)
[16:37:49] <guenther> defined metadata entries - /IMAPSieve/Script on mailbox - /IMAPSieve/Script on server (default) - No control over storage/validation of script - at most one script per mailbox - may be different scripts for different mailboxes
[16:38:05] <guenther> the entries contain the 'name' of the script, not the script itself
[16:38:27] <guenther> no specification for how to create the script
[16:38:50] <guenther> suggests using managesieve
[16:39:19] <guenther> then, instead of activating the script via managesieve, you store the name into the annotation
[16:39:39] <guenther> discussion in sieve was around having per-client scripts
[16:40:02] --- eburger has joined
[16:40:03] <guenther> check jabber archive of sieve meeting for details
[16:40:10] <guenther> randy to submit text
[16:40:52] <guenther> glen: use-case in this doc?
[16:41:00] <guenther> barry: yes, will change this doc
[16:41:06] --- resnick has left
[16:41:14] --- resnick has joined
[16:41:19] <guenther> randy: basic problem: which implementation is creating script?
[16:41:31] <guenther> if scripts are created by user or a single client, then current is okay
[16:41:55] <guenther> but if user has multiple clients all setting script, that's won't work
[16:42:02] --- sam.silberman has joined
[16:42:15] <guenther> updating sieve scripts is Too Hard
[16:42:26] <guenther> clients will just stomp each other
[16:42:36] <guenther> so, give them their own scripts to update
[16:43:10] <guenther> barry: not sure how the multiple scripts will operate/relate
[16:43:40] <guenther> randy: per-client actions would not be allowed to do actions that might conflict (fileinto, etc)
[16:45:44] <guenther> <comedic file mixup interlude>
[16:46:58] <hardie@jabber.qualcomm.com> cue yakty sax
[16:47:12] --- aaronstone has left
[16:47:15] --- lisa has joined
[16:47:23] <guenther> we drove aaron away
[16:47:50] <guenther> issue 2: should we allow transient add/del/edit header actions that would only stick during the execution of the script
[16:48:11] <guenther> - allows header changes for the purpose of redirect
[16:48:26] <guenther> IMAP messages are immutable, thus the restriction
[16:48:35] <eburger> Updated Barry's slides
[16:48:41] <eburger> on the web site
[16:48:42] <guenther> does anyone want that?
[16:49:03] <guenther> currently, header changes are banned completely
[16:49:23] <guenther> alexey: no objection
[16:50:02] <guenther> cyrus: allow them for append?
[16:50:19] <guenther> barry: no, the script is run on the message 'after' it's appended
[16:51:06] <guenther> guenther: easier to add this later than to take it out later
[16:51:17] <guenther> chris: weasel word it?
[16:52:01] <guenther> <comedic interlude>
[16:53:03] <guenther> ted: if you can't come up with a reason, and can add it later, that's a decision
[16:53:19] <guenther> issue 3: should EXPUNGE be an imap-sieve event?
[16:53:29] <guenther> - for some uses, flag change \deleted works, but not all
[16:54:01] <guenther> would operate on the message 'before' it was expunged
[16:57:34] <guenther> <discussion of IMAP expunge delaying>
[17:00:31] <guenther> glen: is there a real reason/use case for this?
[17:01:57] <guenther> eric: want's time limit on the decision
[17:02:04] <guenther> s/want's/wants/
[17:02:43] <arnt> room: I'm not particularly opposed to this, but I'm uneager about the growth of profie-bis.
[17:03:04] <guenther> pete will repeat your comment to the room
[17:03:10] <arnt> room: the cost of implementing seems to be increasing faster than the value provided.
[17:04:21] <guenther> eric: who's implementing this?
[17:04:27] <guenther> 1 yes, done
[17:04:33] <guenther> 2 yes, eventually
[17:04:40] <guenther> 2 maybe
[17:05:16] <guenther> chris: lean toward following the suggestion of the person who has implemented this
[17:05:32] <guenther> in this case, that person (alexey) is the one asking for it
[17:06:24] <guenther> seems to be consensus for making this an extension if it times out on the list
[17:07:18] <guenther> issue 4: alexey is worried that hte behavior of certain actions is "changed" from the base
[17:07:29] <guenther> (base == sieve base spec)
[17:07:55] <guenther> base only deals with new deliveries and this is explaining how the actions behave in _other_ contexts, necessarily differnt
[17:08:02] <guenther> ...appears barry's text is fine
[17:08:49] <guenther> issue 5: should references to sieve extensions be normative or informative?
[17:09:29] <guenther> imap-sieve "updates" the behavior of things, when the extension is present in this new situation
[17:12:07] <guenther> chris: <adhat off> do you have to understand the other spec? leaning towards normative
[17:12:19] <guenther> zolton: leave non-normative and state in text the requirements
[17:14:04] <guenther> barry: that's the current state
[17:14:27] <guenther> guenther: just make broad statements about how processing is done?
[17:15:04] --- eburger has left: Replaced by new connection
[17:17:33] <guenther> <comedic process argument interlude>
[17:18:06] <guenther> alexey: include is the only extension not approved
[17:18:16] <guenther> chris: kind of a grey area for references
[17:19:37] <guenther> chris: technically, it's a fine-grained case, where a given section should ....
[17:19:45] <guenther> eric: "get a room!"
[17:19:55] <guenther> profile bis
[17:20:37] <guenther> slides are up
[17:20:49] <guenther> convert-profile-something bis
[17:20:59] <guenther> stuff being added:
[17:21:19] <guenther> sasi-ir, sort, comparator
[17:21:32] <guenther> views: context=search, context=sort, esort(?)
[17:21:35] <guenther> enable
[17:21:55] <guenther> allow partial URLs in catenate and urlauth (needs to IMAP capability)
[17:22:19] <guenther> comments on the additions?
[17:23:15] <guenther> zolton: should we drop IDLE, now that we have NOTIFY?
[17:23:30] <guenther> alexey: hold this discussion now?
[17:24:26] <guenther> ted: original description and consensus on profile bis was that it would be superset
[17:25:21] <guenther> ted: to minimize icky, keep it
[17:27:23] <guenther> eric: but profile bis superseded
[17:28:11] <guenther> others: but clients use IDLE
[17:28:20] <guenther> rough consensus to leave it in
[17:29:22] <guenther> alexey: should add streaming?
[17:29:34] <guenther> eric: <polls OMA members>
[17:30:02] <guenther> dorothy: not a requirement
[17:30:20] <resnick> More to the point, not important enough to hold up profile bis
[17:30:21] <guenther> dorothy: getting profile bis is more important
[17:30:29] <resnick> Hey! What you said.
[17:30:43] <guenther> "Now, in dolby stereo"
[17:31:01] <guenther> is streaming out?
[17:31:13] <guenther> <many hands>
[17:31:41] <guenther> anyone strongly feel that it should be in?
[17:31:45] <guenther> <no hands>
[17:32:04] <guenther> next: quickstart
[17:32:09] <guenther> what had we decided?
[17:32:55] <guenther> alexey: think we need implementations before deciding
[17:34:01] <guenther> consensus: will leave it out
[17:34:28] <guenther> profile bis: optional/undecided bits:
[17:34:54] <guenther> out-of-band notifications: format, one or more example bindings to protocol (BIFF BOF?)
[17:35:07] <guenther> sieve filters: IMAP sieve - how to manage scripts?
[17:36:14] <guenther> randy: suggestion: take the current appendix with OMA requirements and include pictures showing how o-o-b notification work using an "MAGIC HERE" box
[17:37:27] <resnick> ted: seems simpler to leave it out. What would the implementor do differently?
[17:37:56] <resnick> randy: the appendix allows someone to look at lemonade doc and see the comprehensive solution.
[17:38:09] <resnick> alexey: could move it out of the document
[17:38:30] <resnick> eric: if we're silent, someone is going to move away from lemonade
[17:38:53] <resnick> ted: same risk by putting it in profile bis with "not present here"
[17:39:05] <resnick> randy: depends on how carefully you read the document
[17:39:43] <resnick> glenn: notifications draft has architecture discussion (magical out-of-imap box)
[17:40:29] <resnick> glenn: snapp (sp?) proposal is also in the notifications document
[17:40:53] <hardie@jabber.qualcomm.com> SNAP, no?
[17:40:59] <resnick> sorry, yes.
[17:41:15] <resnick> Couldn't remember if the acronym was longer than that.
[17:41:16] <guenther> extension doc to EMN was deemed a non-started yesterday
[17:41:23] <guenther> s/started/starter
[17:41:31] <resnick> back to our regularly scheduled jabberer.
[17:41:51] <guenther> glen: how much to include in profile bis?
[17:42:11] <guenther> randy: answer depends on how much further we take the notifications document
[17:42:22] <guenther> randy: biff bof may not be relevant to this question
[17:42:41] <guenther> randy: partly timing, partly because it's a very narrow use case
[17:43:14] <guenther> lisa: worried about message event schema
[17:43:53] <guenther> what it contains affects supported use cases
[17:44:17] <guenther> chris: as tech contrib (not ad), maybe: the schema doc is very extensible
[17:44:35] <guenther> right now it only has one attribute that is state oriented
[17:44:51] <guenther> biff bof can add more and profile the schema
[17:45:08] <guenther> biff bof could then concentrate on the extensions
[17:45:33] <guenther> chris: doesn't believe msgevents should be blocked
[17:45:47] <guenther> randy: proposal:
[17:46:03] <guenther> - email discussions among key people (alexey, randy, chris, dave)
[17:46:27] <guenther> - they will send proposal on what to do to msgevents and profile
[17:47:29] <guenther> glen: proposal to be made within two weeks
[17:48:14] <guenther> eric: blocking on biff bof adds...maybe 2 years?
[17:49:04] <guenther> randy: the most simple use case is to send a kicker to restart IMAP
[17:49:09] <guenther> no state needed
[17:50:14] <guenther> alexey: imap-sieve in profile? how much time you need, barry?
[17:50:25] <guenther> barry: depends on metadata and decision on expunge
[17:51:07] <guenther> end of august?
[17:51:20] <guenther> eric: interoperability testing
[17:52:26] <guenther> CMCC testing
[17:52:45] <guenther> CMCC launched mobile email services in enterprise market based on private standards
[17:52:57] <guenther> movile email for mass market in field trial since early 2007
[17:53:10] <guenther> CMCC prefers lemonade to OMA
[17:53:31] <guenther> OMA MEM work progresses slowly: took about three years to complete RD and AD
[17:53:44] <guenther> - a few vendors contribute to OMA
[17:53:58] <guenther> CMCC goal: speed up standardization of MEM
[17:54:09] <guenther> 1) help IMAP based specs accepted by OMA
[17:54:15] <guenther> 2) host or join interop test
[17:54:25] <guenther> 3) upgrade CMCC systems to standard solution
[17:54:32] <guenther> interopt test:
[17:55:03] <guenther> - hope to achieve first-hand experience and understanding of lemonade implementations
[17:55:09] <guenther> CMCC can provide:
[17:55:15] <guenther> - premise, network, etc
[17:55:22] <guenther> - meetings rooms
[17:55:31] <guenther> - suggestions from operation experience
[17:55:49] <guenther> - select friendly customers to experience the service for trial
[17:56:01] <guenther> glen: thank you to CMCC
[17:56:17] <guenther> had test event last fall after profile publication
[17:56:42] <guenther> probably right time to do another test once profile bis is published (in rfc queue?)
[17:56:57] --- sam.silberman has left
[17:57:01] <guenther> perhaps in the fall would match that?
[17:57:14] --- pck has left
[17:57:22] <guenther> that or next year
[17:57:44] <guenther> former would be more about 'proving' the documents
[17:58:45] <guenther> latter would be more about moving the documents to draft or verifying implementations calendaring meeting is around 17-18th of September
[17:58:49] <cyrus_daboo> Calconnect vcard workshop is 18th Sep 2007. Other calconnect stuff is 17th - 21st Sep.
[17:59:35] <guenther> ted: would interop event include WG meeting?
[17:59:44] <guenther> glen: no
[18:00:34] <guenther> alexey: should poll on list about how has/will have implemented stuff
[18:00:55] <guenther> eric: poll: would you participate in october?
[18:01:02] <guenther> <some hands>
[18:01:25] --- cnewman@jabber.org has joined
[18:01:56] <guenther> <schedule jockeying>
[18:02:20] <guenther> will go to list...
[18:04:08] <guenther> eric: proposed milestone dates
[18:09:18] <guenther> <stuff generally pushed a month, maybe two> later
[18:09:23] --- resnick has left
[18:10:01] --- kmurchison has left
[18:10:14] --- barryleiba@gmail.com has left
[18:10:24] <Glenn Parsons> Meeting adjourned
[18:10:27] --- lisa has left
[18:10:29] --- cnewman@jabber.org has left
[18:10:30] --- hardie@jabber.qualcomm.com has left: Disconnected.
[18:10:33] --- guenther has left
[18:10:44] --- randy has left
[18:10:48] --- cyrus_daboo has left
[18:28:14] --- Darryl has left
[18:28:26] --- frodek has left
[18:44:15] --- tonyhansen has left
[18:48:33] --- Glenn Parsons has left
[18:55:51] --- Glenn Parsons has joined
[19:46:06] --- Glenn Parsons has left