[00:00:56] <alexeymelnikov> Stephane: no need to make notifications reliable
[00:01:52] <alexeymelnikov> Glenn: nothing to do for this item, as IMAP will show all messages during resynchronization
[00:02:52] <alexeymelnikov> Question # 2: terminology "cache delete" (IETF term) versa "local delete" (OMA term)
[00:03:13] <alexeymelnikov> OMA will prefer to keep using their term, but don't require Lemonade to use theirs
[00:04:20] <alexeymelnikov> Question #3: signed notifications - do we need to do signing in NF?
[00:05:16] <alexeymelnikov> Stephane: The answer is no, NF is not really aware of the notification method. Unless we want to use end-to-end encryption of notification.
[00:06:16] <alexeymelnikov> Stephane: don't put signing in NF for now, unless somebody asks us. Don't put anything valuable in notification.
[00:08:25] <alexeymelnikov> Ray: why signing? To prevent somebody faking/tampering with notifications
[00:09:53] <alexeymelnikov> Randy: maybe OMA want to prevent Deny Of Service (and money cost) caused by faked notifications
[00:10:09] <alexeymelnikov> ...test...
[00:10:13] <alexeymelnikov> ...test...
[00:10:15] --- alexeymelnikov has left
[00:10:15] --- Randy has left
[00:10:27] --- alexeymelnikov has joined
[00:10:46] --- Randy has joined
[00:12:21] <alexeymelnikov> Glenn: need to discuss Notifications draft first before answering to OMA on this question.
[00:14:00] <alexeymelnikov> Additional comments on Section 7 (draft-ietf-lemonade-oma-realization)
[00:18:23] --- Randy has left: Logged out
[00:21:53] <alexeymelnikov> CONVERT references OMA ST. OMA wants the client to decide on best conversion.
[00:22:42] <alexeymelnikov> This sounds like a clarification requested by OMA.
[00:25:08] <alexeymelnikov> There is no requirement to use OMA ST compliant server for conversion. CONVERT just borrows the list of parameters for different conversions.
[00:25:22] <hardie> As informational reference it seems very useful, but I want to be clear on whether the WG has agreed to use STI for all conversions--sounds like the answer is no, but that the CONVERT draft re-uses some parameters
[00:25:38] <hardie> crossed in the ether there--thanks for the clarificaitons.
[00:28:14] <alexeymelnikov> Alexey: Is OMA ST reference normative? It is (or something else) better be in order to help out implementors.
[00:29:40] <alexeymelnikov> Ray: Maybe we can agree on 10 or so required conversion parameters.
[00:30:33] --- Randy has joined
[00:31:29] <hardie> The global tree for media features at iana is at http://www.iana.org/assignments/media-feature-tags
[00:31:53] <hardie> The ASN.1 is an alternate representation, by the way; it doesn't require an asn.1 protocol
[00:33:15] <hardie> Note that URI tree allows folks to mint these relatively easily
[00:34:05] <resnick> Sorry. Stepped out for a bit. Back.
[00:34:42] <alexeymelnikov> Alexey: ABNF for conversion parameters is underspecified
[00:35:30] <Randy> Item 7 (communication btwn client & server on settings)
[00:36:16] <Randy> Question on DMS: Document Management System; protocol to manage XML documents
[00:37:22] <Randy> Stephan: we don't care about the details of this; out of our scope
[00:37:46] <Randy> Glenn: managesieve
[00:39:32] <Randy> s/DMS/XDM/
[00:39:56] <Randy> Discussion on use of managesieve for this
[00:40:01] <resnick> Whoever is speaking who is not Stephane right now is not audible.
[00:40:08] <resnick> Well, Alexey is audible.
[00:40:10] <Randy> Alexey: could use ACAP or LDAP to manage sieve scripts
[00:40:11] <resnick> The other person.
[00:40:17] <resnick> Or is that Corby?
[00:40:54] <Randy> Corby isn't here, but his colleague is and is often inaudible (he speaks in a low voice unmiked)
[00:41:06] <resnick> :)
[00:41:36] <Randy> Directionality is an issue
[00:42:33] <Randy> Stephane: is this a critical function where we want to insist on our technology being used, or is this an area where we can list options and OMA can use whatever they like, or something of their own
[00:43:12] <Randy> Glenn: leaning towards optional or not described at all
[00:43:25] <Randy> Stephan: if we don't describe it, OMA will use XDM
[00:43:46] <Randy> Alexey: let's include it in the doc for now, we can always modify or delete
[00:44:48] <hardie> I dropped off the phone call for a moment, to hook up the charger, bt I'll be using it again after the break.
[00:58:29] <hardie> Back on the call
[00:59:16] <alexeymelnikov> Ted, we have a break fro 10 minutes (almost over now)
[01:01:27] <hardie> fax me some tea
[01:02:03] * resnick will probably hang in there for 1 more hour
[01:02:40] <alexeymelnikov> We are back
[01:04:06] <alexeymelnikov> Item # 8 - OMA want more information on minimizing delays
[01:05:24] <hardie> Can someone summarize the discussion? It's hard to hear anyone but Glenn right now.
[01:05:24] <alexeymelnikov> Stephane: Presence can be used to minimize delays (which way to reach the endpoint)
[01:06:53] <alexeymelnikov> We were talking about how presence can be used to minimize delays.
[01:08:17] <hardie> It sounds like we don't have an answer, but we should say we've taken on board the idea that it is necessary?
[01:08:34] <hardie> It will depend on which mechanisms we're talking about.
[01:08:48] <hardie> But we can acknowledge that we understand the issue.
[01:09:13] <alexeymelnikov> Ray: a hypotetical protocol that can push envelope (metadata) together with the message, so that metadata can be displayed in message list view on a cell phone.
[01:09:51] <alexeymelnikov> Randy: are we minimizing delays or "persived" delays?
[01:10:26] <alexeymelnikov> Ted: I think there are multiple interpretations of what OMA means, so we might need to double check.
[01:11:12] <alexeymelnikov> Stephane (earlier): IMAP IDLE provides push notifications, this can also qualify as "minimizing delays".
[01:12:06] <alexeymelnikov> Randy: minimizing delays can be in conflict with other goals (e.g. minimizing usage of cellphone battery)
[01:12:09] <Randy> Important to balance delay reduction with battery life
[01:14:24] <alexeymelnikov> Many: Does "minimizing delays" means "minimizing round trips"?
[01:15:28] <resnick> Whoever that is needs to speak up.
[01:15:33] <resnick> Or use a mic.
[01:16:41] <hardie> Guys, I think this is ratholing a bit. If this needs to be clarified, let's get it clarified. Or we can say that it gets considered for each of these protocol bits, in balance with other bits. But the vagueness of this issue means we could spend a lot of time on it without progress.
[01:17:07] <hardie> But moving on seems to be something that we should do soon. There are a lot of documents left to cover past this liaison statement.
[01:23:47] --- xiaodong has left: Disconnected.
[01:24:15] <resnick> BTW: There is something in the path of the camera that is causing it to focus short.
[01:24:33] <resnick> Or at least that's my diagnosis.
[01:25:13] --- Randy has left: Logged out
[01:25:49] <alexeymelnikov> Item # 14: OMA seem to be worried about using TLS for mutual authentication. The answer to this is that mutual auth is provided by SASL, not TLS. Some SASL mechanisms can be not as CPU intensive as TLS.
[01:26:07] <alexeymelnikov> Item # 15: end-to-end message recall
[01:26:44] --- Randy has joined
[01:26:51] <alexeymelnikov> Answer: this doesn't work even with Outlook.
[01:27:15] <alexeymelnikov> Jokes in the room about specifying a "recall" button for OMA.
[01:27:28] <hardie> Glenn, you might try iGlasses, from the same folks as iBoost
[01:27:43] <resnick> (for the focus issues.
[01:27:45] <resnick> )
[01:27:55] <Randy> If they want a button (like they get with Outlook) they can specify the button. We just can't make sure it will work/.
[01:28:06] <resnick> It's not a big deal.
[01:28:46] <alexeymelnikov> Pete, there is nothing but air between the camera and the table where Glenn sits.
[01:29:47] <Randy> (But the air here is not very clear)
[01:29:53] <resnick> :)
[01:30:34] <alexeymelnikov> All: a protocol for message recall can be created, but the chances for this to be useable in Internet at large are very slim.
[01:32:39] <alexeymelnikov> Glenn is on slide 16
[01:33:47] <alexeymelnikov> Glenn: I've just realized the notifications draft was not authorized by the chairs
[01:34:47] <alexeymelnikov> Glenn reviews Notifications discussion from Vancouver: a request to create a new notification mailing list and no traffic on it (except for a few messages from Eric).
[01:36:54] <alexeymelnikov> Glenn: do we want to post Notifications draft to the mailing list now and discuss it tomorrow?
[01:37:02] <alexeymelnikov> Answer: yes
[01:38:51] <alexeymelnikov> Moving on to Content transformations: Ray is going to talk.
[01:40:39] <alexeymelnikov> Changed since the last draft: corrected ABNF errors, merged MIME type/subtype into a single parameter, etc.
[01:41:23] <alexeymelnikov> The main issue is about mandatory to implement content conversion parameters.
[01:42:58] <alexeymelnikov> OMA STI is a massive spec, a developer will be overwhelmed by the number of options
[01:44:01] <alexeymelnikov> Ray: examples show how to use OMA STI.
[01:44:10] <alexeymelnikov> Glenn: is there any ABNF?
[01:44:15] <alexeymelnikov> Ray: no
[01:44:31] --- Fan Xiaohui has left: Replaced by new connection
[01:44:33] --- Fan Xiaohui has joined
[01:44:38] --- xiaodong has joined
[01:45:13] <alexeymelnikov> Glenn: example can't be normative, ABNF is needed.
[01:45:33] --- Randy has left: Logged out
[01:46:38] <alexeymelnikov> Glenn: Is OMA STI a proper spec? What about CONNEG?
[01:47:41] --- anabolism has joined
[01:48:59] --- anabolism has left
[01:49:16] <alexeymelnikov> Ted: string comparisons might be needed on parameter values.
[01:50:57] --- Randy has joined
[01:52:11] <alexeymelnikov> Stephane: how do we decide on subset of parameters we want to mandate? There is no requirement document.
[01:52:46] <hardie> Sorry, it's late and my cold doesn't make it easy to talk up. Basically, I was suggesting that we consider using tokens or some similar method (like conneg's uri mechanism) so that we can assure that paramater interpretation is interoperable across implementations. Width and height might be obvious, but I suspect some other parameter classes might not be.
[01:52:55] <alexeymelnikov> Stephane: how do we extend things later on?
[01:53:36] <alexeymelnikov> Alexey/Randy: create a registry using IANA?
[01:54:33] <hardie> Chris Newman and Ned Freed would be good people to review the token grammar; they were very helpful in working out what elements can clash
[01:57:53] <alexeymelnikov> Ted: check how CONVERT parameters interact with MIME type parameters.
[01:58:48] <Randy> Ted points out that some information might be carried at multiple levels, and these levels might disagree
[02:00:33] --- Randy has left: Logged out
[02:01:20] --- Randy has joined
[02:01:44] <Randy> test
[02:02:08] --- Randy has left: Logged out
[02:02:51] <hardie> yes tester?
[02:03:14] --- Randy has joined
[02:03:50] <Randy> Hmmm
[02:04:13] <Randy> Anything I type goes away when I restart my client.
[02:04:53] <Randy> Also I don't see any msgs from anyone in the last 10 minutes, except for Ted's response to my test (which I now don't see)
[02:05:49] --- Randy has left: Logged out
[02:06:56] --- Randy has joined
[02:07:40] --- Randy has left: Logged out
[02:08:10] <resnick> I'm cooked. Off to bed.
[02:08:21] <resnick> Talk to everyone tomorrow.
[02:08:25] <hardie> See you.
[02:08:29] --- anabolism has joined
[02:10:43] <alexeymelnikov> Zoltan: Can we ask OMA for guidance on STI parameters?
[02:11:11] <hardie> Can someone restart the video chat to me? When Pete left, things dropped.
[02:12:28] <hardie> Thanks, it is back
[02:18:32] <alexeymelnikov> Discussion about whether we want all 91 OMA STI parameters to be supported in CONVERT.
[02:18:48] <alexeymelnikov> The answer is we want to think about a shorter list.
[02:19:48] <alexeymelnikov> OMA liaison should include question about shorter list.
[02:20:47] <alexeymelnikov> Also discussion if we describe all OMA STI parameters in ABNF or just the short (mandatory to implement) list.
[02:25:11] <hardie> Or to quote Terry Pratchett "Everything that happens stays happened"
[02:25:26] <alexeymelnikov> Moving on to Compression
[02:29:20] <alexeymelnikov> TLS compression - RFC 3749
[02:34:13] <alexeymelnikov> Stephane: is there still a problem with BINARY APPEND to be addressed in Phase 2?
[02:36:08] --- anabolism has left
[02:37:00] --- anabolism has joined
[02:37:32] <alexeymelnikov> Ray: change LZIP (which compresses a set of commands) to something like BINARY which can be used to compress a body part.
[02:39:03] <alexeymelnikov> Alexey: per body part compressing seems more interesting to me.
[02:39:24] <alexeymelnikov> Stephane: How TLS stacks behave if TLS compression is not available?
[02:39:36] <alexeymelnikov> All: we don't know.
[02:45:41] <alexeymelnikov> Randy: MAY support TLS compression goes against goals of Phase 1 to have a single package of extensions.
[02:47:11] <alexeymelnikov> Need to research if TLS compression is implemented (e.g. in OpenSSL) and how API work if TLS compression is requested and not available.
[02:49:05] <alexeymelnikov> Randy: <http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html> recommends against using TLS compression as it leads to connection failure.
[02:51:44] <hardie> http://www.iana.org/assignments/comp-meth-ids
[02:51:59] <hardie> http://www.rfc-editor.org/rfc/rfc3749.txt
[02:53:44] <alexeymelnikov> Moving on to Firewall Traveral
[02:55:25] <alexeymelnikov> Stephane: "intermediary challenges" just describes what the issue is.
[02:56:37] <alexeymelnikov> "HTTP binding document" - (revision -05) now introduces SOAP binding
[02:58:20] <hardie> I only see -04, but it has a SOAP binding
[02:58:22] <alexeymelnikov> Future plan for HTTP binding document - to have 4 bindings in total: raw, SOAP, rest, webdav
[03:02:57] <hardie> Ray: please be aware of the CalDAV work and the effort to update 2518 to 2518bis.
[03:05:18] <alexeymelnikov> Ray: we were trying to come up with a generic way of mapping IMAP grammar to SOAP messages.
[03:05:31] <alexeymelnikov> Each IMAP command becomes a SOAP method.
[03:06:29] <alexeymelnikov> Ray: SOAP adds significant overhead to IMAP
[03:07:07] <alexeymelnikov> But there are some new specs about compressing XML (see the draft)
[03:07:07] <hardie> So you're going to create an xml document, then create an asn.1 representation of that, all on mobile device?
[03:10:53] <alexeymelnikov> Ted: is the complexity of SOAP + binary XML mapping worth it?
[03:10:59] <hardie> How much has been implemented now?
[03:11:17] <hardie> in re: Stephane's comments.
[03:11:52] <anabolism> Ted also noted that by compressing SOAP XML in ASN.1 the level 3 boxes can't understand the messages
[03:13:16] <hardie> So the firewall issue is so pressing that we need either to adopt http tunneling or go with a binding that requires new interfaces to the data store, new updates to ALGs, and a great deal of computational crunching from the client?
[03:13:19] <hardie> ow.
[03:13:23] <alexeymelnikov> Stephane: connection life is an issue - for some reasons HTTP connections have longer timeouts.
[03:15:24] <hardie> I missed Eric's joke.
[03:17:48] <hardie> http runs over tcp, what does this mean?
[03:18:20] <anabolism> No exposure to client of ability to create TCP connections
[03:18:26] <alexeymelnikov> Randy: the issue is that networks are unusable for straight TCP. This needs further investigation at high level, or we just end up mapping each protocol to HTTP.
[03:20:37] <alexeymelnikov> Ted: email is a killer application for mobile phones (as RIM has demonstrated), so I still prefer to pit pressure on people to fix their networks/implementations/etc.
[03:22:23] <hardie> The problem Ray alluded to with WebDAV is still present, though, the semantics of the applications protocols are significantly different. Layering it on top of something with different semantics (stateful protocol on top of stateless, for example), you add complexity to the client that costs all things that we are trying to preserve--cpu cycles, memory, time, etc.
[03:22:30] <alexeymelnikov> Glenn: from Lemonade prospective we need to promote use of email protocols. The question is if we want to provide a workaround [in the form of Oracle's document].
[03:27:00] <alexeymelnikov> Eric: I don't have a problem having an Informational document. This is much better than letting OMA people do the work.
[03:27:48] <alexeymelnikov> The document is not going to be mentioned in Profile Phase 2.
[03:28:36] <alexeymelnikov> Eric: it is better to do the document in the WG, so that the WG can say that this document is not an endrun.
[03:31:04] <alexeymelnikov> Glenn: should the profile draft say that ports for IMAP/SUBMIT protocols must be opened in Firewalls.
[03:31:39] <alexeymelnikov> Or do we have a separate BCP on Firewall issues?
[03:33:11] <alexeymelnikov> Randy: Lemonade profile and Firewall traversal have different audiences. The former is for developers, the latter is for network administrators.
[03:34:49] <alexeymelnikov> Randy is volunteering for "deployment considerations" document.
[03:35:10] --- eburger has joined
[03:36:23] --- eburger has left
[03:36:32] --- hardie has left
[03:36:48] <alexeymelnikov> We are done for today
[03:37:06] --- anabolism has left
[03:38:35] --- shmaes has left: Disconnected
[03:46:58] --- alexeymelnikov has left
[03:51:43] --- xiaodong has left
[03:54:21] --- ietflemonade has left
[04:11:23] --- Glenn Parsons has left: Disconnected
[04:27:15] --- Fan Xiaohui has left: Disconnected
[07:38:01] --- Fan Xiaohui has joined
[10:06:33] --- Fan Xiaohui has left: Disconnected
[10:34:57] --- alexeymelnikov has joined
[10:35:11] --- alexeymelnikov has left
[11:56:08] --- LOGGING STARTED
[17:50:32] --- hardie@qualcomm.com has joined
[18:00:18] --- hardie@qualcomm.com has left: Logged out
[18:02:49] --- hardie has joined
[18:03:11] --- resnick has joined
[18:05:21] --- Glenn Parsons has joined
[18:05:27] --- alexeymelnikov has joined
[18:06:05] <alexeymelnikov> [test]
[18:06:11] <hardie> test
[18:06:24] <alexeymelnikov> [Seems to work]
[18:06:40] --- hardie has left: Replaced by new connection
[18:10:13] --- Barry Leiba has joined
[18:10:30] <Barry Leiba> Hola
[18:10:42] <Barry Leiba> (Or however one says that in Mandarin...)
[18:10:56] <resnick> Nee hao
[18:11:04] <Barry Leiba> Nee hao, then.
[18:11:15] <resnick> Ted, once he gets back on, can spell it.
[18:11:57] --- anabolism has joined
[18:14:34] --- anabolism has left
[18:14:39] --- eburger has joined
[18:17:34] <eburger> Welcome to Day two of IETF Lemonade Interim 64.5 Beijing
[18:21:02] <Glenn Parsons> We shall start as soon as we volunteer a scribe...
[18:21:32] --- anabolism has joined
[18:26:20] <alexeymelnikov> Barry: do you have any feedback on how to extend ManageSieve for IMAP Sieve that Dave and I were having?
[18:27:15] <alexeymelnikov> I will scribe again
[18:27:52] <eburger> Thank you Alexey!
[18:27:54] --- anabolism has left
[18:28:13] <Barry Leiba> I think we can deal with the managesieve issue, and I ought to get that into the next draft, rather than trying to hash out the details here.
[18:28:31] <Barry Leiba> What we should discuss here are the broad fiunctions that are needed, so I can try to get the details right.
[18:29:07] <Barry Leiba> The main thing we need to discuss is what Cyrus brought up, about the whole issue of doing things this way in the first place.
[18:29:07] <alexeymelnikov> Barry: I've already written some text/ABNF, so I can send it to you. Yes, we should discuss it offline.
[18:29:10] <eburger> For convenience, the slides for today are at http://flyingfox.snowshore.com/i-d/lemonade/slides64-5/slides64-5.html at the bottom of the page
[18:29:22] <Barry Leiba> OK, yes, send me text/ABNF, definitely.
[18:30:49] --- ray_cromwell3 has joined
[18:30:52] <Barry Leiba> We gonna start before my cell-phone battery runs out and I use up all my minutes? :-)
[18:31:00] <resnick> :)
[18:31:43] <alexeymelnikov> Maybe :-)
[18:32:32] --- ray_cromwell357526 has joined
[18:32:40] --- ray_cromwell3 has left: Disconnected
[18:33:23] <resnick> I'm more here (consciousness-wise) than I was yesterday.
[18:33:50] <alexeymelnikov> Glenn: we are talking about Profile bis today
[18:34:12] <alexeymelnikov> Glenn: We didn't do Notifications yesturday.
[18:34:14] <resnick> Is everybody there in Beijing who was there yesterday?
[18:34:28] <alexeymelnikov> Pete: yes.
[18:34:58] <alexeymelnikov> We will start from Phase bis "in vs. out", followed by Notifications, Filters, Quick reconnect.
[18:35:38] <alexeymelnikov> Glenn: Lomande Profile Phase 1 was sent to IESG
[18:35:50] --- Fan Xiaohui has joined
[18:36:15] <alexeymelnikov> Profile Phase bis = Phase 1 + ...
[18:36:52] <alexeymelnikov> What is extra in bis?
[18:37:57] <alexeymelnikov> Glenn is doing live editing of the extra bits
[18:38:51] <alexeymelnikov> Stephane: replace SIEVE with Filters ~ Filter management
[18:39:14] <alexeymelnikov> s/~/+
[18:40:14] <alexeymelnikov> Stephane: are we doing anything on clarifying architecture for OMA?
[18:41:06] --- anabolism has joined
[18:41:24] <alexeymelnikov> Proxy will be covered in Phase bis
[18:43:20] <alexeymelnikov> Randy has volunteered to write a draft on deployment considerations for Lemonade (in mobile/coprporate networks)
[18:43:54] <alexeymelnikov> Stephane: we should give a pointer to Randy's draft in Phase bis
[18:44:02] --- hardie has joined
[18:45:34] <alexeymelnikov> Alexey: add BINARY APPEND and allow F.w.d. Trio to use partial IMAP URLs.
[18:45:46] <alexeymelnikov> Stephane: discuss object level encryption?
[18:45:47] <hardie> Will they need a respin?
[18:46:28] <alexeymelnikov> To Ted:I think we can just "update" them and define a new special IMAP/ESMTP capability.
[18:46:33] <hardie> okay fine
[18:47:01] <hardie> To stephane's point, we're not talking about the object-level encryption possible for objects in the data store?
[18:49:11] <ray_cromwell357526> I think stephane is talking about the scenario where the proxy needs to be prevented from seeing cleartext message body parts and possibly headers, but still needs to be able to execute Lemonade commands on behalf of a client to a non-lemonade compliant server
[18:49:29] <ray_cromwell357526> this is the "magic box" proxy which retrofits lemonade compliancy to non-lemonade servers
[18:49:48] <alexeymelnikov> Randy: what is "object encryption" in this case?
[18:49:59] <ray_cromwell357526> deployed, presumably, by operators for enterprises which don't neccessarily want to upgrade
[18:50:28] <alexeymelnikov> Stephane: how to encrypt dbody parts between message store and the client (so that proxy can't read it), this is not end-to-end
[18:50:44] <ray_cromwell357526> I think object level encryption refers to the old XENCYPT proposal, which like LZIP, will encrypt the FETCHed items
[18:52:21] <alexeymelnikov> ?/Stephane: if we can do message store to client tunnel, object level encryption might not be needed.
[18:53:02] --- eburger has left: Replaced by new connection
[18:53:47] <alexeymelnikov> Ray: we are not doing SMIME, it is more of a transient thing
[18:54:16] <alexeymelnikov> Fan: if we do object level encryption, how do we distribute the key?
[18:55:32] <alexeymelnikov> Randy: can use SASL DIGEST-MD5 to do mutual authentication, derive a session key and use it.
[18:56:13] <alexeymelnikov> Glenn: reviewing items
[18:56:25] --- eburger has joined
[18:56:48] <eburger> Chairs slides and supplemental 64,5 page updated. DO NOT CLICK on PDF version. It isn't posted yet.
[18:57:05] <ray_cromwell357526> btw another issue is an attack that trio exposes, we have to be careful. a proxy could issue a catenate which references body parts and then forwards those to a third address, getting access to the cleartext. so clearly, proxies and CATENATE + BURL expose a problem
[18:58:03] <anabolism> You mean a proxy which holds the user's IMAP credentials?
[18:59:28] <ray_cromwell357526> yeah, if a proxy has credentials and is authorized for full access to a backend imap store, the tractability of preventing the proxy from handling lemonade requests but not gaining access to user message data is questionable and needs to be studied
[18:59:57] <alexeymelnikov> Notifications, content transformation, Filters (e.g. SIEVE), Filter management (e.g. Manage Sieve), Quick reconnect, Compression (per bodypart), BINARY APPEND (no text yet), allow for partial URLs in Trio (no text yet), Firewall traversal, Proxies, Object Level encryption.
[19:00:01] <anabolism> That seems a major issue with proxies: ultimately you have to trust them
[19:00:34] <anabolism> It seems to me there is only so much you can do to protect against a proxy without breaking the ability of the proxy to proxy
[19:00:51] <alexeymelnikov> VFOLDER also falls under Filters
[19:01:02] <ray_cromwell357526> for example, how would a lemonade proxy handling CONVERT for a backend server which does not support CONVERT get data between the store and the transcoding server without exposing the data to the proxy? and then of course, the transcodingf server could be attacked. So retrofiting CONVERT is not possible without introducing security risk
[19:01:33] <alexeymelnikov> Moving on to Notifications
[19:01:34] <ray_cromwell357526> i agree, the proxy idea is troublesome
[19:01:35] <anabolism> Proxies carry those risks with them
[19:01:45] <anabolism> If you avoid the use of a proxy you avoid the problem :-)
[19:02:16] <alexeymelnikov> Eric: people begged for Notification list, but no traffic on it
[19:02:52] <alexeymelnikov> Barry: no suprises, as there was no proposal
[19:03:54] <Barry Leiba> Can someone move St├ęphane closer to a microphone?
[19:04:00] <alexeymelnikov> Stephane is talking about Notifications draft
[19:04:40] <anabolism> Stephan is talking into a microphone, but that is different from the speaker phone
[19:04:46] <anabolism> Adjusting...
[19:05:28] <ray_cromwell357526> the bridge needs an equalizer for participants to control via DTMF :)
[19:05:29] <alexeymelnikov> Stephane: draft is tlking about NF, DF, and other blocks
[19:05:34] <Barry Leiba> :-)
[19:06:40] <alexeymelnikov> How to use notification for synchronization, Filters (VFOLDER)
[19:06:55] <Barry Leiba> The sound is MUCH better now.
[19:07:49] <alexeymelnikov> Inband notification payload (IDLE); outband payload, how to encrypt it, SMS binding (informative)
[19:08:14] <alexeymelnikov> How to manage notification settings
[19:08:31] <alexeymelnikov> [and I've missed the rest of TOC for the document]
[19:08:55] <hardie> he sent the doc to the list
[19:09:17] <hardie> So you can grab it to follow, if you have current email, or from the archives
[19:09:49] <alexeymelnikov> Stephane: two levels of filters: view filter and notification filter
[19:11:03] <alexeymelnikov> Outband pyaload format: OMA EMN
[19:11:20] <alexeymelnikov> (earlier) event types are defined in Chris Newman's draft
[19:13:00] <alexeymelnikov> Stephane: there is dependency on quick reconnect, text has not enough details
[19:14:36] <alexeymelnikov> Alexey: are we going to have one true payloaed format and allow for multiple notification mechanisms?
[19:14:40] <alexeymelnikov> Stephane: yes
[19:15:01] <alexeymelnikov> Stephane: EMN is not necessarily the format, but it is a current proposal
[19:17:16] <alexeymelnikov> Ted: do we want to allow for multiple channels for sending notifications
[19:17:40] <hardie> And multiple clients--so two clients desiring notifications to the same mailbox?
[19:18:07] <alexeymelnikov> Stephane: the text currently assumes one client/one channel, but nothing prevents multiple channels
[19:19:10] <alexeymelnikov> Ted gives an example of a message describing a trouble report: is the notification sent to multiple clients, or the first one to notice.
[19:19:36] <alexeymelnikov> Barry: there are many possible options: notification expirations, retries, etc.
[19:20:55] <alexeymelnikov> Randy: try to make as few options as possible (to keep it simple) and handle the rest at IMAP level
[19:22:12] <alexeymelnikov> Ray: different clients can use different view filters (in different IMAP connections) and different notification filters
[19:23:23] <alexeymelnikov> Alexey: expeiration can be done using VFOLDER's "SEARCH WITHIN <seconds>" filter
[19:24:07] <Barry Leiba> In case it wasn't clear: I agree with Randy. My point was that there are no end to the options, and it can get overblown very quickly. So, yes, we should avoid that by keeping it as simple as possible.
[19:25:06] <alexeymelnikov> Stephane: there is some text about "if the client doesn't reconnect on notification, stop sending"
[19:25:16] <Barry Leiba> Thanks for the page ref. :-)
[19:25:29] <alexeymelnikov> Scroll to top of page 9
[19:26:14] <alexeymelnikov> Stephane: there is an extension to EMN format
[19:27:46] <alexeymelnikov> ... for extra information like # of deleted messages, lock-down, do full sync, etc,
[19:28:06] <alexeymelnikov> Stephane: not sure if this extension should be in the final document
[19:31:18] <alexeymelnikov> Eric: should this be the base for WG document
[19:31:44] <alexeymelnikov> Barry: sounds like a good base
[19:31:59] <alexeymelnikov> Randy: is there is an alternative?
[19:33:20] <alexeymelnikov> Eric has sent a message approving the draft
[19:33:41] <alexeymelnikov> Chris needs to republish his "event types" draft as WG document
[19:34:55] <alexeymelnikov> Moving on to filters (Barry's IMAP SIEVE draft)
[19:35:07] <alexeymelnikov> Barry: a round of comments on IMAP SIEVE:
[19:35:28] <alexeymelnikov> replace IMAP command with Manage Sieve extension
[19:35:56] <alexeymelnikov> Dave Cridland had many concerns about modifying message during APPEND/COPY.
[19:36:20] <alexeymelnikov> And Cyrus had a concern if it was a right approach
[19:37:36] <alexeymelnikov> Barry haven't thought about Dave concerns while writing the document, but concerns are valid
[19:38:00] <alexeymelnikov> Barry: Lemonade doesn't really care about modifying messages
[19:39:19] <alexeymelnikov> (Dave concerns were about clients cache not matching the state on the server)
[19:40:17] <alexeymelnikov> Randy: treat Sieve modifications as "actions by a second client"
[19:41:04] <alexeymelnikov> Glenn: worried about adding controversial features, which are not needed for Lemonade
[19:42:19] <alexeymelnikov> Barry: don't want to put myself in a position that we need to make this more generic later
[19:42:46] <alexeymelnikov> Barry: talking about Cyrus' concern
[19:45:25] <alexeymelnikov> Cyrus was talking about generalizing SEARCH to allow for Unix style pipes, macro facility, etc.
[19:46:15] <alexeymelnikov> Cyrus's idea is somewhat orthogonal to IMAP Sieve
[19:46:37] <alexeymelnikov> Barry: Mark Crispin thinks that IMAP has too many extensions
[19:47:26] <alexeymelnikov> Ray: extending SEARCH to the point that it becomes Sieve?
[19:47:40] <alexeymelnikov> Barry: yes, add vacation extension to SEARCH :-)
[19:48:24] <alexeymelnikov> Randy: one good thing of Lemonade is that it reduces client code complexity, because all extensions are a package
[19:49:28] <alexeymelnikov> Glenn: when is the next revision?
[19:50:18] <Barry Leiba> Do you know if "*6" or some similar magic will put me in mute, so you don't hear me chewing as I eat dinner?
[19:50:54] <Glenn Parsons> Next revisions of drafts due Feb 27th
[19:51:35] <Glenn Parsons> Bridge mute is *6 -- unmute is *7
[19:51:48] <ray_cromwell357526> alexey: managed sieve is a repository of named sieve scripts, supports upload/delete/etc, SASL authentication
[19:51:54] <ray_cromwell357526> slide: example
[19:52:25] <ray_cromwell357526> example: reading script from server and updating it
[19:52:33] <ray_cromwell357526> slide: how to extend managed sieve
[19:52:48] <ray_cromwell357526> managed sieve assumes a single event type, message delivery
[19:53:03] <ray_cromwell357526> dave proposed extend setactive to bind scripts to other event types
[19:53:27] <ray_cromwell357526> stephane: will that work for all the events chris notified, or restricted set?
[19:53:33] <ray_cromwell357526> alexy: should work for all events
[19:54:06] <ray_cromwell357526> stephhane: would that work for particular event and particular sender? can mechanism be more granular?
[19:54:36] <ray_cromwell357526> alexey: use multiple scripts, uploaded from client, with different senders
[19:55:09] <ray_cromwell357526> glenn: would this proposal be included in barry's draft?
[19:55:11] <ray_cromwell357526> alexey: yeah
[19:55:29] <ray_cromwell357526> glenn: is there anything to add to this document, or barry's document?
[19:55:44] <ray_cromwell357526> alexey: dont care, can be separate or combined draft
[19:55:57] <Barry Leiba> I agree... goes into imap-sieve, that's fine.
[19:56:06] <ray_cromwell357526> glenn: what is the status?
[19:56:21] <ray_cromwell357526> alexey: we can try to do ietf last call, and involve lemonade and sieve wg
[19:56:33] <ray_cromwell357526> glenn: you need more time, or is it done?
[19:56:41] <ray_cromwell357526> alexey: nothing is missing or controversial
[19:57:08] <ray_cromwell357526> glenn: we need last call initiated (alexey to do it, with ted or scott)
[19:57:47] <ray_cromwell357526> alexey: managed sieve is better is sieve wg, instead of imapext
[19:58:28] <ray_cromwell357526> bridge: thought original document is beyond scope of lemonade needs
[19:58:35] <ray_cromwell357526> barry: correct
[19:58:51] <ray_cromwell357526> imapext doesnt want this as item added to charter
[19:59:37] <alexeymelnikov> Alexey: I've agreed to LC ManageSieve asap
[20:00:06] <ray_cromwell357526> glenn: don't think managed sieve needs to be wg document
[20:00:54] <ray_cromwell357526> alexey: has to be reviewed in sieve wg, but not sure it needs to be sieve wg item
[20:01:10] <ray_cromwell357526> bridge: silly that managed sieve not part of sieve wg
[20:01:26] <ray_cromwell357526> alexey: back thenl many mechanisms considered, ACAP, LDAP, etc
[20:01:36] <ray_cromwell357526> alexey:; document is ready to be LC'ed
[20:02:28] <Glenn Parsons> 5 minute break....
[20:02:43] <alexeymelnikov> Alexey: I will send a message to SEIVE WG asking if the ManagSieve should be WG item.
[20:11:03] <Barry Leiba> Beijing is just on mute, right?
[20:11:14] <ray_cromwell357526> yes
[20:11:21] <Barry Leiba> Groovy
[20:11:56] --- ray_cromwell357526 has left
[20:15:58] <Glenn Parsons> resuming with vfolder
[20:15:59] <alexeymelnikov> We are back
[20:16:06] <alexeymelnikov> Ray is talking about VFOLDER
[20:16:40] <alexeymelnikov> VFOLDER is a way to save SEARCH (persistent search)
[20:19:00] <alexeymelnikov> Alexey has raised a concern about persistent searches based on flag state, where a flag change can cause a message to reappear "in the middle" of the virtual mailbox - this violates IMAPv4rev1 spec
[20:20:25] <alexeymelnikov> Ray: so the draft was simplified to only allow for virtual folders based on immutable state (i.e. no flags)
[20:21:05] <alexeymelnikov> Ray: this simplifies server implementations as well
[20:21:43] <alexeymelnikov> Ray: a new SEARCH criteria was added "SEARCH WITHIN", to allow for scrolling window
[20:22:32] <alexeymelnikov> (i.e. "messages received in the last 5 days")
[20:25:51] <alexeymelnikov> Discussion on whether SEARCH WITHIN should be a separate draft. Consensus to have it a separate document.
[20:30:40] <alexeymelnikov> Suggestion to LC VFOLDER and SEARCH WITHIN right away. Discussion if these documents are WG documents or not.
[20:32:03] <alexeymelnikov> Zoltan: do VFOLDER mailboxes inherit view filter from the parent?
[20:32:13] <alexeymelnikov> Ray/Stephane: this is still an open issue
[20:33:03] --- gebing has joined
[20:33:58] --- ray_cromwell3 has joined
[20:35:58] <ray_cromwell3> zoltan was actually asking if NF is inherited, so if NF1 is attached to VF1, and then VF2 is derived based on VF1, does VF2 automatically have the same NF attached to it? probably not, but need to study it
[20:37:17] <ray_cromwell3> glenn: worth alexey doing reconnect work if no implementations?
[20:37:29] <alexeymelnikov> Glenn/Eric: publish Quick Reconnect revision before ManageSieve update
[20:37:39] <ray_cromwell3> stephane: oracle has something similar in pimap, maybe it can be modified to support reconnect
[20:37:44] <ray_cromwell3> alexey: i will do implementation as well
[20:37:53] <alexeymelnikov> Moving on to Profile bis
[20:38:21] <alexeymelnikov> Goal of Profile bis is to meet balance of OMA requirements
[20:39:53] <alexeymelnikov> Stephane: -00 text is based on OMA realization draft
[20:39:56] <Barry Leiba> I'm going to bail out of the phone call at this point... unless someone thinks I should keep listening. I'll stay on Jabber for a while, at least (maybe 'til the end).
[20:40:48] <alexeymelnikov> Profile Phase 1 is currently included by reference, will be merged into once Phase 1 is published
[20:41:30] <alexeymelnikov> There is some text/pictures about OMA and Lemonade architecture
[20:42:12] --- ray_cromwell3 has left
[20:45:30] <alexeymelnikov> Glenn likes architecture diagrams
[20:47:01] <alexeymelnikov> Alexey: suggestion to merge sections 3 and 4 into one (from Lemonade point of view there is no difference between "Proprietary store" and "Non-Lemonade store")
[20:50:06] <alexeymelnikov> Glenn/Stephane if OMA realization document would be referenced or just incorprorate. The answer is "referenced for now".
[20:53:48] <alexeymelnikov> Discussing logistic of what is in -00? Do we cut and paste Phase 1 text in it?
[20:54:43] <alexeymelnikov> Stephane: -00 need to come out before the next OMA meeting (in February).
[20:56:04] <alexeymelnikov> Eric/Glenn: -00 will reference Phase 1. -01 will include Phase 1 (it will be done after IESG telechat on Phase 1)
[20:59:42] --- gebing has left
[21:03:32] <Barry Leiba> Scribe fallen asleep?
[21:04:39] <Glenn Parsons> Does RFC Editor use XML, or Nroff or???
[21:04:46] <Glenn Parsons> I think they still use nroff
[21:04:48] <alexeymelnikov> Almost :-). Just discussing procedural issues regarding Phase bis
[21:04:59] <Barry Leiba> nroff yes
[21:05:14] <Barry Leiba> You obviously haven't been following the discussion on ietf@ietf.org. :-)
[21:06:04] <alexeymelnikov> Talking about milestones/charter now
[21:09:26] <alexeymelnikov> All items in the charter but "streaming" and "s2s notifications" are done.
[21:09:31] <anabolism> I somehow got unsubscribed from the ietf discussion list. I had been subscribed to Harald's ietf-censored, which migrated through several owners, and suddenly I stopped getting messages through it.
[21:09:44] <anabolism> (reply to Barry)
[21:10:18] <alexeymelnikov> Chairs: do we add items for all new drafts?
[21:19:33] <alexeymelnikov> Glenn: need to send liaison to OMA. Stephane will propose some text.
[21:21:51] <alexeymelnikov> 2 2hour meetings to be requested in Dallas
[21:22:38] <alexeymelnikov> We are done.
[21:22:58] <Barry Leiba> See you in Dallas.
[21:23:07] --- eburger has left
[21:23:10] --- alexeymelnikov has left
[21:23:15] --- hardie has left
[21:23:23] --- Barry Leiba has left: Disconnected
[21:23:32] --- anabolism has left
[21:24:20] <Glenn Parsons> Thanks again to China Mobile for hosting this interim!
[21:42:57] --- Fan Xiaohui has left: Disconnected
[22:35:54] --- Glenn Parsons has left: Disconnected
[23:12:56] --- resnick has left