[02:41:10] --- gusta has joined
[02:41:27] --- gusta has left
[02:42:20] --- gustaf has joined
[02:42:42] --- gustaf has left
[02:43:12] --- gustaf rosell has joined
[02:52:41] --- hardie@jabber.psg.com has joined
[02:52:58] <hardie@jabber.psg.com> Hi gustaf
[02:53:09] <hardie@jabber.psg.com> Are you in the meeting room in London, or remote?
[02:53:27] <gustaf rosell> I'm in Stockholm today (was there yesterday)
[02:54:10] <gustaf rosell> I guess they need to fix the daily network problems for half an hour or so...
[02:55:06] <hardie@jabber.psg.com> I hope today goes a *bit* better on that. By now the drill should be second nature.
[03:01:06] --- Glenn Parsons has joined
[03:06:43] --- Glenn Parsons has left: Replaced by new connection
[03:07:01] --- anabolism@jabber.org has joined
[03:07:11] --- Glenn Parsons has joined
[03:07:13] --- anabolism@jabber.org has left
[03:07:24] --- hardie@jabber.psg.com has left
[03:08:19] --- eburger has joined
[03:09:13] --- eburger has left: Replaced by new connection
[03:09:15] --- Glenn Parsons has left: Replaced by new connection
[03:09:35] --- rcromwell has joined
[03:09:45] --- Glenn Parsons has joined
[03:09:59] --- eburger has joined
[03:10:30] --- rcromwell has left
[03:10:49] --- rcromwell has joined
[03:11:13] --- Randy has joined
[03:11:14] --- Glenn Parsons has left: Replaced by new connection
[03:11:49] <rcromwell> test
[03:12:39] <Randy> [ starting ]
[03:12:41] --- eburger has left: Replaced by new connection
[03:14:04] <Randy> [ day 2...'note well' on board ]
[03:14:28] <Randy> [ review agenda ]
[03:14:42] --- eburger has joined
[03:17:37] <Randy> Recap of yesterday's Profile 2 discussions. Stéphan and Greg V to draft proposal on notifications
[03:19:19] <Randy> Content Transformation.
[03:19:43] <Randy> Eric to write text on streaming; Lyndon to write text on streaming
[03:20:14] <Randy> Stéphan talks about LCONVERT, which handles static (not streaming), and is based on binary FETCH.
[03:20:38] --- rcromwell has left: Disconnected
[03:20:38] --- eburger has left: Disconnected
[03:21:18] <Randy> We have LCONVERT and expired CHANNEL
[03:21:38] <Randy> Starting with LCONVERT since we have proposals now
[03:21:48] <Randy> If no one volunteers for streaming then it'll get dropped
[03:22:37] <Randy> Putting lconvert-01 on screen
[03:25:04] <Randy> Greg talks about lconvert-01
[03:25:11] <Randy> Modifies section headers of fetch
[03:26:09] <Randy> BODY[section-part.LCONVERT (media-type subtype (params) ) ]
[03:27:30] <Randy> params references OMA STI
[03:27:34] --- resnick has joined
[03:27:40] <Randy> OMA STI has overwhelming number of parameters
[03:28:00] <Randy> Can use ANNOTATE to discover possible converts in a folder
[03:28:07] <Randy> (or ANNOTATEMORE)
[03:28:43] <Randy> Conversions may be data-dependent (normally can convery x to y, but if x has z in it, will lose data)
[03:29:02] <Randy> added response codes to indicate data was lost
[03:29:18] <Randy> other response codes to indicate conversion not possible
[03:29:37] <Randy> new body part structure
[03:29:54] * resnick now on the call
[03:31:10] <Randy> server needs to return actual conversion done since it might be different from request
[03:37:50] <Randy> Discussion of server override option (server can disregard request and return something else since it "knows better")
[03:38:39] <Randy> Need to have client OK for server changes
[03:38:49] <Randy> Ted says the spec will get very complex
[03:39:05] <Randy> Eric says we can add an "OK to override" flag to request
[03:41:03] <Randy> Or "do not override" flag
[03:42:31] <Randy> Ted notes security considerations of, e.g., asking for text/html and getting application/javascript
[03:43:36] <resnick> Are we looking at particular slides?
[03:43:52] <Randy> lconvert-01 is on screen
[03:44:00] <Randy> \pages 7-8
[03:44:46] <Randy> server can return risky things..e.g., 1,000,000 pixels
[03:44:56] <Randy> now attacks against netscape based on this
[03:45:12] <Randy> key passing mechanisms for converting encrypted messages
[03:46:19] <Randy> problem is tractable because you don't need to give server private key, only message decryption key
[03:47:46] <Randy> dealing with encrypted content is out of scope of the media conversion document...needs its own document
[03:48:40] <Randy> discussion: ask for conversion of aac file, but phone doesn't support DRM, so server transcodes into crappy u-law
[03:49:21] <Randy> encryption protects end users, whereas drm protects 'different parties'
[03:50:28] <Randy> need sentence somewhere about case where content packaged with rights in DRM file...client asks server to transcode content and gets it unprotected by drm
[03:50:57] <Randy> correction: risk noted above was 1,000,000x1,000,000
[03:52:24] --- Dave Cridland has joined
[03:53:12] <Randy> key issue may be separate document saying how to pass keys as parameter to FETCH. This could then be plugged in to LCONVERT
[03:53:57] <Randy> DRM issue may be use case for streaming: server can convert DRM-protected media and stream to client but not send statically
[03:54:03] --- Glenn Parsons has joined
[03:56:27] <Randy> discussion of name (lconvert vs xconvert vs foo)
[03:56:34] <Randy> discussion of c-t-e
[03:57:20] <Randy> discussion of allowing compression as a specific parameter or saying just rely on tls for this
[03:57:31] <Randy> e.g., ask for base65+gzip
[03:57:41] <Randy> (base64+gzip)
[03:58:33] <Randy> servers supporting CONVERT MUST also support BINARYFETCH
[03:58:49] <Randy> but clients can ask for convert without asking for binary
[04:02:24] <Randy> rough conversion to go forward on the document?
[04:05:20] --- resnick has left: Replaced by new connection
[04:06:04] --- resnick has joined
[04:06:09] <gustaf rosell> Now also on phone
[04:14:34] <resnick> So are we on compose now?
[04:15:02] <Randy> [ sorry I missed it ]
[04:15:15] <Dave Cridland> Kind of. We're looking at obtaining partial headers, for huge dist lists, and it went to composition.
[04:15:26] <Dave Cridland> Side tracked in a related way.
[04:16:53] <Randy> new name: convert; now a wg doc
[04:16:58] <resnick> And clean up the control characters in the document!
[04:17:17] <Randy> add text on headers, c-t-e, etc. as issues
[04:18:05] <resnick> (or I guess I should say, the 8-bit characters)
[04:18:30] <Randy> streaming
[04:19:05] <Randy> Eric to check with Lyndon on streaming
[04:19:18] <Randy> streaming is profile not imap...use urlauth
[04:25:47] <Glenn Parsons> On break for 10 min
[04:25:55] <Glenn Parsons> Agenda when we return:
[04:25:58] <Glenn Parsons> Submission & remote compose draft-maes-lemonade-deliver Application Compression draft-maes-lemonade-lzip Firewallsdraft-maes-lemonade-http-binding
[04:29:21] --- eburger has joined
[04:37:57] <Glenn Parsons> We will reusme in 2 minutes
[04:38:50] --- eburger has left: Disconnected
[04:41:49] <Randy> Now discussing submission and remote compose
[04:42:00] <Randy> Stéphan has slides
[04:42:14] <Randy> slides are on web site
[04:42:18] <resnick> Named?
[04:42:49] <resnick> Got em
[04:42:57] <resnick> http://flyingfox.snowshore.com/i-d/lemonade/slides63-5/lemonade_mobile_newdrafts_London_sm_9_29_05.pdf
[04:43:31] <Dave Cridland> SLide 4
[04:44:19] <Randy> Handset vendors concerned with bandwidth, latency, and battery consumption. Also time to market.
[04:44:30] <gustaf rosell> You bet...
[04:45:21] <Randy> "Writing a good, efficient IMAP client is a black art. You need to have a lot of client experience to do it well."
[04:46:16] <Randy> Need lemonade document on best practices for a good client implementation
[04:49:21] <Randy> Common idea of itty-bitty clients and huge servers may not be accurate, since per-user slice on server may be more limited that handset
[04:49:58] <Randy> Don't worry about battery life of server
[04:50:17] <gustaf rosell> ROM size is not such a big issue. Complexity is a big issue when it comes to the time it would take to get things out on the market.
[04:50:55] <resnick> Might I suggest, "Yeah, we get it. Let's move on."?
[04:51:13] <resnick> ;)
[04:51:58] <gustaf rosell> What is the practical experience of running really large deployments with zillions of users on IMAP IDLE? This is something we are a bit concerned of.
[04:54:54] <Randy> Extra round trips in CATENATE because of literals, etc.
[04:55:28] <Randy> Discussion of LITERAL+
[04:55:30] --- eburger has joined
[04:55:37] <Randy> Can we require it in lemonade?
[04:55:46] <Randy> Alexey mentions very large literals (2 gig)
[04:55:51] <eburger> slide 6
[04:57:26] <eburger> Don't want to make clients have to have fall-back code for everything; too complex and too many lines of code.
[04:58:32] <eburger> Dave: send LITERAL+ in first message, which gives you knowledge of capability and privilege.
[04:58:53] <Randy> Send rationale for requiring LITERAL+ to list
[04:58:55] <eburger> Alexey: will put LITERAL+ into Profile 1.
[04:59:12] <eburger> Add another example, using LITERAL+
[04:59:15] <Randy> Add text to rev of Profile to require LITERAL+ and note that this is new
[04:59:19] <Randy> Any changes to CATENATE as a result?
[04:59:39] <Randy> Add new example to CATENATE to use LITERAL+
[04:59:45] <Dave Cridland> Actually, I don't use LITERAL+ for the first literal in some commands, to get an early failure.
[04:59:57] <eburger> so...?
[05:00:18] <eburger> (or did you mean you *do* use LITERAL+?)
[05:01:07] <Randy> I think he means he doesn't use it, so the server can fail the command right away
[05:01:43] <Dave Cridland> Yeah, I use LITERAL+, but not on the first literal, sometimes. So I can get the fail on the synch, rather than having to send all the data first.
[05:02:05] <resnick> All of this discussion reduces to "Profile should give examples with LITERAL+ so that everyone knows it's coming"
[05:03:09] --- Fan Xiaohui has joined
[05:05:06] <Randy> OMA wants to be able to send a diff in a literal (only changed part of message or addresses or whatever)
[05:05:31] --- hardie@jabber.psg.com has joined
[05:05:33] <Randy> Pete suggests adding octet range to URL in CATENATE
[05:05:44] <Randy> Ted has some concerns
[05:05:49] <Dave Cridland> So partial fetch syntax in URIs
[05:11:34] <hardie@jabber.psg.com> I guess my concern here is re-using fragment syntax for this. If the IMAP URL syntax is updated to introduce this, rather than trying to use fragments, I think it is workable, but may involve a spin past the URI list to ensure that the byte-range syntax doesn't break any assumptions of generic URI processors.
[05:11:50] --- eburger has left: Replaced by new connection
[05:12:24] <resnick> Absolutely. I don't want to use fragment syntax for this. But of course this will need to be floated by the URI people.
[05:13:22] <Dave Cridland> Alexey (surprise) is doing IMAP URI update anyway: draft-melnikov-imap-rfc2192bis
[05:14:49] --- eburger has joined
[05:17:28] <eburger> IMAPURL discussion
[05:17:48] <eburger> Common use case for server composition: replying without download (attachments)
[05:18:02] <eburger> Rarely attaching parts of other documents in mail box.
[05:18:19] <eburger> Sometimes like to remove pieces, however.
[05:18:28] <eburger> Mostly a routing thing (from me to someone else)
[05:18:44] <eburger> Proposal: modify IMAPURL to refer to message, less some bits.
[05:19:15] <eburger> Pete: how would one specify the boundaries?
[05:20:29] <eburger> Pete: offering to save the bytes of specifying URI's N-times, less the one time for the part you don't want (as opposed to sending 1 IMAPURL with some extra bytes indicating the part you don't want).
[05:21:23] <eburger> Pete offers that savings isn't worth it, unless there are tons of attachments.
[05:21:38] <gustaf rosell> Keep it simple... It should be enough to add text in top of message. Attachments should normally *not* be included when you reply, but of course when you forward.
[05:21:56] <eburger> Less complexity at server and client.
[05:22:08] <eburger> ... to do it Pete's way.
[05:23:56] <eburger> Pete asserts that user is most likely to forward whole message.
[05:24:03] <eburger> If they pick and chose, they will pick and chose.
[05:24:13] <eburger> Let protocol reflect that.
[05:24:44] <eburger> For the corner case where the message has an ugly, complicated structure, the new message will have an ugly, complicated structure, so no real savings.
[05:24:58] <eburger> [Therefore will take out IMAPURL extensions]
[05:25:19] <eburger> Up to slide 12
[05:25:24] <eburger> SUMBIT OVER IMAP
[05:25:58] <eburger> Deployment issue: belief that clients are not allowed to connect to SUBMIT servers
[05:27:35] <eburger> Randy: Enterprises that require only local SUBMIT (thus requiring VPN) *also* impose only local IMAP.
[05:28:40] <eburger> In this case, you must have VPN for doing both submit and retrieval
[05:28:48] <eburger> submit over IMAP doesn't help
[05:28:57] <eburger> because IMAP will be blocked, too.
[05:29:17] <eburger> Randy: if you can connect to the IMAP server, you probably can connect to the SUBMIT server.
[05:29:36] <eburger> If you cannot connect to the SUBMIT server, you cannot connect to the IMAP server.
[05:29:43] <eburger> [Up to slide 17]
[05:30:38] <eburger> Dave: how would you use AUTH other than PLAIN?
[05:30:43] <eburger> Alexey: you can't
[05:31:49] <eburger> Randy: Ned's SMTP tunneling draft (batch) is totally different than tunneling over another protocol.
[05:32:25] <eburger> Randy: If you are going through a lot of work to recreate SMTP in IMAP, why not just use SUBMIT?
[05:32:47] <eburger> Anil: What is argument for LDELIVER?
[05:32:52] <Randy> Ned's batch SMTP (encapsulating SMTP in a MIME body part) is to tunnel SMTP, that is, relay.
[05:32:54] <eburger> It isn't less client complexity.
[05:33:07] <Randy> Here we're talking about submission. Submission and relay are very different.
[05:33:08] <eburger> Saves a round trip; don't need URLAUTH.
[05:33:40] <Randy> Especially in how errors are handled
[05:35:07] <eburger> Proposal is that if we had an HTTP binding for IMAP, then we would get an HTTP binding for SUBMIT functionality.
[05:35:13] <gustaf rosell> An issue is that several mobile operators block port 25 because of spam, but do allow the usage of their own SMTP server (but typically not with TLS). LDELIVER, a HTTP binding for SMTP could be ways of handling that, maybe others too.
[05:35:29] <eburger> Ted: Ready to charter the RFC3205 Work Group? ;)
[05:38:14] <eburger> IETF World slide 12
[05:38:24] <eburger> [from Joint Meeting]
[05:39:51] <eburger> Glenn: if there was an HTTP binding, would we need LDELIVER?
[05:40:06] <eburger> for SUBMIT
[05:40:37] <eburger> what?
[05:41:03] <hardie@jabber.psg.com> If you use "Connect", are you proposing that TLS would actually be used?
[05:41:21] <hardie@jabber.psg.com> e.g. required to connect to the IMAP server.
[05:41:35] <eburger> Use CONNECT, and then "speak" IMAP
[05:41:44] <eburger> You could negotiate a TLS
[05:42:23] <eburger> Could LDELIVER be postponed and have HTTP binding discussion instead?
[05:43:01] <eburger> LCOMPOSE is covered if we do LITERAL+
[05:43:12] <eburger> IMAPURL with byte range extensions
[05:43:37] <eburger> LDELIVER can be tabled if we discuss firewall traversal
[05:45:02] <hardie@jabber.psg.com> Which version of "tabled"? "not discussed" or "brought to the fore"?
[05:45:04] <eburger> [back to slides]
[05:45:06] <eburger> slide 19
[05:45:22] <eburger> Offer was that TLS will do compression.
[05:45:42] <eburger> Problem is, of course, that TLS could expand already compressed multimedia.
[05:45:54] <eburger> that unnecessarily reduces battery life
[05:46:33] <eburger> LZIP lets you selectively compress result of IMAP command
[05:46:33] <eburger> slide 20
[05:46:50] <eburger> 0.98 of OpenSSL supports TLS compression
[05:48:19] <eburger> Could be way of building good IMAP dictionary, but Ray couldn't do it.
[05:48:25] <eburger> Randy: don't want to reinvent SIGCOMP
[05:48:55] <eburger> Compression results vary
[05:50:23] <eburger> Most compelling use case is the "UID FETCH 1:* FLAGS" result: 3144 bytes transfered for 20408 byte object
[05:50:51] <eburger> [by the way, we're discussing slide 22]
[05:51:24] <eburger> Would ESEARCH, a priori, have a similar reduction in traffic?
[05:51:42] <eburger> Would CONDSTORE have a similar reduction in traffic?
[05:52:15] <gustaf rosell> CPU cycles are *much* cheaper in power than active radio transmitter time. So it is worth investing in compression and even more in less verbose communication.
[05:52:31] <eburger> Does LZIP add state? No, because the command is LZIP <command>; only works over <command>.
[05:52:44] <eburger> BUT, command can result in multiple responses.
[05:53:07] <eburger> How does server know it's OK to ZIP intermediate responses?
[05:53:49] <eburger> Gustaf's point results in offering that TLS is the better way to go, because trade-off of CPU is more than made up in compression.
[05:53:50] <resnick> And on the mobile, you're not *compressing*; you're *decompressing*, which is significantly cheaper CPU-wise.
[05:54:13] <eburger> We would need minimum compression algorithm for TLS.
[05:54:23] <eburger> At least GZIP is there.
[05:54:28] <eburger> Belief is STACK is there, too.
[05:56:06] <resnick> **5 minute warning**
[05:56:33] <eburger> Tabling EXPERIMENTAL/INFORMATIONAL discussion
[05:56:54] <eburger> [we actually have the room to 1:30pm, but we'll try to finish closer to "on time" :-]
[05:57:55] <eburger> Dave: one can renegotiate compression on TLS. Any idea how many r.t.'s that takes?
[05:58:07] <Randy> In response to Stéphan's question about if we do experimental or informational for compression, could he do the same for LDELIVER, I'd suggest that experimental would be very appropriate for compression, but could be viewed as an attempted end-run if tried for ldeliver.
[05:58:27] <eburger> Do you have to renegotiate security, too?
[05:58:27] <eburger> No.
[06:00:14] <eburger> LZIP continues as Individual; experimental vs. info vs. std later
[06:00:25] <eburger> Profile 2 to include TLS with compression.
[06:00:41] <eburger> Anyone in studio audience willing to continue for 30 minutes?
[06:00:50] <eburger> [up to slide 27: HTTP Binding]
[06:01:03] <eburger> 1. OPTIONAL
[06:01:11] <eburger> needed for firewall traversal
[06:01:38] <eburger> needed for support of long-lived connections
[06:02:17] <gustaf rosell> We can keep long IDLE (tcp) connections in around 75% of tested mobile network vs. 95% for http.
[06:02:17] <eburger> for some reason, not well explained, but empirically believed, HTTP over TCP sessions are much more reliable than generic TCP sessions
[06:02:28] <eburger> See Gustaf's point.
[06:03:00] <eburger> HTTP to get around blocking of Operator's network of outbound ports
[06:03:21] <eburger> Only thing visiting network operator lets you do is use port 80
[06:03:28] <hardie@jabber.psg.com> Gustaf--is this because of 100 continue responses in HTTP, or are these pure idle connections?
[06:04:04] <gustaf rosell> Pure IDLE.
[06:04:11] <hardie@jabber.psg.com> thanks for clarifying
[06:04:45] <eburger> [slide 28]
[06:06:12] <resnick> How about you're screwing up all that well-worked HTTP load-balancing?
[06:06:14] <eburger> Ray: why can't IMAP be bound on protocols other than TCP?
[06:06:24] <eburger> Why can't we bind it to HTTP?
[06:06:35] <eburger> Pete: what's the issue?
[06:07:38] <eburger> Ray: if we specify HTTP transport, it would allow firewall manufacturers to block that, if they want to
[06:07:39] <hardie@jabber.psg.com> I think you're really talking about TLS over HTTP rather than TLS over TCP; otherwise the caching aspects ("interception" proxies) are going to cause huge problems.
[06:08:27] <eburger> Phil: IETF doesn't standardize non-Internet protocols
[06:08:30] <Dave Cridland> And privacy, too, if you're not using TLS.
[06:08:56] <eburger> Ted/Pete: care to bring up issue on phone?
[06:09:29] <resnick> I'm thinking about it. :-/
[06:09:50] <eburger> Need me to jump in, or still formulating, or need more coffee
[06:09:55] <Dave Cridland> Randy suggests a BCP for network operators.
[06:10:02] <resnick> The latter two.
[06:10:07] <hardie@jabber.psg.com> If the semantics of HTTP and IMAP are the same, then it is not a problem, but additional layering is fundamentally going to cause a mismatch if they are not. You also have to look at the "if this is tunelling to get past a firewall", why is the policy enforcement not appropriate?
[06:10:11] <Dave Cridland> Personally, I'd prefer a Big Stick. ;-)
[06:10:43] <hardie@jabber.psg.com> By reverse proxy, do they mean surrogate?
[06:11:37] <eburger> Pete: all being proposed for scenario where I have a lemonade server in my network
[06:11:43] <eburger> people want to access it from outside the network
[06:11:49] <eburger> but I won't let them access it over IMAP
[06:12:13] <eburger> but I will let them access it over an HTTP proxy that ultimately becomes IMAP
[06:12:20] <eburger> Answer: not really
[06:12:35] <eburger> For example, 3G doesn't do TCP well, but does HTTP OK.
[06:12:43] <eburger> Thus use HTTP to work around 3G TCP bugs
[06:12:57] <eburger> (don't know why, just know)
[06:13:24] <eburger> Another example: you go to a *different* network.
[06:13:30] <hardie@jabber.psg.com> Since TCP is the substrate to HTTP, that assertion is odd.
[06:13:47] <eburger> To Ted: agreed, but lots of people seem to think so.
[06:14:12] <eburger> back to example: different network doesn't let you get back to home network
[06:14:14] <gustaf rosell> Visiting networks are not such a big problem, you are tunneled in the the home network thru GRX.
[06:14:31] <eburger> Randy: if that is the argument, then shouldn't all protocols be run over HTTP?
[06:15:36] <eburger> Theory for why HTTP works better is because 3G gateways have different time-out settings for HTTP than for TCP
[06:16:00] <eburger> Gustaf: GGSN's are tuned differently for non-port-80
[06:16:01] <Randy> (BCP would be for TCP implementations as well as network operators, as appropriate based on what the problems turn out to be)
[06:16:45] <eburger> Ted: implication is that right thing to do is to explain that IMAP is a non-foreign protocol and thus operators need to properly configure their GGSN's
[06:17:53] <eburger> Ted: anything we do here will take at least a year to get deployed into the network, probably 18 months [Eric's observation] for handsets.
[06:18:19] <eburger> Compare this to notifying operators to properly configure their GGSN's. That would happen comparitively instantly.
[06:18:30] <Randy> (any HTTP binding would take a year or more to get built and deployed)
[06:18:31] <eburger> Stephane: it may be that GGSN's *cannot* be reconfigured.
[06:18:53] <gustaf rosell> It would still take a longer time to change the networks... But the firewall issues are more important for the http binding.
[06:19:13] <eburger> Jerry (speaking as an operator): what is the sample set?
[06:19:33] <Dave Cridland> gustaf: You mean corporate firewall, or network gateway firewalls?
[06:19:33] <eburger> Stephane: tried several 2.5G and 3G networks, and all seemed to have same behavior.
[06:19:45] <eburger> Network Gateway Firewalls (to Dave)
[06:20:00] <eburger> Look up GGSN.
[06:20:02] <gustaf rosell> We have tested some 25 networks, but again, the firewall issue is the most important one.
[06:20:40] <eburger> Stephane: not clear what the problem is, it is just an observation.
[06:21:22] <eburger> Ted lists issues from above: namely caching, HTTP routing, security, etc.
[06:21:50] <eburger> Ray: also need to tell enterprises to open ports
[06:22:21] <eburger> Ted: discusses VPN versus HTTP tunneling
[06:22:32] <eburger> to enterprise
[06:23:36] <gustaf rosell> VPN clients on closed OS phones (some 97% av volumes today) will take a very, very long time, if ever.
[06:23:57] <hardie@jabber.psg.com> What do you mean by a closed OS phone?
[06:24:20] <gustaf rosell> Not Symbian, Microsoft, Palm, Linux. The absolute majority.
[06:24:49] <eburger> Eric: enterprise deploys wireless access (e.g., RIM); first thing IT manager does is opens port 3101. What is problem?
[06:25:23] <Randy> Symbian, Microsoft, Palm, Linux are all open? Or are all closed?
[06:25:32] <hardie@jabber.psg.com> I don't believe gustaf's comment is correct for Microsoft, Linux, or Brew, but we may have different views of what "very, very long time" is.
[06:25:43] <eburger> Phil: discusses deep packet inspection
[06:25:52] <resnick> Those are all open.
[06:25:56] <gustaf rosell> It is correct but maybe unclear...
[06:26:21] <Randy> What does 'open' and 'closed' mean here?
[06:26:43] <resnick> Random schmoe can program on them == open
[06:26:55] <gustaf rosell> Most phones today are closed OS, Like Nokia Series 40, Ericsson/Enea OSE etc. Essentially only MS, Symbian, Palm and Linux are open. These volumes are still very small.
[06:27:06] <eburger> Ray offers that using SOAP primitives for mail (e.g, a FETCH method) is any different than tunneling IMAP FETCH over HTTP.
[06:27:32] <hardie@jabber.psg.com> Certainly the 3g networks support IPSEC for a variety of uses. Moving from those uses to enterprise VPNs has some issues with key management in SA setup. But moving to that openness is not that big a stretch.
[06:28:36] <eburger> Glenn: need document for issues and IETF solutions
[06:29:14] <gustaf rosell> IPSEC sucks big time in all mobile networks. There are serious problems with NAT, and these have been solved in proprietary ways by different vendors. Thus, different non-standard clients would be needed, and therefore an open OS.
[06:29:35] <Randy> Not all operators use NAT.
[06:29:47] <eburger> IPv6, anyone?
[06:30:02] <hardie@jabber.psg.com> dead:beef::::
[06:30:12] <gustaf rosell> Almost everyone use NAT.
[06:30:36] <Randy> There are very large operators that don't
[06:30:38] <eburger> Do we resurrect "Intermediary Challenges"?
[06:30:41] <Randy> But yes, many do
[06:31:16] <gustaf rosell> It is one advantage with mobile IP in CDMA networks, yes...
[06:32:17] <eburger> Action: Stephane will update challenges paper
[06:32:27] <eburger> Gustaf: can you help collect data?
[06:32:29] <resnick> Do you need me for anything else or can I jump off the call?
[06:32:31] <eburger> Answer: yes
[06:32:47] <Randy> we're wrapping up
[06:33:04] <eburger> You can go.l
[06:33:14] <resnick> OK, ttyl.
[06:33:18] <eburger> tfn!
[06:33:22] --- resnick has left
[06:33:46] <eburger> THANKS TO ISODE for Venue
[06:33:56] <eburger> THANKS to BROOKTROUT for Dinner and Entertainment
[06:34:13] <hardie@jabber.psg.com> Talk to you later.
[06:34:15] --- hardie@jabber.psg.com has left
[06:34:18] <eburger> We will request two slots
[06:34:44] <eburger> Monday - Wednesday requested.
[06:34:53] --- gustaf rosell has left
[06:34:59] <eburger> But don't count on it
[06:35:44] <eburger> Do we want to have Informal WG MTG in Vancouver?
[06:35:55] <eburger> especially to discuss HTTP bindings :)
[06:36:14] <Fan Xiaohui> I support to have
[06:37:09] --- Dave Cridland has left
[06:37:23] <eburger> Fan - will you be in Vancouver?
[06:38:12] <Fan Xiaohui> One delegate from cmcc will be there
[06:38:22] <eburger> Thanks!
[06:38:36] <Fan Xiaohui> Welcome :)
[06:38:47] <eburger> Also, thank you for staying up late to accomodate us.
[06:39:16] <Fan Xiaohui> Welcome again :D
[06:39:19] <eburger> bye for now.
[06:39:22] --- eburger has left
[06:40:07] --- Glenn Parsons has left
[06:41:44] --- Fan Xiaohui has left
[06:49:09] --- Randy has left: Disconnected
[07:44:46] --- Fan Xiaohui has joined
[08:23:44] --- Fan Xiaohui has left