[00:40:20] --- kael has joined
[00:40:34] --- kael has left
[01:50:42] --- kael has joined
[01:53:32] --- kael has left
[08:49:39] --- arnt has joined
[09:07:22] --- keithmoore has joined
[09:08:44] --- Fan Xiaohui has joined
[09:41:04] --- Fan Xiaohui has left: Replaced by new connection
[09:42:21] --- pguenther has joined
[09:43:33] --- Fan Xiaohui has joined
[09:46:44] --- frodek has joined
[09:48:58] --- Esemwy has joined
[09:49:00] --- hawbrook has joined
[09:50:46] --- Barry Leiba has joined
[09:51:10] --- Esemwy has left
[09:53:39] --- Glenn Parsons has joined
[09:59:18] --- Dave Cridland has joined
[10:01:10] <pguenther> Glenn: listening to you and Eric chatting has been amusing, especially Eric's "My butt feels especially clean this morning" comment
[10:01:18] <Glenn Parsons> We will start shortly....
[10:01:35] <Dave Cridland> I'm now thinking it's a good thing I only just got the audio feed on.
[10:01:39] --- cyrus_daboo has joined
[10:01:46] --- alexeymelnikov has joined
[10:02:47] <Glenn Parsons> Hey... I can turn on iCHat liek we did in Beijing ....
[10:03:42] --- ams has joined
[10:03:56] <Dave Cridland> If we haven't started yet, has anyone been looking at EAI's initial ideas?
[10:04:03] <arnt> EAI?
[10:04:09] <Dave Cridland> Email Address I18n.
[10:04:11] <hawbrook> Email Address I18N
[10:04:57] --- robsiemb has joined
[10:05:03] --- NFreed@jabber.org has joined
[10:05:08] <hawbrook> EAI is a new WG: plans to allow email address localparts and domain-names to be raw UTF-8
[10:05:17] --- smaes has joined
[10:05:17] --- greg.vaudreuil has joined
[10:05:19] --- tonyhansen has joined
[10:05:21] --- resnick has joined
[10:05:31] <Dave Cridland> I noted large amounts of wanting to switch from RFC2047 header encoding to UTF-8 in the slides, which made me think it might make the header generation from envelope concept a little nicer.
[10:05:40] <Dave Cridland> But anyway...
[10:05:42] --- cnewman@jabber.org has joined
[10:05:49] --- kmurchison has joined
[10:06:10] <pguenther> slide #?
[10:06:19] <robsiemb> 18
[10:06:23] <robsiemb> (chairs slides)
[10:06:26] <pguenther> is there a second set of slides?
[10:06:29] <tonyhansen> bash agenda - whack whack
[10:06:37] <cyrus_daboo> Some more are on the way
[10:07:04] <tonyhansen> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
[10:07:18] <tonyhansen> agenda will start from OMA liaison response
[10:07:33] <hawbrook> slide #19
[10:08:10] <Glenn Parsons> revised slides are uploaded.
[10:10:05] <tonyhansen> glenn/eric discussing when response is needed
[10:10:33] --- lisaDusseault@jabber.psg.com has joined
[10:10:41] <tonyhansen> not doing these things
[10:12:50] <tonyhansen> greg: a few audio needed: amr, qself, edrc for generating; ipr not too onerous
[10:13:03] <tonyhansen> eric: difficult to get amr license 1.5 yrs
[10:13:28] <tonyhansen> stefan: don't mandate as 'must support'
[10:13:40] <Glenn Parsons> codec - AMR, QCELP, ..
[10:13:49] <tonyhansen> server may provide other conversions as well
[10:14:24] <tonyhansen> chris: we have experience that trivial ipr can even be a stumbling block
[10:14:49] <tonyhansen> greg: oma mem profile may tighten this up
[10:15:29] <tonyhansen> ted: we needed these as input, but handsets already support those, so these are a list of output formats
[10:15:42] <tonyhansen> (concurrence)
[10:15:49] <Dave Cridland> Ah, just realised that the PPT and PDF versions of "chair's slides" are different. Are they meant to be?
[10:16:23] <tonyhansen> greg: ouside mobile box, want "mandatory to implement" into g7, which is unencumbered
[10:16:49] <tonyhansen> greg/ned/glenn: flashback to vpim
[10:17:07] --- resnick has left: Disconnected
[10:17:18] <tonyhansen> greg: take vpim learnings, least common codec is g7-11
[10:17:44] <tonyhansen> greg/glenn/chris: to g7-11, so what from?
[10:18:48] <Dave Cridland> Ogg/Vorbis, of course, is also unencumbered, so qualifies as a potential From or To. Implementations exist for some mobile platforms as well.
[10:18:49] <tonyhansen> chris: need non-null set for "from"
[10:19:03] <keithmoore> .
[10:19:11] <tonyhansen> chris: need omething to demo interop
[10:19:17] <tonyhansen> ted: (missed it)
[10:19:55] <tonyhansen> ted: pick one for from to demo interop, and let oma extend the list of from
[10:20:35] <tonyhansen> greg/glenn/eric: converging on what is mandatory to impl.
[10:21:06] <Dave Cridland> Wait - what is the point of HTML=>text? Most mobiles handle HTML, these days.
[10:21:11] <tonyhansen> greg: we're not suggesting these to oma as what they should require, but useless for anything to proving interop
[10:21:38] <tonyhansen> (if anyone wants me to channel something, start your sentence with "Please channel")
[10:22:09] <tonyhansen> glenn/stefan going around
[10:22:41] <tonyhansen> chris: html => text is useful outside of mobile
[10:23:08] <tonyhansen> glenn: where are details? stefan: no details yet
[10:23:43] <tonyhansen> stefan: understand para, headings, etc., main issue is tables
[10:23:56] <tonyhansen> glenn: reiterate that oma profile can extend our list
[10:24:06] --- lyndon has joined
[10:24:19] <keithmoore> as convert is an optional feature, does there really need to be an MTI set of conversions?
[10:24:42] <tonyhansen> glenn: as server implementor, why do I need to implement html => text
[10:24:52] <tonyhansen> (oops, greg)
[10:24:53] <arnt> (dave: html->text is useful, we do it. gives you something sensible to search on, for example.)
[10:25:06] <tonyhansen> ned: we need MTI to get through process
[10:25:07] <Dave Cridland> Keith: Alternately, if there is adequate support for discovering supported conversions, do we need MTI anything?
[10:25:37] <keithmoore> seems like we need MTI for mandatory features. we need to be able to do interop testing, but that's not the same thing as having MTI conversions.
[10:26:02] <Dave Cridland> Arnt: But the only mails I get that only have HTML, without a plain text alternative, are spam.
[10:26:12] <tonyhansen> eric: make html => text the only MTI, others are discoverable
[10:26:21] <keithmoore> maybe we need an MTI spam->ham conversion :)
[10:26:39] <tonyhansen> (spam, spam, spam, hum along with me)
[10:26:53] <Dave Cridland> Keith: I think you need a more generic system, that can also extract useful conversations out of the IETF public list. ;-)
[10:26:59] <tonyhansen> stefan: value of image was tsting extra params
[10:27:31] <tonyhansen> chris: (joke)
[10:28:05] <tonyhansen> eric: are there parms for html=>text
[10:28:10] <tonyhansen> stefan: will investigate
[10:28:30] <tonyhansen> chris: obvious parm is width
[10:28:34] <keithmoore> seems like this whole discussion is predicated on a dubious assumption - that we need an MTI conversion. I don't see how failure to specify an MTI conversion harms interoperability of the protocol.
[10:29:05] <Dave Cridland> Keith: I agree, actually.
[10:30:01] <tonyhansen> eric: recap: MTI is html => text, (broad applicability), other multimedia types could be suggested by oma profile
[10:30:50] <tonyhansen> greg: this set of media is mobile specific, so approp for oma
[10:30:53] --- hardie@jabber.psg.com has joined
[10:31:15] <tonyhansen> (reminder: if you want me to channel anything, please add "please channel" to what you write)
[10:32:08] --- resnick has joined
[10:32:11] <arnt> it's more fun to mutter and heckle in the back row.
[10:32:22] <tonyhansen> stefan: could also consider other transformations: compression. stefan will write text
[10:32:28] <smaes> mutter and heckle :)
[10:32:46] --- dcrocker has joined
[10:32:48] <tonyhansen> (that's why I want an explicit token grabber, so I can ignore the peanut gallery otherwise. :-) )
[10:32:59] <keithmoore> (mutter) seems like what we need is not an MTI conversion set, but a conversion set that people agree to implement for the sake of interop testing of the conversion feature.
[10:33:11] --- john.levine has joined
[10:33:24] <tonyhansen> glenn: need to craft text by end of this week or early next week
[10:34:18] <cnewman@jabber.org> Keith, given how many times I've seen the "HTML email is evil" debate, it seems like making HTML to text an MTI will simply be goodness for the Internet mail community. :-)
[10:34:34] <tonyhansen> switch slide sets: lemonade update for oma #2 (?)
[10:35:18] <tonyhansen> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
[10:35:22] <Dave Cridland> Chris: But if that issue is cured, we'll be forced to invent an entirely new pointless debate.
[10:35:23] <tonyhansen> just uplaoded
[10:35:28] <lyndon> [tony: please remind folks to speak *into* the microphone -- it's really hard to hear everyone except Stephane]
[10:35:38] <tonyhansen> (will do)
[10:35:40] <lyndon> thx
[10:36:03] <lisaDusseault@jabber.psg.com> Entirely new pointless debates crop up naturally, everywhere, like dandelions.
[10:36:36] <Dave Cridland> Lisa: True. We could do f=f, proper references/in-reply-to headers, etc.
[10:36:43] <lisaDusseault@jabber.psg.com> There is certainly no principle of conservation of pointless debates. There may even be a principle of multiplication of pointless debates for any given group starting from zero.
[10:37:52] <tonyhansen> not working on green stuff
[10:38:09] --- Esemwy has joined
[10:38:33] <tonyhansen> non-lemonade imap4 store
[10:38:35] --- randy has joined
[10:38:42] <arnt> tony: "not working on green stuff"?
[10:38:42] <Dave Cridland> The magic term was advanced (sufficiently, of course) in London interim, actually.
[10:38:46] <tonyhansen> shows notifications
[10:38:49] <keithmoore> okay, which set of slides (from the datatracker page) is actually being viewed?
[10:39:03] <Dave Cridland> Last ones.
[10:39:07] <Dave Cridland> Newly added.
[10:39:30] <ams> arnt: s/not/now/
[10:39:33] <keithmoore> (sigh) it's in PPT. are people still using that crap?
[10:39:55] <Dave Cridland> keith: Works okay in OpenOffice.
[10:40:03] <tonyhansen> (takes a few minutes for auto ppt=> pdf to occur)
[10:40:20] <tonyhansen> how oma lem server would use
[10:40:29] <tonyhansen> slide #17 is refs
[10:40:40] <Dave Cridland> Note to self: POSTADDRESS requires LIST-EXTENDED
[10:40:55] --- resnick has left: Disconnected
[10:41:16] <tonyhansen> greg: soem encryption rqts cannot be met by current protocols
[10:41:17] <robsiemb> maybe PPT -> PDF should be the MTI conversion
[10:41:23] <keithmoore> :)
[10:41:24] <Dave Cridland> :-)
[10:41:38] <keithmoore> though these days PDF is almost as evil
[10:41:42] <tonyhansen> glenn: stefan will present more later
[10:41:52] <robsiemb> PPT -> text then
[10:41:53] <tonyhansen> greg: lemonade profile 3?
[10:42:26] --- resnick has joined
[10:42:28] <tonyhansen> chairs: will talk encrypt later
[10:42:37] --- hawbrook has left
[10:42:43] <tonyhansen> chairs: are these slides okk to present to oma? (yes)
[10:42:44] <keithmoore> PPT->html would be quite useful
[10:43:02] <tonyhansen> chair's slides now
[10:43:07] --- jonathanclark has joined
[10:43:30] <Dave Cridland> Keith: I wonder if PPT->HTML and HTML->TXT both being available implies that PPT->TXT is available?
[10:43:50] <tonyhansen> chairs: asking for implementors
[10:44:00] <Dave Cridland> Sorry, implementing what?
[10:44:06] <keithmoore> offhand, I don't think it should necessarily mean that.
[10:44:17] <tonyhansen> alexey: dependencies are wrong: no sort, i18n or annotate
[10:44:48] <tonyhansen> (people): need abnf and expunged
[10:45:25] <Dave Cridland> Ah, implementing RECONNECT? I'll do that within ten minutes of access to a server implementation.
[10:45:27] <keithmoore> which slide are they on?
[10:45:33] <smaes> 25
[10:45:50] <Dave Cridland> Keith: 25, but it may only be the PPT version of the Chair's slides.
[10:45:55] <tonyhansen> (keith: can you see the current "topic" title?)
[10:46:04] <keithmoore> (no)
[10:46:15] <tonyhansen> (sigh; I've been using that to indicate where we're at)
[10:46:17] <smaes> Title: Reconnect issues
[10:46:25] <keithmoore> (yeah, the slide #s of the pdf version don't seem to match)
[10:46:41] <tonyhansen> chairs' slide #25
[10:47:12] <keithmoore> it's slide # 16 on the pdf version. presumably this means that the pdf is out of date
[10:47:40] <Dave Cridland> Channel: Why is deleting the current session needed?
[10:48:05] <tonyhansen> barry: must be robust enough, so why need logout?
[10:48:10] <Dave Cridland> Channel: Or is that deleting a different session? And why do that?
[10:48:36] <tonyhansen> barry: don't need logout
[10:49:23] <tonyhansen> ned: logout does not preserve sessions, but parm lets it do that
[10:49:55] <tonyhansen> randy: logout is friendlier, cause svr can immediately release tcp session
[10:50:44] <tonyhansen> tim: send this stuff to list
[10:51:05] <pguenther> the TIME_WAIT state exists on the side that closes the connection _first_, so LOGOUT tends to put the TIME_WAIT state in the server
[10:51:14] --- dcrocker has left
[10:51:47] <pguenther> so arguments about LOGOUT(PRESERVE) being cheaper for the server are backwards
[10:51:50] <arnt> dave: to implement reconnect, we'd use RAM for a long time to keep the sessions around. we wouldn't like to to incur that cost for any old disconnect.
[10:51:51] <tonyhansen> cyrus: unfair on clients that know how to do this, ... so saying worst case is 20k
[10:51:59] <tonyhansen> barry: channelling phil's comment
[10:52:43] <pguenther> thanks Barry
[10:52:53] <Dave Cridland> Arnt: I'm thinking DELETESID, not a formal LOGOUT.
[10:52:58] <tonyhansen> barry: imap didn't make any decisions at end
[10:53:17] <tonyhansen> eric: alexey will take to list, and call for implementations
[10:53:24] <tonyhansen> slide #26 2192bis
[10:53:44] <arnt> dave: what I mean is that we want a sign that the client will want the session. if the client doesn't give us a sign, the cost of remembering the sessions is prohibitive.
[10:53:48] <tonyhansen> alexey: did cleanup
[10:53:56] <Dave Cridland> As I say, I have all the prereqs done for RECONNECT, so when I see a RECONNECT server, I'll do the client side.
[10:54:11] <pguenther> Arnt: but then you can't do reconnect for unexpected drops
[10:54:30] <pguenther> or you just mean that plain LOGOUT doesn't preserve
[10:55:10] <randy> Is client sign early in session enough?
[10:55:16] <arnt> for me, yes.
[10:55:44] <arnt> I just want to ensure that we don't incur server cost for every laptop whose lid is closed while running outlook.
[10:56:06] <tonyhansen> slide #27 2192bis issues
[10:56:08] <Dave Cridland> Arnt: RECONNECT requires a client to say it wants a SID, but after that, the default is to persist it.
[10:56:14] <arnt> fine
[10:57:17] <tonyhansen> ted: reasonable to include imap url ext
[10:57:18] <pguenther> already breaking people by adding partial
[10:57:24] <tonyhansen> greg/alexey: discussing
[10:57:35] <Dave Cridland> Channel: There's a difference between knowing how to parse the URL and knowing how to process it, though.
[10:58:08] <tonyhansen> chris: combine drafts
[10:58:18] <pguenther> or rather, if an imap URL generator uses partial, a 2192 imap URL processor will choke
[10:58:22] <tonyhansen> eric: agree
[10:58:46] <tonyhansen> (agreement in room, shades of vpim
[10:59:06] <tonyhansen> greg: how does client know which url auths ar supported by svr?
[10:59:26] <tonyhansen> greg: what does compliance mean?
[11:00:11] <tonyhansen> greg: so it's a closed loop within a trio
[11:00:16] <tonyhansen> (concurrence)
[11:00:29] <tonyhansen> slide #28: encryption
[11:01:46] <tonyhansen> glenn: need to understand notification encryption
[11:02:12] <tonyhansen> randy: what does oma want? glenn: most import is notif encrypt
[11:02:38] <pguenther> there is part of object encryption that we haven't figured out: how to forward-without-download the content of an S/MIME message, decrypting or re-encrypting
[11:02:46] <pguenther> we talked about this in, uh, Minneapolis?
[11:02:48] <tonyhansen> randy: at beijing, some concern about signing, but not encrypt
[11:03:55] <tonyhansen> stefan: both aspects are correct; worry about denial of service; oma paris confirmed interest in encrypt; even uid may need to be confidential
[11:04:13] <tonyhansen> ned: please explain why not vulnerable to man-in-the-middle attack?
[11:04:40] <tonyhansen> ned: no integrity protection, so can't prevent anything
[11:05:01] <tonyhansen> ned: security issues abound
[11:05:50] <tonyhansen> randy: in beijing, we talked about use sasl digest
[11:06:17] <tonyhansen> greg: maybe we don't care about mitm; if need integrity, use imap tls
[11:06:28] <randy> sasl digest provides session keys that can be used to encrypt/sign subsequent notifications
[11:06:37] <tonyhansen> greg: may get false preview, at most
[11:06:46] <tonyhansen> ned: why do it at all then?
[11:06:55] <tonyhansen> greg: eavesdropping
[11:07:09] <tonyhansen> greg: mitm could substitue info, but couldn't view info
[11:07:51] <tonyhansen> ned: do we worry about mimt too much? but security area may feel otherwise.
[11:07:55] <keithmoore> you really can't evaluate efficacy without a threat model
[11:08:14] <pguenther> the existence of BTNS may mean security area has gotten the point that Ned just mentioned
[11:08:16] <tonyhansen> tim: evil twin may generate notif msgs causing DOS attack
[11:08:36] <tonyhansen> tim: so ??? didn't do it at all
[11:08:45] <Dave Cridland> Phil: Are you following BTNS?
[11:09:17] <tonyhansen> stefan: if notif contains important info, then make sure no eavesdropping; DOS attack
[11:09:38] <tonyhansen> stefan: would have been better to have notific with no info other than poking you
[11:09:49] <tonyhansen> stefan: but oma wants more
[11:10:06] <tonyhansen> eric: is oma wrong headed?
[11:10:24] <tonyhansen> (oops; tim above should be corby)
[11:10:32] <pguenther> does the OMA have a threat model?
[11:10:43] <tonyhansen> stefan: not like recall issue
[11:10:50] <pguenther> (that they just haven't mentioned to us...)
[11:11:14] <tonyhansen> greg: want to match deployed services elsewhere
[11:11:40] <tonyhansen> eric: we don't have draft on notif encryption
[11:11:55] <tonyhansen> stefan: we specificy something and handwave rest
[11:12:24] <tonyhansen> stefan: issue is how key is exchanged
[11:12:59] <tonyhansen> eric: for minutes, remind chair to talk to security ADs, if reqts are confid but not integrity, would that be sanctionable?
[11:13:41] <tonyhansen> stefan's slides day 2; slide #2
[11:14:58] <tonyhansen> slide #3: operator proxy deployment model
[11:16:36] <tonyhansen> randy: who is customer in 1st bullet?
[11:17:01] <tonyhansen> stefan: op wants relationship with client customer,
[11:17:28] <tonyhansen> randy: are 2 endpoints non-lemonade and client? (yes)
[11:18:03] <tonyhansen> slide #4: problem: security
[11:18:35] --- dcrocker has joined
[11:19:19] <tonyhansen> slide #5: object level encryption
[11:19:34] <robsiemb> ooooh, ENCRYPTEDLITERAL8MINUSPLUS
[11:20:31] <tonyhansen> greg: upstream path is not encrypted?
[11:20:52] <tonyhansen> cyrus: client can use literals, and can encryp t that
[11:21:07] <tonyhansen> ned: but know search is going on
[11:21:17] <tonyhansen> slide #6: problem: key management
[11:21:19] <keithmoore> okay, forgive my ignorance - could someone fill me in as to why not just use TLS?
[11:21:40] <Dave Cridland> Keith: Because the network operators want to act as a MITM.
[11:21:48] <Dave Cridland> Keith: For Fun And Profit.
[11:21:59] <keithmoore> so why is IETF trying to standardize this, since it's not for the good of the Internet?
[11:22:15] <arnt> Dave wants consluting income from network operators.
[11:22:28] <keithmoore> so why don't people just walk out and go to lunch?
[11:22:33] <Dave Cridland> Arnt: Income would be very good in virtually any form. :-)
[11:22:52] <keithmoore> can't say I'd mind having a new source of income myself...but I want to do honest work.
[11:23:09] <tonyhansen> barry: have we consulted with security ADs about lemonade definitng new encrypt protocol?
[11:23:30] <tonyhansen> stefan: have to start somewhere
[11:23:36] <tonyhansen> barry: could be non-starter?
[11:23:49] <tonyhansen> randy: how aware is client they're talking to two entities
[11:23:54] <tonyhansen> stefan: not at all
[11:24:34] <resnick> Shades of OPES considerations?
[11:24:53] <keithmoore> pete: sort of looks that way...
[11:25:47] <tonyhansen> chris: security AD will like idea, but don't do adhoc design here
[11:26:18] <tonyhansen> chris: assume client cannot bypass proxy , way to make this work is public key. proxy cannot interfere other than DOS
[11:27:03] <tonyhansen> chris: we have pgp and s/mime, to leverage PK. leverage PGP or s/mime without wrappers
[11:27:10] <tonyhansen> stefan: likes idea
[11:28:02] <tonyhansen> jim: in this model, enterprise svr won't want to implement all this new functionality
[11:28:26] <Dave Cridland> Has the audio gone all funky for anyone else?
[11:28:42] <Dave Cridland> Oh, never mind, it's cleared up.
[11:28:44] <resnick> Echo.....echo
[11:28:49] <resnick> Yeah, better now.
[11:29:06] <tonyhansen> stefan: business model in proposal, best soln is to not have this problem, but operator wants to own relationship, so offer with minimal impact on server
[11:30:17] <tonyhansen> eric: does usoft xchange already support what hasn't been invented yet? (????)
[11:30:52] <tonyhansen> stefan: todays' solutions provide equiv solutions in proprietary way
[11:31:02] <tonyhansen> stefan: proxy is part of enterprise server
[11:31:06] <keithmoore> is the assumption that the operator proxy is an interception proxy?
[11:31:30] <NFreed@jabber.org> I characterize this as "in order to avoid changing the enterprise server, we're going to change the enterprise server"
[11:31:49] <keithmoore> ned:...in a different and less-compatible way
[11:32:00] <tonyhansen> jim: can I set up the operator network, to send back msgs to usoft xchange, without changing backend?
[11:32:30] <Dave Cridland> Ned: I characterise this as "We are contributing of our time and effort in order to let the networks fleece us even more than they do already", but then, I'm cynical.
[11:32:31] <pguenther> oh goody, we're up to 2 proxies now
[11:32:34] <tonyhansen> greg: no, non-lemonade will use TLS, value adde services will need lemonade support in back
[11:32:36] <keithmoore> gotta love the model where you bill for a service without adding value
[11:32:49] <tonyhansen> slide #7
[11:32:52] <Dave Cridland> Keith: Like I said.
[11:33:10] --- lisaDusseault@jabber.psg.com has left: Logged out
[11:33:22] --- greg.vaudreuil has left
[11:33:29] <keithmoore> my real question is why we allow proposals like this to consume precious meeting time...seems like the appropriate remedy involves tar and feathers.
[11:34:42] <tonyhansen> ned: understands greg but doesn't buy it. creating this differeint thing will be more complicated than doing it write. greg is saying there's a split piece with two gizmos that implements pieces of lemonade
[11:35:05] <tonyhansen> greg: existing world is there already is a split proxy model
[11:35:20] <pguenther> that gizmo is an ugly, complicated thing too, modding protocol stream as it goes
[11:35:21] <pguenther> ugh
[11:35:59] <pguenther> they also add points-of-failure
[11:35:59] <keithmoore> now I seem to be hearing that people are proposing that IETF standardize ways to work around MS brain damage.
[11:36:00] <tonyhansen> ned: but that's wrong world view; customers don't want these extra boxes and and want to dump it, paticularly large customers (financial especially)
[11:36:13] <tonyhansen> eric: so they'll buy lemonade servers
[11:36:28] <tonyhansen> greg: wants world view where we do TLS, but not sure how to get ther
[11:36:54] <tonyhansen> jim: other hat (security world): red flags all over the place; this is DOA
[11:37:31] <tonyhansen> randy: if you can convince customer to deploy gizmo, why not convince them to upgrade server instead?
[11:37:54] --- hardie@jabber.psg.com has left
[11:37:56] <tonyhansen> randy: lemonade will benefit *all* users, not just mobile: desktop, dialup, everyone
[11:38:14] <keithmoore> agree with randy. I can see why the customer might prefer to have a lemonade proxy on site rather than upgrading server immediately, but creating a role for the operator is Just Wrong
[11:38:21] <tonyhansen> greg: tell oma to "this req't doesn't work in our world"
[11:38:30] <Dave Cridland> Randy: As someone who's implemented Lemonade on the desktop, I agree entirely.
[11:38:51] <randy> Thanks, Dave. Glad to hear you've done a desktop client impl.
[11:39:52] <tonyhansen> chris: use case, likes protocol level object security, suppose provider has imap proxy lets you access local shared folders, and also access remote inbox not under provider control. if we want proxy to (lost it). this is an interesting thing to do, but not part of lemonade profile
[11:40:27] <tonyhansen> stefan: wanted to get us to start thinking about this;
[11:40:38] <Dave Cridland> Randy: I should do more self-publicity. I've had that done for a while. Does full ACAP too.
[11:41:00] <randy> chris: in use case, we want proxy to be able to me data from my imap store, and we trust proxy to do basic imap proto, but we don't trust proxy with actual data
[11:41:12] <randy> (just filling in what Tony missed)
[11:41:15] --- Esemwy has left
[11:41:41] <tonyhansen> stefan: not limited to address lemonade; we should disassociate this problem of studying proxy from object level encryption;
[11:42:05] <randy> Dave -- there's some revenue op for you -- license sw
[11:42:09] <tonyhansen> eric: respin, need coauthor from security
[11:42:10] <keithmoore> offhand it seems like chris's use case is a fairly marginal one...how often would people actually need this?
[11:42:37] <tonyhansen> ned: who is security AD? (ecker)
[11:43:13] <randy> keith -- I think Chris' use case is operator-provided universal inbox, but maybe I misunderstand it
[11:43:19] <tonyhansen> glen: eric will close loop. also note we'll split proposals.
[11:43:46] <Dave Cridland> Randy: I licensed it GPL ages ago, when I started it. :-)
[11:43:54] <NFreed@jabber.org> Tony: I was asking about security area advisor, not the AD. Each WG (in apps at least) is supposed to have
[11:44:02] <tonyhansen> stefan: in oma discussion, proxy has richer variations than what was presented here.
[11:44:02] <Barry Leiba> s/ecker/ekr/ == Eric Rescorla
[11:44:05] <tonyhansen> (sorry ned)
[11:44:08] <keithmoore> seems like before a WG invests significant effort in this it should at least have a convincing use case
[11:44:12] <NFreed@jabber.org> a designated area advisor. This concept rarely works well in my experience, but it is there.
[11:45:08] <tonyhansen> greg: if look at arch picture, oma wants vf/nf on proxy, and df/af in enterprise. hwo you controlthe filter sets, get different assumptions, re sieve. we need more analysis.
[11:45:48] <tonyhansen> chairs' slide #31
[11:45:55] <tonyhansen> glenn: any issues on profile?
[11:46:07] <tonyhansen> stefan: in monday's slides
[11:46:30] <tonyhansen> going to stefan's first day slides, slide #2
[11:46:33] <pguenther> OMA just loves to multiple the entities; haven't they heard of Ockham's razor?
[11:47:00] <keithmoore> so OMA ends up taking the place of the IESG in determining lemonade's charter?
[11:48:15] <tonyhansen> slide #3
[11:48:21] <tonyhansen> slide #4
[11:48:25] <randy> I think Ned's point was on point here: that he hears from many customers (especially financial institutions) that they are sick of constantly being required to deploy new widgets and services for each new requirement, on new boxes etc.
[11:49:02] <robsiemb> Chris's use case seems to assume that (a) the client can't reach multiple imap servers (b) the client can't configure multiple imap servers, are these real assumptions?
[11:49:16] <tonyhansen> slide #5
[11:49:31] <Dave Cridland> Rob: GIven the control asserted by some networks on the software available on the handsets by default...
[11:50:09] <pguenther> so it's a way to enable networks to continue to screw TCP/IP users
[11:50:22] <keithmoore> rjs3: maybe for a mobile handheld device. but that doesn't mean we should standardize it. sometimes we have an obligation to say no
[11:50:41] <robsiemb> Yes, I agree.
[11:50:51] <tonyhansen> no discussion; back to chair's slide #31
[11:51:14] <robsiemb> (with phil and keith)
[11:51:19] <tonyhansen> glenn: profile bis discussion will continue on list
[11:51:24] <tonyhansen> slide #32: futuer delivery
[11:51:41] --- jr111 has joined
[11:51:55] <randy> Chris said he user case was interesting but shouldn't be a wg item
[11:52:01] <randy> s/he/his/
[11:52:51] <tonyhansen> ned: this doc is really not in charter; should have been in vpim; individual contrib so ok
[11:53:05] <tonyhansen> should be "future release" not "future delivery"
[11:53:25] <tonyhansen> chairs' slide #34
[11:53:28] <keithmoore> snicker
[11:53:43] <tonyhansen> #34 firewall traversal
[11:54:37] <Dave Cridland> "TCP-Challenged" - I like that.
[11:54:43] <smaes> :)
[11:55:04] <resnick> It has been brought to his attention indeed! ;)
[11:55:20] <tonyhansen> eric: charter was stretched too far, not an IP network so broken
[11:55:20] <cyrus_daboo> FYI future delivery is draft-ietf-lemonade-futuredelivery-03.txt so it does need to be renamed as an individual submission.
[11:55:30] <tonyhansen> slide #35 "moving forward on tcp-challenged environments"
[11:55:49] <tonyhansen> eric: individual submissions, reviewed by wg, but not in charter
[11:56:11] <tonyhansen> bcp still wg doc
[11:56:46] <tonyhansen> randy: which elements are rsponsible for difficulties?
[11:57:07] --- amarine has joined
[11:57:47] <cnewman@jabber.org> HTTP over MPEG 2? Bletch cough barf....
[11:57:49] <keithmoore> (channel) I think it's important that any such efforts (a) be clearly marked as temporary workarounds that are discouraged in new platforms, and (b) any tunneling mechanism MUST NOT require changes to existing or future standard protocols
[11:58:11] <keithmoore> chris: imap over http over mpeg2!
[11:58:15] <tonyhansen> greg: 3 environments, #1 java cannot open tcp; #2 opentv settop boxes no tcpip (http over mpeg2); cannot remember #3
[11:58:27] <tonyhansen> java mipv2 device or something like that
[11:58:29] <cnewman@jabber.org> Oh my!
[11:58:51] <Dave Cridland> Keith: Recall that you can channel IP over email. :-)
[11:58:55] <cyrus_daboo> java midp part of J2ME (Jave 2 Micro Edition)
[11:59:24] <tonyhansen> ned: glad chair pulled back on this draft.
[11:59:45] <tonyhansen> ned: publishing rfcs on how to deal with bad practices is a good idea, with proper caveats.
[12:00:03] <keithmoore> we really need a class of RFCs that are clearly labeled "least known harmful ways to do inherently bad things"
[12:00:15] <Dave Cridland> Keith: Least Worst Common Practise
[12:00:37] <tonyhansen> ned: word firewall needs to go; not a firewall.
[12:00:47] <keithmoore> dwd: as good as acronym as any
[12:01:25] <tonyhansen> ned: lots of tech details needed. confusion about batch smtp; described opposite of reality.
[12:01:48] <tonyhansen> ned: go with blob approach to batch smtp.
[12:02:00] <tonyhansen> ned: draft needs to settle on specific approach to these tunneling things.
[12:02:19] <tonyhansen> ned: include list of things that are broken, to justify draft's existence.
[12:02:29] <keithmoore> agree with ned. more generally, LWCPs should include a section of "why this is a bad idea"
[12:02:37] <tonyhansen> randy: draft should include list of things that will still be problematic
[12:02:53] --- hardie@jabber.psg.com has joined
[12:03:11] <hardie@jabber.psg.com> I totally didn't get the pamplona reference
[12:03:12] <tonyhansen> randy: include greg's list.
[12:03:15] <Dave Cridland> Keith: And end with Now Wash Your Hands.
[12:03:58] <tonyhansen> chris: do a ??? passthrough on bcp. add extensive refs to ??.
[12:04:06] <tonyhansen> eric: randy and chris get together
[12:04:13] <tonyhansen> chairs' slide #36
[12:04:31] <tonyhansen> (charter dates)
[12:04:33] <cyrus_daboo> In the case where you only have http why not simply build an http client with XML-rpc ajax and give the end user the same experience as they would have had with a native IMAP client?
[12:05:00] <tonyhansen> streaming multimedia is late; s2s draft is gone
[12:05:01] <Dave Cridland> Cyrus: When you have both HTTP and decent bandwidth, yes.
[12:05:16] <keithmoore> cyrus: only much less efficient and slower. but yes, that's the idea.
[12:05:21] <Dave Cridland> Cyrus: The problem is when you have limited bandwidth and only HTTP.
[12:05:31] <randy> Ned also had a point that trying to traverse (i.e., hide from) firewalls is really bad; you'll lose a war with firewall people, and companies take Sarbonnes-Oxeley very seriously
[12:05:41] <tonyhansen> greg: wants details on streaming mm
[12:05:49] <cnewman@jabber.org> RFC 2979 is good reading when it comes to firewalls...
[12:05:51] <Dave Cridland> Randy: What is/was Sarbonnes-Oxeley?
[12:06:14] <tonyhansen> stefan: only change to picture was using RTSP
[12:06:19] <NFreed@jabber.org> FWIW, the specific road to perdition I'm really worried about is we go to email over HTTP, that gets blocked, things shift to using HTTPS, that can't be blocked and can't be inspected but it can be restricted to "good" servers. We could easily end up damaging web security in general here.
[12:06:25] <Barry Leiba> Sarbanes/Oxley is a US law holding corporate officials accountable.
[12:06:25] <cyrus_daboo> Sarbonnes-Oxeley specifies legal privacy requirements for financial information, if I recall correctly.
[12:06:34] <hardie@jabber.psg.com> Or disclosure requirements
[12:06:54] <keithmoore> funny, I was guessing part of the justification for using this was to use a protocol that firewalls already knew how to intercept and filter ... so they could leverage an existing firewall rather than having to have a new one for IMAP
[12:07:08] <tonyhansen> (discussion on who wants to discuss streaming MM?)
[12:07:09] <Barry Leiba> You should be able to google on "Sarbanes Oxley".
[12:07:27] <cyrus_daboo> There is of course also the healthcare equivalent: HIPPA.
[12:07:43] <tonyhansen> (discussion on how to change charter)
[12:07:51] <Barry Leiba> In fact, try http://www.sarbanes-oxley.com
[12:07:54] <Dave Cridland> I get the picture - this is saying "people who hold the chequebooks care deeply about this stuff"
[12:07:55] <randy> Dave -- it's a US requirement that was passed in the aftermath of the Enron et al scandals. In short, it imposes lots of reqs on cos to document their practices and protections
[12:08:18] <cnewman@jabber.org> Sarbonnes-Oxeley is a truly terrible law in the US (in response to Enron) that makes corporate officials criminally accountable for company actions and has vague privacy requirements. US Managers are running around like chickens with no heads, trying to deploy all sorts of security technology and US companies are using SOX FUD to sell crap software.
[12:08:19] <arnt> dave: people who hold the chequebooks are held personally responsible.
[12:08:25] <Barry Leiba> Cyrus: it's "HIPAA"
[12:08:28] <tonyhansen> ted: it's a chance to cleanup charter
[12:09:22] <tonyhansen> glenn: we might eventually want to add more things to charter, but want to finish things off first
[12:09:24] <keithmoore> group needs to go to fin-wait - not add new deliverables
[12:09:29] <NFreed@jabber.org> S-O applies to any publicly traded company, although the requirements as well as the dates when they have to be met vary by company type and size.
[12:10:15] <Dave Cridland> Chatering a new group has the advantage of a new, even siller, name.
[12:10:29] <robsiemb> cranberryjuice
[12:10:30] <keithmoore> koolaid?
[12:10:30] --- greg.vaudreuil has joined
[12:10:30] <greg.vaudreuil> .
[12:10:35] <cyrus_daboo> bandaid
[12:10:42] <keithmoore> because the group is acting like it's on acid
[12:10:50] <randy> pomegranate juice (that would be a fun one to force-fit)
[12:11:43] <tonyhansen> eric: let's finish docs and do reviews, before montreal
[12:12:36] <tonyhansen> chars' slide #40 next steps
[12:13:25] <NFreed@jabber.org> Eleven drafts updated in basically 11 days. Doesn't seem likely...
[12:13:28] <keithmoore> fin-wait is going to take along time, and it's always more interesting to work on new stuff than to finish up existing work. so the group needs to go to fin-wait and finish up.
[12:14:07] <tonyhansen> glenn: next meeting
[12:14:31] <tonyhansen> glenn: do we wait til Montreal, or have interim before July?
[12:14:47] <NFreed@jabber.org> I view the rechartering exercise as a clarification and possibly a scope-limiting exercise, not a means to add new work.
[12:15:09] <tonyhansen> ted: schedule interim, then cancel
[12:15:21] <resnick> :)
[12:15:36] <tonyhansen> dave: monsoon is in bangkok. and Dallas
[12:15:45] <keithmoore> heck, schedule an interim in a _nice_ place, then get the work done beforehand...
[12:15:59] <tonyhansen> barry: get minutes out sooner!
[12:17:01] <hardie@jabber.psg.com> Each interim attendees meets with himself or herself at home....
[12:17:22] --- dcrocker has left
[12:17:23] <tonyhansen> done
[12:17:26] --- hardie@jabber.psg.com has left
[12:17:37] <Barry Leiba> We really have to convince ourselves that the interims accomplish things we would NOT accomplish on the mailing list -- since we HAVE to ratify on the list anyway.
[12:17:41] --- john.levine has left: Logged out
[12:17:41] --- alexeymelnikov has left
[12:17:52] --- randy has left: Logged out
[12:18:01] --- kmurchison has left
[12:18:07] --- NFreed@jabber.org has left
[12:18:10] <Dave Cridland> We could have an interim purely on this thing, too. Or indeed regular high-bandwidth chatter.
[12:18:14] --- smaes has left
[12:18:19] --- Barry Leiba has left
[12:18:29] --- resnick has left
[12:18:31] --- robsiemb has left
[12:19:06] <Dave Cridland> Anyway... Feed the kids and put them to bed ready for IMAPEXT. :-)
[12:19:09] --- Dave Cridland has left
[12:19:26] --- ams has left
[12:19:49] --- keithmoore has left
[12:21:15] --- cnewman@jabber.org has left: Logged out
[12:21:42] --- cyrus_daboo has left
[12:22:55] --- jonathanclark has left
[12:23:14] --- lyndon has left
[12:23:41] --- greg.vaudreuil has left
[12:24:27] --- arnt has left
[12:25:17] --- Fan Xiaohui has left
[12:27:00] --- amarine has left
[12:36:37] --- jr111 has left
[12:39:08] --- frodek has left
[12:41:22] --- tonyhansen has left
[12:41:52] --- pguenther has left
[12:48:22] --- Glenn Parsons has left
[13:11:37] --- Glenn Parsons has joined
[13:12:19] --- Glenn Parsons has left
[13:38:53] --- alexeymelnikov has joined
[14:02:22] --- alexeymelnikov has left
[15:00:33] --- Glenn Parsons has joined
[15:00:46] --- Glenn Parsons has left
[15:03:43] --- dcrocker has joined
[15:13:08] --- kael has joined
[15:48:44] --- kael has left
[16:23:11] --- tonyhansen has joined
[16:23:35] --- tonyhansen has left
[17:16:51] --- dcrocker has left
[19:20:36] --- dcrocker has joined
[20:25:31] --- dcrocker has left