[03:01:46] --- hardie has joined
[03:02:16] <hardie> Good morning
[03:27:18] --- hardie has left
[03:31:37] --- hardie has joined
[03:50:37] --- eburger has joined
[03:50:44] <eburger> hi ted!
[03:50:47] <hardie> Hi eburger
[03:52:04] <hardie> Apparently, we owe a beer to Stefan Strigler
[03:52:30] <eburger> :)
[03:52:44] <hardie> Safari is supported
[03:56:26] --- gustafr has joined
[03:56:34] <hardie> Welcom gustafr
[03:57:13] --- hyland has joined
[03:57:24] <hyland> hello world
[03:58:10] <eburger> welcome all
[03:58:18] <gustafr> All...
[03:58:24] <hardie> Welcome hyland
[03:58:42] <eburger> for the record: we're starting late due to a poorly configured firewall...
[04:00:27] <hardie> Antony Bowsman dropped me a note via email that he dropped off the bridge due to a VoIP error; he will try to join again later.
[04:00:55] <hardie> (He joined the telephone bridge around 9:00, local meeting time)
[04:01:46] --- rjc has joined
[04:01:58] <rjc> finally!
[04:02:17] <hardie> Welcome rjc
[04:04:08] <eburger> Slides live at: http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/
[04:04:23] <eburger> China Mobile presentation: http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/OMA-MEM-2005-0045R02-Business_Model_Study.zip
[04:04:46] <eburger> MEM Requirements: http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/OMA-MEM-2005-0046R01-Mobile_email_RD_Pres_Lemonade.zip
[04:05:07] <eburger> MEM Architecture: http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/OMA-MEM-2005-0047R02-Mobile_email_AD_Pres_Lemonade.zip
[04:05:27] <eburger> Meeting started (REALLY!)
[04:05:40] <hardie> Thanks for the presentation URLs.
[04:06:09] <eburger> k
[04:07:41] <eburger> Unfortunately, the Chairs's slides are not yet posted to the Supplemental site :(
[04:08:08] <eburger> Agenda bashing
[04:10:32] <hardie> I'm still on, muted.
[04:10:44] <hardie> But I'm hearing garble now.
[04:11:40] <rjc> test
[04:11:58] <hardie> your test is visible.
[04:13:32] --- hyland has left: Disconnected
[04:13:56] <hardie> Is anyone in the meeting room still on jabber?
[04:13:59] --- eburger has left: Disconnected
[04:19:21] <hardie> The meeting has started to review the China Mobile presentation on the business case for mobile email
[04:19:33] --- gustafr has left: Disconnected
[04:20:57] --- rjc has left: Replaced by new connection
[04:25:25] --- rcromwell has joined
[04:27:02] <hardie> Welcome rcromwell
[04:27:17] <hardie> Do you have access to the bridge/are you in the meeting room?
[04:27:29] --- gustafr has joined
[04:27:40] <rcromwell> i am in meeting room
[04:27:46] <hardie> okay.
[04:28:25] --- eburger has joined
[04:28:41] <eburger> I'm baack!
[04:29:38] <rcromwell> this jwchat thing seems to timeout if you dont type something for a few minutes, I get network connect timeout/lost in Firefox
[04:30:00] <eburger> That's probably what happened to me. I'll keep jabbering :)
[04:31:05] <rcromwell> i bet the http proxy here probably kills any long lived connections, i guess the jwclient forgot to add a ping/heartbeat to keep the http proxy alive
[04:31:09] <eburger> slide 16 of CM presentation
[04:31:46] <eburger> slide 17
[04:32:44] <eburger> Greg: asking difference between model A and model C
[04:33:01] <eburger> Model C: Everything is owned by Carrier, where A has everything owned by Service Provider
[04:33:35] <eburger> slide 19
[04:34:07] --- shmaes has joined
[04:34:20] <hardie> Welcome shmaes
[04:34:30] <eburger> Welcome Stephane!
[04:35:33] <eburger> slide 20
[04:36:08] <rcromwell> ping
[04:36:26] <hardie> Heartbeat message, or did you need an ICMP_ECHO_REPLY?
[04:36:46] <eburger> I was assuming heartbeat, since he's here
[04:37:09] --- shmaes has left: Disconnected
[04:37:10] <eburger> slide 21 (my slide count is my heartbeat)
[04:37:45] <eburger> slide 23
[04:39:22] <eburger> slide 26
[04:40:04] <rcromwell> yeah, i was heartbeating myself to prevent firefox from losing the connection to the proxy
[04:40:17] <eburger> presentation done...
[04:40:26] <eburger> Questions on the presentation?
[04:41:36] <eburger> coffee :)
[04:41:39] <hardie> What time do you plan to close today?
[04:41:57] --- robsiemb has joined
[04:42:13] <hardie> welcome robsiemb
[04:42:18] <robsiemb> hi ted
[04:42:51] --- hyland has joined
[04:43:55] <eburger> On to Requirements Document Presentation: http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/OMA-MEM-2005-0046R01-Mobile_email_RD_Pres_Lemonade.zip
[04:44:23] <rcromwell> opps, he got timed out
[04:44:40] <hardie> The enabler documents that he lists on slide two are all on the member site; are they also on a publice site?
[04:45:00] <hardie> Or are we getting the summary because they are not yet public?
[04:46:02] <eburger> Not yet public, but will be.
[04:47:27] <eburger> Stephane presenting on requirements
[04:47:39] <eburger> Some updates from OMA meeting in Paris.
[04:48:37] <eburger> Requirements Document itself is at: http://member.openmobilealliance.org/ftp/Public_documents/REQ/Permanent_documents/OMA-RD-MobileEmail-V1_0-20050921-D.zip
[04:49:39] <eburger> review comments coming now; expect to be done next week
[04:49:49] <eburger> looking for approval in Sydney
[04:50:33] <eburger> "Candidate Approval" - some level of stability. Final Approval after real work done (other documents)
[04:50:59] <eburger> Possible, but tough to change once at Candidate Approval level
[04:51:17] <eburger> Mobile email is *defined* as an email enabler
[04:51:19] <hardie> Now we're on slide 4, yes?
[04:51:31] <eburger> However, an *enabler* is just a specification, not necessarily a box.
[04:51:33] <eburger> slide 4
[04:51:36] <eburger> :)
[04:53:10] <eburger> discuss end-to-end
[04:53:19] <eburger> IETF considers end-to-end to be sender to recipient
[04:53:29] <eburger> OMA considers end-to-end to be subscriber to their mail server
[04:53:40] <eburger> "end-to-end" phrase removed from requirements
[04:54:02] <eburger> slide 5
[04:55:45] <eburger> describes use cases
[04:56:30] <eburger> 1. New e-mail arrives
[04:58:08] <eburger> 2. change of e-mail status
[04:58:13] <hardie> DSNs?
[04:58:27] <hardie> MDNs?
[04:59:53] <hardie> okay; clear enough.
[05:00:06] <eburger> no - about flags on messages
[05:00:41] <hardie> (Sorry "clear enough" reflected conversation on the bridge)
[05:00:49] <eburger> use case doesn't special case DSN's & MDN's; probably something to look at later
[05:01:33] <eburger> I get it - my "no" was about the question, not your message that it was clear
[05:02:04] <eburger> 3. viewing e-mail attachements, including content adaptation
[05:02:12] <eburger> 4. sending e-mail
[05:02:25] <hardie> Just lost audio.
[05:02:28] <hardie> back.
[05:03:36] <eburger> 5. filtering rules
[05:04:31] <hardie> lost audio again
[05:05:29] <eburger> 6. DS Sync: syncing, e.g., 3 devices: Phone, Laptop, server
[05:06:32] <eburger> get e-mail on your server; get e-mail when you connect your laptop; can you also use this to sync with phone, locally, not over-the-air
[05:07:33] <hardie> Can you repeat the questions there?
[05:07:47] <eburger> Does this assume DS rules are same?
[05:08:05] <eburger> Answer: not really
[05:08:14] <hardie> Someone on the bridge is not muted, and they are being registered as talking at the same time as the room in London. That's what's causing the cut in and out, I think.
[05:08:34] <eburger> We'll investigate next time it comes on
[05:09:17] --- resnick has joined
[05:09:23] <eburger> Question: does this assume no local IP connectivity?
[05:09:39] <eburger> Answer: correct, no local IP over sync cable
[05:10:27] <eburger> Clarifying quesion: why not use laptop as IP router?
[05:10:40] <eburger> Answer: One of two use cases: either phone goes through laptop (as router), or phone does DS with laptop.
[05:12:35] <eburger> slide 7
[05:12:48] <eburger> 7. e-mail with attachment
[05:14:15] <eburger> 8. forward without download
[05:14:47] <rcromwell>
[05:14:57] <eburger> Question: does the IETF have usecases?
[05:15:17] <eburger> Answer: not like OMA. We do have some descriptions in the Goals Document, however.
[05:15:22] <hardie> Can you remind folks on the bridge how to mute? We've lost audio from you again.
[05:17:46] <eburger> done.
[05:17:52] <hardie> thanks.
[05:18:12] --- rcromwell has left: Replaced by new connection
[05:18:26] <eburger> 9. configuration multiple e-mail accounts
[05:19:58] --- rcromwell2 has joined
[05:20:09] <eburger> Question: Isn't this just a client issue?
[05:20:26] <eburger> Answer: no, because the "enabler" (in the network) may just need to know about this
[05:21:16] <eburger> 10. Replying to messages from different accounts, including having the correct From: address
[05:21:40] --- eburger has left
[05:22:04] <hardie> We have lost audio to the handset again.
[05:22:06] --- eburger has joined
[05:22:13] <eburger> test
[05:22:16] <hardie> please repeat whatever is being said
[05:22:28] <hardie> okay, the audio is back.
[05:22:49] <eburger> I just lost connectivity, too (poor confluence of *it).
[05:23:21] <eburger> 11. Client e-mail events, like DELETE on client, without deleting on server
[05:23:44] <eburger> (message deleted on client should not show up on client again, even if still on server)
[05:24:20] <rcromwell2> next time, if you see me get disconnected, hurry up and type something :) i just reconnected one minute before you :)
[05:24:28] <eburger> 12. filtering rules
[05:25:18] <eburger> Question: Is there an expectation that events other than "new message" are pushed to client?
[05:25:41] <eburger> E.g., I read on laptop; does the "read" state propogate to laptop?
[05:25:45] <eburger> Answer: maybe
[05:26:01] <hardie> bridge not audible again.
[05:26:30] <hardie> really, someone one's phone is crackling, there is breathing, and we hear that, not the London discussion.
[05:27:01] <hardie> I can hear you now.
[05:27:40] <resnick> Same nonsense again.....
[05:29:23] --- rcromwell2 has left: Replaced by new connection
[05:30:01] --- hyland has left: Disconnected
[05:30:06] * resnick eats his raisin bran.....yummmmmmm
[05:30:36] <hardie> what the heck is that?
[05:30:40] --- eburger has left: Disconnected
[05:30:41] <resnick> Feedback. Cool.
[05:30:47] <hardie> niiiice.
[05:31:06] --- rcromwell has joined
[05:31:27] <hardie> I'm off to get caffeine. I'll be back before the 15 minutes are up, if you need me for debugging.
[05:33:39] <resnick> Excellent.
[05:33:42] --- gustafr has left: Disconnected
[05:33:54] <resnick> Just got the little message which said that everyone is muted.
[05:34:58] --- rcromwell has left: Disconnected
[05:36:26] <hardie> thanks
[05:36:53] <hardie> China Mobile just joined the conference
[05:37:21] <resnick> Is unmute *6 as well.
[05:37:23] <resnick> ?
[05:45:07] --- eburger has joined
[05:45:36] <resnick> I take it the current silence on the call is the desired state?
[05:45:48] <eburger> Yes.
[05:45:55] <eburger> I'm back, but some folks are caffinating.
[05:46:00] <eburger> Who from China Mobile joined?
[05:46:10] <eburger> Also, *6 toggles mute/unmute
[05:46:11] <hardie> Sorry, didn't catch the name
[05:46:22] <eburger> We'll ask when folks wander back in.
[05:46:34] <hardie> You may need to repeat that to the bridge, as some folks on the bridge clearly aren't on jabber.
[05:47:08] <eburger> Of course ;)
[05:49:03] --- resnick has left
[05:49:28] <eburger> Could anyone hear what I just said?
[05:49:37] --- resnick has joined
[05:49:57] <eburger> Pete - could you hear me on the bridge c. 20s ago?
[05:49:59] <resnick> Not I.
[05:50:19] <resnick> Now I can.
[05:51:09] <resnick> I did.
[05:51:40] <resnick> Several folks from CM joined.
[05:55:18] <eburger> We're back!
[05:56:40] <eburger> Slide 11
[05:57:05] <eburger> Rob: see http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/OMA-MEM-2005-0046R01-Mobile_email_RD_Pres_Lemonade.zip
[05:58:19] <eburger> Motherhood & apple pie: need to minimize delay and bandwidth usage
[05:59:55] --- hyland has joined
[06:00:01] <eburger> Slide 12
[06:00:26] --- hyland has left
[06:00:44] <eburger> New requirement: events must support "pushing" events to the client as well as "pulling" events by the clients (notification *and* polling)
[06:00:57] --- hyland has joined
[06:01:04] <eburger> New requirement: baseline interoperable media types and formats
[06:01:12] --- gellert has joined
[06:02:32] <eburger> New requirement: mobile enabler must support wireless optimizations (duh)
[06:03:07] <robsiemb> is "wireless environment" something more special than "low bandwidth high latency" for the purposes of the IETF?
[06:03:29] <eburger> Pete: is a reasonable answer to HLF-2 (notifications) to say it already is there?
[06:03:56] <eburger> Answer: not quite, but a lot of it is there (e.g., IDLE)
[06:04:26] <eburger> Clarification: does this mean that the requirements are not really new, but just expanding existing implied requirements?
[06:04:27] <eburger> Yes
[06:04:55] <eburger> slide 13
[06:06:20] <eburger> Answer to Rob's question: includes stuff like intermittent connectivity, IP address changing, roaming issues, intermediaries, etc.
[06:07:33] <robsiemb> ok
[06:07:49] <eburger> Changed "end-to-end" to "client-to-server".
[06:07:49] <eburger> Question: which server?
[06:07:49] <eburger> Answer: mail server
[06:08:23] <robsiemb> (from the IETF persepctive I'd rather see those enumerated specifically rather than lumped into something vague, but I understand why the OMA doesn't do that)
[06:09:13] <eburger> Question: are we talking about secure communications or secure transport?
[06:09:50] <eburger> Answer: secure transport. S/MIME is out of scope for OMA's concept of 'security'.
[06:10:04] <eburger> slide 14
[06:10:46] <eburger> Question: on SEC-8, does anything authenticate server?
[06:10:58] <eburger> Answer: yes
[06:11:32] <eburger> Answer: in fact, client is the end that is not authenticated (hence application-level authentication)
[06:13:17] <eburger> Discussion about distributing root certificates and user certificates; how users are used to accepting expired and self-signed certificates.
[06:16:59] <eburger> still talking about user issues with dealing with certificates
[06:17:22] <hardie> Unsuccessfully attempted to put onto the bridge; the use of self-signed certificates is perfectly adequate for lots of situations, as it provides a bootstrapping mechanism.
[06:17:43] <hardie> Realistically, for lots of uses "the same one as before" is good enough--see ssh as one such use.
[06:20:00] --- hyland has left: Disconnected
[06:20:00] --- gellert has left: Disconnected
[06:20:50] <eburger> Assertion: won't market forces move everyone to get CA-issed certificates?
[06:21:25] <eburger> Ted: not totally valuable, in that what often needs to happen is that I'm talking to the *same* person. Self-signed is OK, so long as it doesn't change.
[06:23:33] <resnick> Ted also said: CA's are not entirely responsible, i.e., "They will only protect you against people from whom they will not accept money."
[06:25:08] <eburger> Question: is this a subscriber problem or a srever problem?
[06:25:13] <eburger> Answer: really is both.
[06:26:59] <eburger> Happy if said, "easy behavior if CA-issued / chain; other behavior if not, but assuming that self-signed is OK (not banned by protocol)"
[06:27:45] <hardie> One aspect of this is that there is no difference between the behavior of "self-signed" and "CA- not recognized"; if your list of known CAs does not include the CA for a particular cert, your procedures are the same as for a self-signed cert.
[06:29:31] <hardie> And in lots of cases, what the client cares about "is the same one as presented last time"--so an enterprise using a self-signed cert validates at "home", and continues to show as valid when accessed from a mobile client. The big red flag goes up if it changes.
[06:29:40] <eburger> And, it would give too much market power to let the service provider control the list of root certificates.
[06:30:04] <eburger> Back to slide 14
[06:30:44] <resnick> (Out-of-band question: When do you folks take your lunch break? Or was that what you did 30 minutes ago?)
[06:31:12] <eburger> Question: SEC-12 (DoS protection) sounds like unimplementable
[06:31:21] <eburger> (1pm local time in London)
[06:31:30] <eburger> Answer: guideline
[06:31:36] <resnick> (thx)
[06:32:53] <robsiemb> alternate answer "protection against" != DoS-proof
[06:34:37] <eburger> slide 15
[06:36:23] <eburger> slide 16
[06:37:31] <eburger> Reworded requirement/split: ADMIN-2 and ADMIN-3; ADMIN-3 on filtering
[06:38:08] <eburger> slide 17
[06:38:17] --- robsiemb has left: Disconnected
[06:39:01] <eburger> Reworded requirement: how much time left for download (!?)
[06:39:16] <eburger> slide 18
[06:40:53] <eburger> USAB-11: MUST support multiple notification mechanisms
[06:41:18] <eburger> Question: could users understand different SMS vs. MMS, Push, etc.?
[06:41:36] <eburger> Not really, but protocol must support multiple methods.
[06:46:25] <eburger> Question: is it realistic to expect network to know whether notifications will be cheap or expensive? Whether I'm "roaming", "roaming with charging", "on WLAN", etc.?
[06:46:37] <eburger> Answer: ... not really, but yes, but not clear how.
[06:47:03] <eburger> Clarification: just need to say rules may have a roaming component
[06:47:24] <eburger> Question: was there requirement for client to process notifications for all supported mechanisms?
[06:47:52] <eburger> Answer: requirement does NOT specify what happens where. It could be at client or server. Specification will happen later.
[06:48:04] <eburger> Remember, this is a "specification" requirement, not a protocol requirement.
[06:50:04] <eburger> slide 19
[06:50:55] <eburger> slide 20
[06:51:30] <eburger> slide 21 (all new reuqirements)
[06:51:40] <eburger> USAB-33: recalling a message
[06:51:55] <eburger> USAB-34: success / fail of recall
[06:53:37] <eburger> More discussion on -33 and -34
[06:56:12] <eburger> Are we talking about recalling "locally" or at recipient's mailbox?
[06:56:24] <eburger> Not solveable at recipient's mailbox.
[06:58:50] <hardie> I'm not Pete, but it's always been "advisory once it's out of my system" in my experience
[06:59:44] <eburger> Pete going over senders-SMTP-receivers
[06:59:54] <eburger> once delivery occurs, out of SMTP "system"
[07:00:04] <eburger> we're asking for sender access to receiver mailbox access
[07:00:28] <eburger> we want to manipulate recipient's (up to now) private store
[07:03:06] <hardie> I disagree with this formulation.
[07:03:49] <eburger> Pete: "owner" of enterprise mailbox isn't user, it is the enterprise, so enterprise has "right" to reach in and delete (recall) message
[07:04:32] <eburger> Ted: "user" is still user.
[07:04:59] <hardie> But the enterprise may have a policy which the user must follow.
[07:05:40] <eburger> Enterprise is saying "I will accept recall requests for users in this enterprise"
[07:05:52] <hardie> One of those might be "accept requests to recall"; it may even have a policy that it does so on the behalf of the user.
[07:06:02] <eburger> not strictly "users are granted recall privileges"
[07:07:29] <eburger> Greg: given I have a system that allows for recall, is it OK to create a standard method for doing recall?
[07:08:33] <hardie> Did I also hear Greg say "and a standard method for indicating support of this?"
[07:09:14] <eburger> Ray: how can we clean up message that has been forwarded for which the original message has been deleted.
[07:10:13] <eburger> Answer: you can't, really
[07:11:06] <eburger> back to our presentation (slide 21)
[07:12:12] <eburger> Question on USAB-37: is this to have server ignore client requests that are too often, or to make client not ask too often?
[07:12:26] <eburger> Answer: requirements do not discuss implementation
[07:15:15] <eburger> Agreed not a lemonade issue
[07:16:38] <hardie> Hmm, I apparently got dropped.
[07:16:59] <eburger> looking to have lunch. back at 2pm London time.
[07:17:26] <hardie> Okay, but you may have to re-start the conference.
[07:17:34] <eburger> Will do.
[07:17:50] <eburger> I think we'll leave it up. My guess is I'll have to restart jabber, however.
[07:18:07] <hardie> Drop a note in jabber when you're back on the phone, please.
[07:18:17] <eburger> not a problem.
[07:18:21] <hardie> thanks
[07:18:30] <eburger> Thanks for putting up with us.
[07:20:36] <resnick> BTW: I have an IAB call at 0800 California, 1600 London. I will be dropping off then.
[07:23:54] --- gparsons has joined
[07:32:16] --- resnick has left: Disconnected
[07:42:17] --- resnick has joined
[07:42:18] <resnick>
[07:43:53] <eburger> ping
[07:43:59] <resnick> pong
[07:44:04] <hardie> pung
[07:45:04] <eburger> cute. We're still 15 minutes away from restarting, just checking connectivity.
[07:45:36] --- eburger has left
[08:06:29] <gparsons> shall we start again in 2 minutes?
[08:06:43] --- eburger has joined
[08:06:55] <resnick> A fine plan.
[08:07:04] <eburger> We're back on-line.
[08:08:19] <eburger> back to slide 22
[08:09:55] <eburger> slide 25
[08:11:56] <eburger> Question: IOP-13: does it mean we have to support POP3?
[08:11:57] <eburger> Answer no.
[08:13:31] <eburger> Question: does it make more sense to consider the requirements reflecting that there MUST be a "box in the middle"?
[08:13:34] <eburger> Answer: That, itself, is the problem.
[08:14:58] <eburger> Discussion homing in on REQUIRING a box in the middle
[08:16:13] <eburger> Deferring this controversial topic
[08:16:24] <eburger> slide 26
[08:18:31] <eburger> Moving on to Architectural Document Presentation: http://member.openmobilealliance.org/ftp/public_documents/mwg/MEM/2005/OMA-MEM-2005-0047R02-Mobile_email_AD_Pres_Lemonade.zip
[08:21:32] <eburger> Greg: can't we punt requirements that are infeasible?
[08:22:14] <eburger> Answer: problem is identifying what is in scope for, e.g., lemonade versus other important requirements, such as those that are addressed by Device Management.
[08:24:36] <eburger> Stephane presenting
[08:24:51] <eburger> Notes that Architectural Design is still a logical decomposition.
[08:25:11] <eburger> One can combine logical boxes in different ways.
[08:25:22] <eburger> slide 2
[08:25:25] <eburger> slide 3
[08:26:23] <eburger> underlying document is at http://member.openmobilealliance.org/ftp/Public_documents/MWG/Permanent_documents/OMA-AD-Mobile_Email-V1_0_0-20050621-D.zip
[08:26:25] <eburger> slide 4
[08:27:36] <eburger> no attempt to make DS interwork with IMAP, for example
[08:27:53] <eburger> if you have DS client, must have DS server; IMAP client -> IMAP server
[08:29:20] <eburger> slide 5
[08:30:56] <eburger> Greg has (OMA) action to draw an alternate to slide 5 (Logical Architecture), showing separate submit and retrieval servers
[08:32:10] * resnick will be back in a few minutes
[08:32:15] <eburger> k
[08:35:14] <eburger> highlighting that "Mobile E-mail Enabler Server" may not be a physical box
[08:36:54] <eburger> I2 (interface between Email server an dMobile E-mail Enabler Server) is a private interface, not subject to standardization.
[08:37:33] * resnick is back with his toast and eggs
[08:37:53] <eburger> Clarification: MEM may issue requirements on the ME-3 interface (Mobile E_mail Enabler Srever to Other Mobile Enablers), to be worked on by other OMA groups.
[08:40:47] <eburger> <Eric takes a call>
[08:42:35] <eburger> slide 8
[08:45:28] <eburger> slide 9, 10, 11
[08:45:30] <eburger> slide 12
[08:46:39] <eburger> slide 13
[08:46:44] <eburger> slide 14
[08:46:53] <eburger> slide 15
[08:48:44] <eburger> slide 16
[08:48:45] <eburger> slide 17
[08:49:46] <eburger> slide 18
[08:49:49] <eburger> slide 19
[08:51:10] <eburger> slide 20
[08:51:12] <eburger> slide 21
[08:52:21] <eburger> Question: isn't what is called a "Proxy" really a "split enabler"?
[08:52:21] <eburger> Answer: yes.
[08:53:33] <eburger> Need to decide whether enabler is transparent or not.
[08:53:36] <eburger> Answer: can defer
[08:54:44] <eburger> slide 22
[08:54:45] <eburger> slide 23
[08:55:11] <eburger> and slide 24
[08:56:14] <eburger> Question: doesn't slide 24 *require* a proxy/enabler?
[08:56:37] <eburger> Answer: proxy is what gets through firewall; mobile enabler does content adaptation, etc.
[08:57:08] <eburger> Question: wouldn't there always be a proxy?
[08:57:21] <eburger> that does stuff like encryption, etc. (under I2 interface)?
[08:57:31] <eburger> Answer: no, because I2 is proprietary and thus out-of-scope
[08:57:33] <eburger> back to slide 22
[08:58:04] <eburger> I2 interface is out of scope, but Proxy - Mobile E-mail server is *not* I2
[08:58:18] <eburger> Proxy - Mobile E-mail Enabler protocol *is* I0
[09:01:04] <eburger> lots of discussion on what is proxy and if in scope for IETF or should be in scope for IETF
[09:01:41] <eburger> slide 25
[09:04:18] <eburger> Any questions?
[09:04:43] <eburger> Question: can we sum up how IETF can assist with all of the architecture deployment models?
[09:04:50] <eburger> Answer: IETF can completely own I0 interface
[09:05:25] <eburger> (I0:ME-1 and I0:ME-2 e-mail client to Mobile E-mail Enabler Server)
[09:05:54] <hardie> Is there anyone there involved in the SMTP work going on in OPES?
[09:06:28] <hardie> They are looking at seive, but are less than convinced that people care about their output.
[09:06:34] <hardie> Tony H. is one of the contacts.
[09:08:23] <eburger> Question: do we want to do formal exchange between IETF and OMA, or informally?
[09:08:58] <eburger> Or, since the OMA documents are public, should IETF just comment?
[09:09:35] <eburger> Jerry (OMA MEM chair): open to do both
[09:10:44] <eburger> Jerry: IETF is more than just lemonade; should OMA be engaged with other groups?
[09:11:37] <eburger> Glenn: same people in multiple groups; could use lemonade as focal point.
[09:13:19] <eburger> Eric raises Ted's issue.
[09:13:58] <eburger> Glenn suggests next liaison goes to multiple work groups
[09:17:20] <hardie> Return 7:37 PDT.
[09:17:30] <eburger> break for 20 minutes; precisely.
[09:27:10] <eburger> .
[09:27:19] <hardie> ..
[09:29:16] --- gparsons has left: Replaced by new connection
[09:29:40] --- gparsons has joined
[09:30:12] <gparsons> 5 minutes...
[09:36:41] --- resnick has left
[09:37:04] --- resnick has joined
[09:37:22] <resnick>
[09:37:26] <hardie> we're back?
[09:38:20] <gparsons> people entering the room with coffe cups still in hand...
[09:38:46] <resnick> I think I forgot my duck.
[09:42:31] <hardie> work plan discussion starting
[09:43:04] <gparsons> Eric shows lemonade model slide...
[09:43:35] <gparsons> slide one of message sent to mailing list
[09:44:14] <gparsons> shows delivery and submit as separate MTAs
[09:44:59] <gparsons> separate retrieval and retrieve 'functions' that implement LEMONADE
[09:45:19] <gparsons> slide 2 shows an implementation choice showing the 'magic' box
[09:46:19] <gparsons> Pete notes that arrows showing direction would add clarity
[09:46:25] <gparsons> since some are unidirectional
[09:46:40] <gparsons> this is the IETF view
[09:47:48] <gparsons> are the IMAP lines 'full IMAP'
[09:48:33] <gparsons> essentially yes.
[09:48:52] <gparsons> it means that any IMAP client can talk to the server
[09:49:23] <gparsons> it would likely be 'LEMONADE IMAP'
[09:49:44] <gparsons> THe MUA would need to support LEMONADE IMAP?
[09:49:50] <gparsons> Or just the enabler?
[09:50:00] <gparsons> Client choice.
[09:50:40] <gparsons> But the client will need to support LEMAONDE to do forward without download
[09:51:54] <gparsons> LEMONADE profile clients can talk to vanilla IMAP servers
[09:52:47] <gparsons> Will LEMONADE be IMAP5?
[09:52:50] <hardie> la la lalalalalalalala
[09:52:52] <hardie> lalalalalalalalla
[09:52:58] <gparsons> No.
[09:53:09] <gparsons> It is a profile.
[09:53:13] <hardie> (let me know when I can open my ears again)
[09:54:01] <gparsons> Mike does not want to negotiate each feature...
[09:54:36] <gparsons> a server must support all of LEMONADE or not
[09:55:14] <gparsons> Eric explains IETF view of capability negotiation.
[09:55:34] <gparsons> looks bad, but it isn't.
[09:56:21] <gparsons> Vidya nervous because of excessive OTA traffic in XDM and presence
[09:57:25] <gparsons> Pete 2 choices to determine if you have a LEMOANDE pair
[09:57:32] <gparsons> 1. you know out of band
[09:57:41] <gparsons> 2. capabilites command
[09:58:24] <gparsons> If its out of band, then this is provisioning
[09:58:46] <hardie> Or you have something in band that you don't need to use if it is provisioned.
[09:59:17] <hardie> So out-of-band, then profile, then capabilitiies, in order of chattiness on the wire and in order of explicitness
[09:59:20] <gparsons> Dwight - knowing the items beyond LEMONADE is going to be harder
[09:59:30] <gparsons> this is going to be compliance an issue
[09:59:35] <gparsons> Mike - this needs to be branded
[09:59:57] <hardie> RFC XXXX compliant is branding?
[10:00:01] <hardie> in this context?
[10:01:11] <gparsons> Greg recalls VPIM branding & compliance
[10:01:59] <gparsons> Dwight speaks to marketing and compliance to OMA MEM
[10:02:05] <resnick> I'm jumping of the call. I'll be Jabber available.
[10:05:23] <gparsons> Mike notes that this picture is differnet than the OMA picture
[10:05:36] <gparsons> there is no split and no proxy
[10:09:05] <gparsons> concern about coordination across multiple groups in IETF
[10:09:32] <gparsons> eg. SIEVE, OPES, IMAPEXT, LEMONADE
[10:09:46] <gparsons> does LEMOANDE coordinate?
[10:10:15] <gparsons> will all the pieces be in the LEMOANDE profile?
[10:10:42] <gparsons> ...
[10:10:56] <gparsons> ...
[10:10:59] <gparsons> test
[10:11:06] <hardie> you're visible
[10:11:44] --- gparsons has left
[10:25:28] <hardie> Can you repeat Greg's last statement?
[10:26:27] --- gparsons has joined
[10:27:03] <gparsons> considerable group discussion creating new slides with colour etc.
[10:27:19] <gparsons> (ps. connectivity went for a few minutes)
[10:27:24] <hardie> Greg's been hard to hear, but his comment on proxies is actually audible.
[10:27:39] <hardie> I heard you making green lines, but of course that didn't help a lot.
[10:28:00] <gparsons> considerable cross table discussion tweaking the slides that were sent out earlier
[10:28:48] <gparsons> will notifications be in LEMAONDE charter or not?
[10:29:03] <gparsons> that will decide what colour it is on the chart :-)
[10:31:16] <gparsons> creation of another implementation that is not IMAP/POP
[10:31:29] <gparsons> and is 'proprietary email'
[10:34:59] <gparsons> Greg - the mobile magic servers are LEMONADE servers
[10:35:08] <gparsons> STepahne - it is too early to make this determination.
[10:35:18] <gparsons> Vidya/Dwight - it is a combination
[10:35:42] <gparsons> the mixture is driven by OMA right now
[10:36:03] <gparsons> hopefully it will be a full LEMONADE
[10:36:18] <gparsons> (after se decide what extensions are in scope)
[10:40:10] <gparsons> LEMONADE will need to complete a realization for the AD items
[10:40:30] <gparsons> Stephane notes it might not be useful to do this for the RD again
[10:41:06] <gparsons> ...
[10:43:09] <gparsons> more discussion about what the figure means ....
[10:43:49] <gparsons> The ambition is that IMAP+whatever is LEMONADE
[10:44:06] <hardie> Are you closing down in a few moments?
[10:45:02] <gparsons> Very soon...
[10:45:12] <gparsons> 10 minutes
[10:46:23] <gparsons> Greg will convert this into a contribution for the AD
[10:47:21] <gparsons> moving onto schedule
[10:47:24] <gparsons> charter review
[10:47:40] <gparsons> work plan
[10:47:58] <gparsons> slide 10 of emailed presentation
[10:48:52] <gparsons> the notifications we are talking about can be viewed as server to server
[10:49:53] <gparsons> OMA MEM requirements are mostly included in phase 1
[10:51:19] <gparsons> phase 1 last call Nov 2005
[10:51:25] <gparsons> phase 2 last call MArch 2006
[10:51:50] <gparsons> phase 2 includes notifications, transcoding and possibly SIEVe
[10:52:16] <gparsons> Greg gives a quick explanation of SIEVE
[10:53:14] <gparsons> it is traditionally used for inbound email but it is an arbitrary langauge
[10:55:25] <gparsons> we are done....
[10:55:27] <gparsons> now logisitics for tomorrow
[10:55:45] <hardie> Post the new telephone bridge info please
[11:00:43] --- gparsons has left
[11:03:54] --- eburger has left
[11:09:20] --- hardie has left
[11:14:50] --- sunny has joined
[11:15:48] <sunny> Is the meeting over?
[11:19:24] <resnick> Yes. Starting again tomorrow.
[11:21:49] --- sunny has left
[11:21:55] --- resnick has left