[10:08:47] --- Glenn Parsons has joined
[10:44:18] --- herve.prigent@jabber.org has joined
[11:33:05] --- Glenn Parsons has left
[11:34:00] --- herve.prigent@jabber.org has left: Replaced by new connection
[11:54:04] --- Glenn Parsons has joined
[12:15:48] --- greg.vaudreuil has joined
[12:57:10] --- Glenn Parsons has left
[12:59:33] --- greg.vaudreuil has left
[13:20:51] --- AaronStone has joined
[13:36:54] --- arnt has joined
[13:45:01] --- AaronStone has left
[13:45:01] --- dwd has left: Lost connection
[13:45:40] --- aaronstone has joined
[13:58:58] --- cnewman@jabber.org has joined
[13:59:03] --- cyrus_daboo has joined
[14:00:17] --- tonyhansen has joined
[14:04:08] --- alexeymelnikov has joined
[14:04:14] --- guenther has joined
[14:06:28] --- barryleiba@gmail.com has joined
[14:06:30] <guenther> arnt, can you hear the audio?
[14:06:36] <guenther> aaron?
[14:06:39] <guenther> anyone?
[14:06:48] <aaronstone> hey there. oh sorry, i haven't connected into the audio yet.
[14:07:07] <aaronstone> i'll actually be in monday morning meetings at work for most of this session.
[14:07:11] --- kmurchison has joined
[14:07:35] --- resnick has joined
[14:07:38] <arnt> philip, I can't hear audio right now.
[14:07:52] --- ddayman has joined
[14:07:57] <arnt> I'm afraid I can't be here all the time tonight. sorry about that.
[14:08:02] <tonyhansen> phil is taking minutes
[14:08:03] <arnt> I'll turn on the audio.
[14:08:06] --- Darryl has joined
[14:08:43] <tonyhansen> bash agenda
[14:10:05] --- sm-msk has joined
[14:12:01] <tonyhansen> on slides, revised slide 5
[14:12:53] <tonyhansen> killing time, slowly
[14:13:28] <tonyhansen> slide 6: doc status
[14:13:45] <tonyhansen> slide 7: docs out of our hands: rfc ed queue or iesg's hands
[14:14:25] --- kdz has joined
[14:15:22] <tonyhansen> chris is covering where the docs in IESG Q are at
[14:15:39] <tonyhansen> pete says annotatemore will recycle once more
[14:16:09] <tonyhansen> slide 8: docs in our control
[14:16:19] --- resnick has left
[14:16:29] <tonyhansen> next up: Dorothy Gellert from OMA
[14:16:37] <cnewman@jabber.org> Pete said imapext-i18n will recycle once more (but annotatemore probably will as well).
[14:16:50] --- barryleiba@gmail.com has left
[14:17:42] <cnewman@jabber.org> IESG document status is public on https://datatracker.ietf.org/idtracker/; anyone can look for documents there, find the status and look up what that status means.
[14:17:48] <tonyhansen> OMA Enabler Development Status
[14:18:05] <arnt> is the volume _extremely_ low on the audio?
[14:18:32] <tonyhansen> better?
[14:18:33] <guenther> were eric and glen easy to hear?
[14:18:45] --- Glenn Parsons has joined
[14:18:58] <arnt> no. this si so weird that I think it must be a problem on my end.
[14:19:01] --- Glenn Parsons has left
[14:19:10] --- Glenn Parsons has joined
[14:19:28] <tonyhansen> OMA requirements overview...
[14:19:58] <tonyhansen> www.openmobilealliance.org/ft/Publice_documents/REQ/Permanent_documents/OMA-RD-MobileEmail-V1_0-20051018-C.zip
[14:20:09] <tonyhansen> ft => ftp
[14:20:23] <tonyhansen> OMA archtectural overview ...
[14:20:36] <Glenn Parsons> DHCP finally gave me an address... perhaps the audio broadcast is challenged as well...
[14:20:57] <arnt> fixed
[14:20:58] <tonyhansen> /ftp/Public_documents/MWG/MEM/Permanent_documents/OMA-AD_Mobile_Email-V1_0_0-20070614-D.zip
[14:20:59] <ddayman> are you saying VoIP ;)
[14:21:33] --- resnick has joined
[14:21:36] <arnt> I am haunted by weird problems these days.
[14:22:39] <tonyhansen> pete: what does MEM server map onto in Lemonade? Dorothy: see next slide
[14:22:59] --- barryleiba@gmail.com has joined
[14:23:29] <tonyhansen> randy: is there a slide to differentiate email protocol vs MEM protocol dorothy: hopefully later slide will make it clear
[14:25:39] <tonyhansen> glen: outbound notification is optional? D: intent is to describe eventually in later phase
[14:26:37] <tonyhansen> D: slide #6: OMA MEM enabler: logical architecture defining green boxes on slide
[14:26:47] <tonyhansen> slide #7: IETF lemonade realization
[14:28:42] <tonyhansen> glen: hashed area should be blue, as well as message store and submit server dark blue are OMA enablers
[14:29:28] <tonyhansen> lemonade: blue, hash in middle MEM server is sitting around message store behavior and submit server behavior
[14:29:30] --- randy has joined
[14:30:18] <tonyhansen> pete: problem w/ slide #6 is with "EMAIL server" glen: slide #6 is high level marketing slide
[14:31:07] <tonyhansen> slide #6 is high level OMA view slide #7 is detail lemonade view
[14:31:25] --- Dave Cridland has joined
[14:31:43] <guenther> <insert arguing about colors here>
[14:32:13] --- kdz has left
[14:32:41] <tonyhansen> <<side bar on which version of slides to use>>
[14:32:54] <sm-msk> <<<loud drilling noises>>>
[14:33:04] <ddayman> that is not a technical problem
[14:33:53] <guenther> there is a periodical loud drilling noise occuring here
[14:34:03] <guenther> make that "periodic"
[14:34:13] <ddayman> For those who aren't here. Dave Crocker went to go beat some construction workers butts
[14:35:57] <resnick> WRT slide #6: The problem I had was that they separate "e-mail server" (which is the SMTP/IMAP/POP environment that doesn't do LEMONADE stuff) and "MEM Server" (which is the LEMONADE stuff). In LEMONADE, we don't talk about those in two separate boxes normally.
[14:36:18] <tonyhansen> slide #8 compares pieces of MEM to Lemonade
[14:37:01] --- dcrocker has joined
[14:37:57] <tonyhansen> glen: asks about mapping of lemonade items to slide #6 lines
[14:39:53] <tonyhansen> randy: on slide #6, is "mem server" a lemonade-compliant server that interfaces with non-lemonade-compliant server, or an entity that could be coexistent with email server d: slide is more generic; could apply to lemonade or DS server there are different ways that could be implemented
[14:40:22] * resnick nods
[14:40:43] --- dcrocker has left
[14:40:47] <tonyhansen> eric: ?s use of email servers: could be microsoft mail server or lemonade server
[14:40:56] --- herve.prigent@jabber.org has joined
[14:41:38] --- dcrocker has joined
[14:41:38] <tonyhansen> slide #9: technical specifications overview wants suggestions on where to fill in blanks .../ftp/Public_documents/MWG/MEM/Permanent_documents/OMA-TS-Mobile_Email-V1_0-20070110-D.zip
[14:42:18] <tonyhansen> dorothy: taking more contributions on lemonade side than OMA DS
[14:43:35] <dcrocker> For those who are or aren't here, ddaymen has me confused with an idiot. Chicago+construction = talk politely.
[14:44:00] <tonyhansen> glenn: ? on notifications being optional does this slide show pieces of option notifications? no: inband are defined, wants to define enough to do interop
[14:44:30] <dcrocker> (I will sometimes consider kicking my cat's butt, but that's about as big an animal as I'll risk.)
[14:44:38] <tonyhansen> glenn: the content transcoding, will that be discussed dorothy: have looked at language transcoding, but haven't gotten anywhere
[14:45:28] <tonyhansen> glenn: what we've done for transcoding is to define a baseline, but more can be defined and OMA will need to define that set
[14:47:09] <tonyhansen> slide #10: development tatus pointers to lots of documents: requirements doc approved as candate in oct 2005, architeture doc review complete jul 17, 07 technical spec (MEM TS) development work has started
[14:47:37] <tonyhansen> slide #11, MEM Enabler: going forward how to progress MEM TS work to completion
[14:48:54] <tonyhansen> glenn: ???
[14:49:01] <Dave Cridland> I did think that existing handsets supported "basic" EMN, though?
[14:49:46] <tonyhansen> dorothy: will be filling in the outline, including ontributions from china on universal unicode format for transcoding
[14:50:52] <tonyhansen> glenn: universal unicode? translates from diff chinese char sets to unicode? dorothy: chinese wants to be able to support unicode, so whatever came in could be translated into unicode handset would only do universal unicode
[14:51:55] <tonyhansen> randy: when speaking about original intent to extending EMN, but no more what is the EMN functioanly needed? dorothy: no, no extensions to EMN for now
[14:53:07] <tonyhansen> dorothy: could be change in membership not pushing for it anymore
[14:54:21] <tonyhansen> randy: what's the diff btw "unicode" and "universal unicode" dorothy: that's how china referred to it, but she doesn't know more
[14:54:58] <Dave Cridland> Randy: I'd have thought asking Fan Xiaohui might yield some useful answers.
[14:55:20] <randy> (Extensions to EMN were to provide additional fields besides URL, e.g., subject or size or attachment or message type)
[14:55:40] <aaronstone> GB 18030:
[14:55:54] <tonyhansen> phil: is it the wacky chinese unicode subset? dorothy: no, not the obscure version pete: chinese govt had 'std' a few years ago, GB18030, that got some traction, and we want to make sure they are NOT referring to it
[14:56:09] <aaronstone> here's an ibm developerworks thing about it: http://www.ibm.com/developerworks/library/u-china.html
[14:56:12] <tonyhansen> GB18030 is a unicode subset
[14:56:25] <Dave Cridland> http://en.wikipedia.org/wiki/GB18030
[14:56:51] <tonyhansen> eric: ask them for more clarifications
[14:57:14] <tonyhansen> (was ted, not eric)
[15:00:41] <tonyhansen> randy: did we get req'ts on language translation? dorothy: no, was unicode eric: why do we really care "what" 'universal unicode' is? isn't it a great use of content transcoding? pete: make sure "we" don't have native support for anything other than regular unicode we don't want to "encourage" GB18030, and want to make sure that's clear ted: a major problem is that some of the transcodings are one way and could create problems
[15:01:34] <tonyhansen> next OMA MWG-MEM SWG meeting is in Korea aug 19-24
[15:02:28] <tonyhansen> vancouver oct 14-19, london december 9-14
[15:05:24] <Dave Cridland> Indeed.
[15:05:32] <Dave Cridland> Both of us could easily show up.
[15:05:37] --- resnick has left
[15:05:43] <Dave Cridland> And have another free lunch, of course.
[15:05:51] <randy> Both of whom?
[15:05:51] <tonyhansen> glenn: can we arrange an invite for Alexey to one of these
[15:06:09] <Dave Cridland> Randy: Me and/or Alexey.
[15:06:34] <tonyhansen> dorothy: want to push forward, get something out soon, and perfect it later
[15:07:40] <tonyhansen> next up? alexey
[15:07:45] <tonyhansen> convert
[15:07:51] <tonyhansen> imap convert
[15:08:43] <tonyhansen> slide #2: open issue -- do we need BODYPARTSTRUCTURE to be returned ...
[15:09:53] --- resnick has joined
[15:10:59] --- galvinjamesm@jabber.org has joined
[15:11:56] <tonyhansen> chris: has suggestion syntax choices that would simplify things by removing redundancies
[15:13:18] <tonyhansen> chris: has other suggestions as well
[15:15:26] <Dave Cridland> On CONVERT - with the original FETCH-style syntax, I could see methods for down-converting during BURL or CATENATE. Is this still possible with the new syntax?
[15:15:27] <tonyhansen> who wants to get rid of non-binary conversions? several who wants to keep non-binary conversions? one rough consensus barry: should usually get rid of non-binary stuff whenever possible
[15:16:01] <tonyhansen> zoltan: was afraid this affected things other than CTE, but withdraws
[15:16:05] <Dave Cridland> Clients always have base64 codecs, because of AUTHENTICATE and (probably) mUTF-7
[15:16:17] <tonyhansen> eric: clarifies
[15:16:56] --- frank has joined
[15:17:21] <tonyhansen> dorothy: is there a req't to throw something away? chris: no, original message is untouched barry: should have something in spec that reminds that binary could have NULs, etc. chris: implementation note barry is volunterred
[15:18:18] <tonyhansen> chris: a security considerations issue with multipart/signed and then ask server to convert, there's no way to get back without downloading again. needs to be mentioned as a consequence
[15:19:09] <aaronstone> well, the server could verify the signature, but the client would have to trust the server. (which sort of defeats end-to-end security, doesn't it.)
[15:19:25] <tonyhansen> ?? something about multiple conversions ??
[15:19:33] <barryleiba@gmail.com> Assuming the server has the certs/keys for that; it might not.
[15:20:02] <tonyhansen> >> from list: Saying that "servers MAY disallow a request to perform multiple different conversions of the same bodypart at once" is an interop problem as clients that request that will get unpredictable behavior if they issue such a command.  It would be simpler to just disallow this altogether.
[15:20:15] <aaronstone> well so then shouldn't we not even touch an encrypted part?
[15:20:24] --- ddayman has left
[15:20:32] --- Lisa has joined
[15:20:32] <tonyhansen> alexey: one more revision to address Chris' comments, then WGLC
[15:20:39] <Dave Cridland> Can someone mention CATENATE/BURL interaction?
[15:20:56] <Dave Cridland> (Although Pete is now more or less mentioning it)
[15:20:59] <aaronstone> (notes to self: oh wait, we're not talking about encrypted, we're talking about signed. *sigh* nevermind.)
[15:21:37] <tonyhansen> convertbis? added new section "fetch convert" syntax
[15:21:53] <arnt> arnt is with us again.
[15:22:35] <arnt> I returned with a bottle of wine and a full belly, the better to enjoy the discussion.
[15:22:37] <tonyhansen> do we need another wglc on convert?
[15:22:48] <tonyhansen> consensus: probably not
[15:23:01] <guenther> arnt: did you bring enough for everyone?
[15:23:01] --- ddayman has joined
[15:23:26] <Dave Cridland> [Alexey in the same timezone as someone else? Never...]
[15:23:39] <tonyhansen> notify
[15:24:26] <tonyhansen> extended NOTIFY cmd to manipulate event list
[15:24:33] --- resnick has left
[15:26:18] --- resnick has joined
[15:28:15] <arnt> (thank you, alexey)
[15:29:16] <tonyhansen> open issues: slide #5
[15:30:41] <arnt> didn't we put what Chris says into the draft?
[15:31:47] <arnt> didn't we take patterns out of the draft, too?
[15:31:54] <tonyhansen> alexey: when the notify cmd should return tagged NO response due to access controls, should it fail or behave as if should not disclose info? chris: SHOULD return NO alexey: what about list of mailboxes? and failing one of them? chris: don't allow patterns? would be simpler alexey: not generi pattern, but one for submailboxes
[15:32:14] <tonyhansen> cyrus: have nonexistent flag, how about adding noaccess flag?
[15:32:23] <tonyhansen> alexey asks for text
[15:32:42] <tonyhansen> slide #6:
[15:34:15] <tonyhansen> alexey: what to do when messageexpunge event is lacking some events don't have corresponding event in draft: not a problem?
[15:35:57] <tonyhansen> randy: could extend message events? alexey: remember access controls? not a big deal? randy: thinks it's fine, except collisions alexey: let registry deal with it? randy: will check draft
[15:36:42] <tonyhansen> alexey: shorten search syntax?
[15:37:23] <arnt> comment on that: seems a poor reason to introduce a dependency.
[15:38:07] <Dave Cridland> arnt: I agree. I think there is some overlap, but I don't see how to sanely reduce it.
[15:38:16] <aaronstone> sounds like barry
[15:38:19] <tonyhansen> randy: back to message events: event registry can handle it through IETF consensus and do it within alexey's draft
[15:38:28] <barryleiba@gmail.com> Que?
[15:38:53] <tonyhansen> eric: do it in an IANA considerations section alexey: ok
[15:38:53] <aaronstone> oh, wow sorry, way off. that's why it's good to be on-mic so we can tell who's speaking!
[15:39:10] <barryleiba@gmail.com> Eric and Randy are speaking. I'm sleep^h^h^h^h^h^hjust sitting here.
[15:39:26] <arnt> dave, we agree 100%
[15:40:01] --- resnick has left
[15:40:08] <tonyhansen> alexey: remove overlap (message-search-criteria) btw NOTIFY and CONTEXT?
[15:40:16] <Dave Cridland> arnt: Although if NOTIFY defined a new search key that meant 'my notify filter', that'd be handy.
[15:40:26] <tonyhansen> and get rid of fetch-atts on MessageNew event?
[15:40:59] <arnt> Dave Cridland: some other document defines such a search key.
[15:41:00] --- resnick has joined
[15:41:07] <arnt> or?
[15:41:08] <Dave Cridland> Someone nudge Alexey with Arnt/my chat here.
[15:41:25] <tonyhansen> chris: he will look at overlap carefully
[15:42:53] <tonyhansen> chris: please look at carefully it now
[15:43:11] <tonyhansen> barry channels dave and arnt
[15:44:42] <Dave Cridland> It means we don't feel there's much overlap, and none worth attempting to remove. A search-key which says "wot I want to notify" allows CONTEXT to reuse the NOTIFY criteria.
[15:45:54] <aaronstone> is someone speaking right now?
[15:46:09] <barryleiba@gmail.com> There was a long gap, while we digested.
[15:46:11] --- Lisa has left
[15:46:24] <Dave Cridland> Aaron: They're stunned into silence by my brilliance. ;-)
[15:46:27] <cnewman@jabber.org> As AD: I have no problem with changes to context at this point in the process (prior to IETF last call), especially if it makes CONTEXT and NOTIFY more consistent and/or less overlapping.
[15:47:56] <tonyhansen> chris: CONTEXT and NOTIFY are complex and hard to get your head around wants volunteers to commit to state technical opinions on the list (be committed)
[15:48:41] <tonyhansen> alexey: has implemented CONTEXT, so not sure interaction is that complex
[15:48:41] <Dave Cridland> One other thing - CONTEXT is not defined in terms of message events, in part because one of its jobs is to transform the new/expunge/flagchange events into context add/remove. So I'm not entirely convinced I now want to make new/flagchange now different again.
[15:49:13] <barryleiba@gmail.com> Daven shall I say that on mic?
[15:49:27] <Dave Cridland> If it makes sense. :-)
[15:50:07] <tonyhansen> chris: phil, can you be stuck? eric: give doc to ???
[15:51:05] <Dave Cridland> This is one of those times I wish the audio was two-way. :-)
[15:51:16] <barryleiba@gmail.com> da
[15:51:17] <tonyhansen> eric: peter is on top of list to be a stuckee
[15:51:22] --- dcrocker has left
[15:51:37] <barryleiba@gmail.com> I don't know why they can't support two-way audio.
[15:52:11] --- sm-msk has left: Logged out
[15:52:48] <tonyhansen> randy: ? on text in -07 regarding a SHOULD
[15:54:25] --- ddayman has left
[15:55:06] <tonyhansen> randy: volunteers to provide text
[15:55:30] --- barryleiba@gmail.com has left
[15:55:40] <tonyhansen> eric: agenda change streaming
[15:56:19] * Dave Cridland looks suitably guilty.
[15:56:25] <tonyhansen> eric: dave was going to write extensions to URL, dave's doc needs to get out soon then streaming draft can go forward
[15:57:26] --- aaronstone has left
[15:57:27] <tonyhansen> and on that note, we're adjourned
[15:57:32] --- resnick has left
[15:57:33] --- tonyhansen has left
[15:57:35] --- galvinjamesm@jabber.org has left
[15:57:38] --- kmurchison has left
[15:57:38] --- frank has left
[15:57:42] --- cnewman@jabber.org has left
[15:58:20] --- randy has left
[15:59:10] --- cyrus_daboo has left
[16:05:26] --- arnt has left
[16:07:15] --- herve.prigent@jabber.org has left
[16:08:36] --- alexeymelnikov has left
[16:14:51] --- David Martin has joined
[16:15:14] --- Glenn Parsons has left
[16:15:31] --- David Martin has left
[16:16:32] --- Darryl has left
[16:46:50] --- guenther has left
[18:40:07] --- alexeymelnikov has joined
[20:15:39] --- alexeymelnikov has left