[06:32:33] PARAGM-WXP01 joins the room [13:30:48] Julian Reschke joins the room [14:08:32] unixonline joins the room [14:08:35] unixonline leaves the room [14:09:48] unixonline joins the room [14:09:57] unixonline leaves the room [14:33:43] hyperfeng joins the room [14:33:57] hyperfeng leaves the room [14:43:55] hyperfeng joins the room [14:43:58] hyperfeng leaves the room [15:33:07] Dowon Kim joins the room [15:34:10] Dowon Kim leaves the room [15:35:04] Exodus joins the room [15:35:08] Exodus leaves the room [15:35:15] yone joins the room [15:50:46] hildjj joins the room [15:54:17] jack joins the room [15:57:27] Exodus joins the room [15:59:03] Exodus leaves the room [15:59:14] Exodus joins the room [15:59:31] sm joins the room [16:00:41] Julian Reschke leaves the room [16:00:46] Julian Reschke joins the room [16:01:06] mattlarson joins the room [16:01:11] mattlarson leaves the room [16:01:15] Barry Leiba joins the room [16:02:04] Ted joins the room [16:02:04] Ted leaves the room [16:02:46] Randall Gellens joins the room [16:02:47] tonyhansen joins the room [16:03:22] stpeter joins the room [16:03:29] fujiwara joins the room [16:03:35] Dowon Kim joins the room [16:03:42] stpeter has set the subject to: AppArea General Meeting, IETF 74 [16:03:42] PARAGM-WXP01 leaves the room [16:03:50] Agenda Bashing [16:04:14] Ted Hardie is speaking. [16:04:30] stpeter is scribing but clearly still waking up [16:04:33] HTML 5 [16:04:43] (Lisa Dusseault speaking) [16:04:50] What was the group Ted pointed us to? [16:05:13] Andrew Sullivan joins the room [16:05:18] question of what HTTP extensions needed [16:05:18] So for I don't hear anybody *speaking* (on the audio feed); just generic chatter. [16:06:03] Julian Reschke: ok I will tell folks here [16:06:27] Julian Reschke: is that better? [16:06:31] yes [16:06:39] except for collosal echp [16:06:41] lisa saves [16:06:42] echo [16:07:02] Lisa explains the kerfuffle over IPR [16:07:03] hi [16:07:08] fenton joins the room [16:07:22] frodek joins the room [16:07:28] klensin joins the room [16:08:17] Ted joins the room [16:08:52] meadhbh.siobhan joins the room [16:08:55] kdz joins the room [16:09:58] Ted Hardie at the mic [16:10:00] brb [16:11:08] question for remote listeners: is the audio OK? I have one report of bad echo [16:11:16] There is bad echo [16:11:18] additional reports would be appreciated [16:11:20] sm: ok [16:11:34] thanks, I will find the NOC people [16:11:46] brb, perhaps someone else could scribe briefly [16:12:12] I can [16:12:24] [wasn't paying attention] at mic [16:12:39] arguing that the current outline is too broad [16:12:41] echo is fixed, thanks [16:12:46] also, worry about antitrust issues [16:13:13] don't drive people "out of the room" [16:13:18] speaker's name, again? [16:13:39] tlyu joins the room [16:13:52] Dave Crocker @ mic [16:13:57] thnk hard about what Ted said [16:14:03] ray joins the room [16:14:40] other standards groups are careful not to get into IPR very carefully. This is not an engineering problem [16:14:49] Lisa responded, and Dave acked all very bad [16:15:04] problem is that this is not an engineering problem, and we don't have expertise [16:15:23] Point is that there's some sort of "implicit approval". Is there a risk? [16:15:38] Ted Hardie: also issue of rules in one area vs. other area [16:15:59] and may not be good that this induces potential area-shopping [16:16:10] perhaps should not do this at area level [16:16:13] Simon Josefsson joins the room [16:16:33] Leslie Daigle joins the room [16:17:00] moving on to Eran Hammer-Lahav [16:17:04] Slides on agenda [16:17:16] mtnviewmark joins the room [16:17:38] oh, wait. Maybe not [16:18:02] presnick joins the room [16:18:02] presnick leaves the room [16:18:13] rlbob joins the room [16:18:53] slides at http://www.ietf.org/proceedings/09mar/slides/apparea-0.pdf [16:20:17] spencerdawkins joins the room [16:20:23] mtnviewmark leaves the room [16:20:34] XRD being standardize elsewhere [16:20:47] idea is to use 3 kinds of links to get from URI to document describgin [16:21:08] jtrentadams joins the room [16:21:39] lellel joins the room [16:21:44] next slide: 3 examples [16:22:54] franck.martin@jabber.org joins the room [16:23:03] next slide: XRD example [16:23:21] Leslie Daigle leaves the room [16:23:31] mtnviewmark joins the room [16:23:43] typical use case: describe where address book is from in blog [16:23:57] XRD standardization venue is: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri [16:24:00] mtnviewmark leaves the room [16:24:03] OASIS XRI TC [16:24:26] Next, Stuart [16:24:35] mtnviewmark joins the room [16:24:38] Service Discovery [16:24:41] for slides [16:25:00] mtnviewmark leaves the room [16:25:34] DNS-based service discovery [16:25:40] Stuart moving mic [16:25:43] hta joins the room [16:25:47] overview of background [16:25:52] Andrew Sullivan: thanks for scribing, you're better than I am :) [16:25:54] dan.hoopyfrood joins the room [16:26:06] Mark Nottingham joins the room [16:26:42] naming slide [16:27:30] next slide [16:27:37] next slide [16:27:40] browsing [16:27:42] next [16:27:45] DNS Svc disc [16:28:06] next slide [16:28:33] BTW http://xmpp.org/extensions/xep-0174.html#howitworks has a nice description how this all works (skewed to our use of link-local in Jabber) [16:28:49] next slide [16:29:01] answer to ptr [16:29:08] full UTF-8 text (!) [16:29:12] Leslie Daigle joins the room [16:29:44] Lookup via DNS SRV slide [16:30:20] (do the slides become part of the meeting record? I wonder how you do that with keynote... PDF?) [16:30:22] next slide [16:30:33] they're at http://www.ietf.org/proceedings/09mar/slides/apparea-7.pdf [16:30:44] DNS-SD slide [16:31:07] Wide-Area DNS Sercvice Disc slide [16:31:09] Service, even [16:31:19] Architecture (LAN) slide [16:31:25] WAN slide [16:31:31] MtnViewMark joins the room [16:32:01] next slide (Arhictecture) [16:32:28] no garbage collection in Dynamic Update. [16:32:34] sal joins the room [16:32:36] Apple's code under Apache license [16:32:45] dwd joins the room [16:32:58] dwd is now known as Dave Cridland [16:33:02] Book cover slide [16:33:17] Is that a partridge? [16:33:26] My bird identification skills are few [16:33:29] Ted: seemed to be [16:33:30] Web sites slde [16:33:34] slide, even [16:33:45] Showing a demo [16:33:45] License for the Apple code used to be really bad. Apache 2.0 is a nice move. [16:34:07] indeed. [16:34:29] Bonjour for Windows also available [16:34:55] bear joins the room [16:35:21] Lawson English joins the room [16:35:36] command line DNS lookups on screen [16:35:43] Various teensy dig commands on screen [16:35:48] (umm... ok, now that I've got my infrastructure issues sorted, somebody help me understand why this is on the agenda? it seems to be existing, standardized stuff. is this just to inform people that might not know about it?) [16:36:08] dan.hoopyfrood: good question [16:36:20] is that a question for mic? [16:36:25] I believe the DNS stuff is just in draft [16:36:28] Morgaine joins the room [16:36:49] There was some discussion about draft-cheshire-dnsext-dns-sd-05 [16:36:58] Dave Crocker at the mic [16:37:31] MtnViewMark leaves the room: Replaced by new connection [16:37:36] what can people in apparea do to help move that along? [16:37:45] Lisa talking about it [16:37:46] Mark Nottingham leaves the room [16:37:49] Greetings all. Here out of interest in David Levine's presentation tomorrow at 1030 on "Intro to MMOX". [16:38:05] don't want every app WG to invent their own discovery stuff [16:38:07] Howdy [16:38:12] Cyrus Daboo at the mic [16:38:20] MarkAtwood joins the room [16:38:31] MtnViewMark joins the room [16:38:42] stpeter: This is great, you're telling me who will be at the microphone in 20 seconds or so. How *do* you do it? [16:39:01] heehee [16:39:12] Dave Crocker going to the mic [16:39:19] Andrew Sullivan at the mic [16:39:23] any access to mp3 for us peons? [16:39:33] (me got the queueing wrong) [16:39:39] jfenton joins the room [16:39:46] http://feed.verilan.com:8000/imperial_b.m3u [16:39:59] Please refer to the online agenda at http://tools.ietf.org/agenda/74/ to find a link to the stream for each session. [16:40:04] MtnViewMark leaves the room: Replaced by new connection [16:40:18] Dave Crocker [16:40:20] thanks [16:41:12] MtnViewMark joins the room [16:41:14] Did I miss the responses to the last IETF Last Call for dns-sd? [16:41:29] No, hasn't actually been LCd [16:41:29] (Crocker's point about broader... is this the general problem of squatting on names? I've worked on that in the W3C Technical Architecture Group. very frustrating.) [16:41:33] Dave Cridland: good questions [16:42:17] Peter (?) at the mic [16:42:22] (didn't catch his last name) [16:42:23] Last Call was last year [16:42:25] Is cyrus daboo on this chat? [16:42:27] gogh? [16:42:29] Andrew Sullivan: As in, the Last Call for draft-cheshire-dns-sd around mid-november last year? That last call didn't happen? It was all a dream? Damn those drugs are awesome. [16:42:36] At the mic: was Peter Koch [16:42:40] I think it was last year [16:42:42] fenton: thanks [16:42:46] So, it quacks like a duck [16:43:07] looks like NETINFO meets DNS to me [16:43:41] I'd like to speak with cyrus daboo, when free (but I'm in IPv6 room). Thanks [16:43:58] shikob joins the room [16:44:21] Cyrus Daboo presenting [16:45:03] siobhan: actually this is appletalk on internet [16:45:26] Simon Josefsson leaves the room [16:45:30] shikob leaves the room [16:45:49] Mark Nottingham joins the room [16:45:52] franck.martin@jabber.org leaves the room [16:45:59] Simon Josefsson joins the room [16:46:11] Cyrus describes the current state of time zone (TZ) data [16:46:16] rlbob: Sure. dns-sd isn't really IP at all. Just like it isn't DNS... [16:46:42] Cyrus: who cares about this? [16:47:00] Cyrus: anyone who cares about scheduling, calendaring, etc. [16:47:06] Cyrus: TZ problems... [16:47:11] (the tzinfo process is working... I wonder why change it... or even publicize it to the point where more people get involved and hence it stops working ;-) [16:47:12] interop problems [16:47:19] different definitions used by different products [16:47:28] dan.hoopyfrood: :) [16:47:43] different products use diffent TZ names in their iCal data, its very annoying [16:47:45] Cyrus: failure to update TZ data when rules change [16:48:03] Cyrus: and failure to update in a timely fashion when changes occur [16:48:08] (I heard of a change in Australia with much less than 18 months lead time.) [16:48:20] Not to mention Venezuela. [16:48:31] Cyrus: many copies of zoneinfo on the same system [16:48:47] Cyrus: updates done only at the OS is patched [16:48:51] shikob joins the room [16:49:06] MySQL uses its own zoneinfo tables only if there is no system zoneinfo data [16:49:32] Cyrus: CalConnect has a committee working on these issues [16:49:42] darn wish we could virtual worlds mashup for this stuff. [16:49:55] proposed solutions: IANA registry for publishers of TZ data [16:50:06] Lawson: Sorry, I don't understand how that mashup would work/help. Can you explain? [16:50:09] (2) define TZ service protocol [16:50:14] kdz leaves the room [16:50:32] (3) work out a succession plan for Olson database [16:50:56] Why ISOC rather than IANA? [16:50:59] (4) make sure TZ data is "secure" [16:51:05] (aha... Olsen due to retire soon. *that's* answers my "if it ain't broke, why fix it?" question) [16:51:09] Not that I have heartburn about it being ISOC, but confused. [16:51:21] dan.hoopyfrood: Indeed. Breakage is scheduled. [16:51:24] Ted: I see the word "perhaps" in there [16:51:31] True enough. [16:51:36] The Cerf problem [16:51:42] Cyrus shows a fancy slide with lots of boxes and arrows [16:51:53] And colours... [16:51:56] what happens when the one trusted guy goes away, how can he be replaced with a committee and still work almost as well? [16:51:58] where's IANA in this graph? [16:51:59] Nice colours. [16:51:59] FYI, I'm Dan Connolly. I suppose there's a remaining infrastructure issue if I'm being identified as dan.hoopyfrood in this forum. [16:52:00] yeah, colors too [16:52:23] Ted well we were hoping to do one for mmox. WOuld let 3D vws have inworld video, audio and chat discussion as well as potentially multimedia presentation [16:52:26] not just IANA, but operating system providers [16:52:37] I see. [16:52:40] Summary slide [16:52:44] Julian Reschke leaves the room [16:52:53] You weren't thinking in particular about a virtual world/timezone issue, which is what I understood you to be saying. [16:52:57] looks like MSFT is on board, and it wouldnt be hard to get the Linux distros in, i dont see Apple being a problem [16:53:09] Cyrus works for Apple, so likely not. [16:53:22] oops, who's at the mic? [16:53:28] That was Eric Burger [16:53:28] Julian Reschke joins the room [16:53:33] an no, was just wishing I had virtual faces and/or media to look at. [16:53:35] Julian Reschke leaves the room [16:53:37] Ted: right, sory [16:53:39] DanC at the mic [16:53:44] Julian Reschke joins the room [16:53:45] Even Science Friday mock up would be fun [16:53:51] Julian Reschke leaves the room [16:53:52] Solaris might be a problem, but I can hammer on the Solaris team from the inside ^_^ [16:53:55] thx DanC for asking my question at the mic [16:54:30] DanC suggests using Wikipedia to store this info. Lots of people made faces in the room at that suggestion. [16:54:46] Barry Leiba at the mic [16:55:30] wikipedia not a good idea, but keeping it in a wiki is a good idea, IMO [16:55:38] That may make ISOC less than the ideal choice, since it often wishes to influence policy. On the other hand, its chapter structure would fit well here, as a way to reach out to a variety of areas [16:55:39] Alexey Melnikov presenting about SCRAM [16:55:42] +1 to Mark A [16:55:52] +1 to Ted, as well. [16:55:54] seems to me the security issues with timezones have been handled by operating system providers... but I guess the requirement is to propagate the data faster than the OSs can be updated. I wonder if this is really a solveable problem. [16:56:04] sal leaves the room: Replaced by new connection [16:56:06] Cyrus have you talked to Leslie Daigle about ISOC involvement here? [16:56:09] shikob leaves the room [16:56:45] if the data is on a trusted server or is signed, then it can be distributed via HTTP/DNS/etc [16:57:33] also, most OSes now have a rapid update service, the problem is machines that a "locked down", then it doesnt matter how often the OS vendor does updates... that turns into an *interesting* ops problem... [16:57:36] existing password-based mechanisms... [16:57:39] PLAIN [16:57:47] needs to be run over TLS [16:57:53] allows server to impersonate user [16:57:58] (2) CRAM-MD5 [16:58:17] ops problem... exactly. [16:58:18] not considered to be secure [16:58:24] Mark Nottingham leaves the room [16:58:25] doesn't support server auth [16:58:39] cyrus joins the room [16:58:40] doesn't support i18n, channel bindings, etc. [16:58:43] Dan: Yes, I agree, ops problem. [16:58:44] (3) DIGEST-MD5 [16:59:04] poor interoperability [16:59:21] TZ: If one doesn't have an authoritative list, it is really no better than the Olson (van Vleck et al) data. [16:59:22] SASL WG tried to fix DIGEST-MD5 [16:59:25] Julian Reschke joins the room [16:59:44] the ops problem suggests influencing policy; i.e. educating govts about the costs of low-latency timezone rule changes. [16:59:50] concluded that work involved was not worth the effort, instead define something new [17:00:06] Alexey quickly runs through the objectives/requirements [17:00:24] Dan: I agree, but that's not the IETF's business. ISOC could work on that. [17:00:28] result of these efforts: SCRAM [17:00:46] status in SASL WG: core authentication protocol is complete [17:01:22] remaining issue about re-use of GSS-API framing [17:01:22] Another point: if computer are getting TZ info over the Internet, we have to be careful about hackers breaking into it and corrupting it for fun and profit. [17:02:01] TZ issues mirror DNS issues - why not use same method for both [17:02:04] Ted: re ISOC - I will try and corner Leslie sometime this week. [17:02:19] what's next for SCRAM: need to investigate best way to intergrate it into HTTP [17:02:32] TZ database hacking is already a problem [17:02:37] Barry Leiba at the mic [17:02:47] alexmcmahon joins the room [17:03:11] Bear: we looked at DNS as a solution, but we want a richer api than would be reasonable for DNS. The rich queries we want to enable would not be good for DNS. Plus timezone data can be large - i.e. packet size issues. Right now we are looking at a Restful HTTP solution. [17:03:19] barry saying we want to avoid repay attacks [17:03:23] +1 barry [17:03:26] "do not give away credientals so that bad services can impersonate" [17:03:29] Barry: we need to move to authc protocols that prevent server from impersonating [17:03:35] (there's an HTTP auth mailing list or something, yes? is that still live?) [17:03:37] this is what OAuth is for in the social web space [17:03:42] dan.hoopyfrood: there is, I think [17:03:48] John Klensin at the mic [17:03:50] Is there evidence of tz database hacking? Any references to articles? [17:04:09] yes, OAuth seems to have a nice combination of security and deployability characteristics [17:04:34] MarkAtwood is one of the OAuth spec authors [17:05:43] John's point is that CRAM-MD5 was "brain-damagingly simple" [17:05:46] was/is :) [17:05:50] I haven't seen evidence of tz database hacking; but like I say, I think the changes get vetted by OS providers before they get widely distributed [17:06:03] Kurt Zeilenga: SCRAM designed to replace DIGEST-MD5 [17:06:11] ugh.i was going to ask if this is in any way related to PKCS5 PBKDF2 [17:06:18] are there any use cases or market drivers identified for this SCRAM stuff? [17:06:20] but i'll ask that at the SASL meeting [17:06:26] (that was Kurt at the mic) [17:06:42] dcolivares joins the room [17:06:45] SASL meeting... good point; I wonder if that fits in my schedule... [17:06:53] also... with respect to "hash alacrity" [17:06:57] anyone remember MOSS? [17:06:57] http://www.ietf.org/rfc/rfc1848.txt [http://www.ietf.org/rfc/rfc1848.txt] [17:06:58] it was a risk i had to work to alleviate putting TZ updates into linux based PVRs... i dont know if its a rreal risk, but its a risk that real orgs want to feel comfortable that it's addressed [17:07:06] dan.hoopyfrood: FWIW, XMPP is looking at using it to replace our current DIGEST-MD5 MTI. [17:07:31] ah. good to know, dwd [17:08:02] Dowon Kim leaves the room [17:08:10] dcolivares turns the audio feed up.. as he's really quiet! [17:08:18] Andrew Sullivan leaves the room [17:08:37] fenton leaves the room [17:08:38] dcolivares: The audio feeds for the IETFs are always really quiet, I find. [17:09:05] dcolivares commits an Audio no-no and turns uses the EQ to overmodulate it into audibility. [17:09:45] Greg Wilkins presenting about Comet / Bayeux [17:10:01] (I wonder how bayeaux deals with NAT traversal) [17:11:11] down with polling! [17:11:30] dan.hoopyfrood: same as HTTP [17:11:31] dcolivares++ [17:11:32] Dan: this is standard HTTP so far, eh? [17:11:38] So the same NAT traversal mechanism. [17:11:40] preferred method: "long polling: [17:11:41] how many pubsub bidirectional protocls does the world need? [17:11:47] Mark: 9. [17:11:48] MarkAtwood: 7.2 [17:11:50] Leslie Daigle leaves the room [17:11:50] normal so far with description of Long Poll. [17:11:50] dcolivares leaves the room [17:11:58] right, so far no TCP connections initiated by the server [17:11:58] Leslie Daigle joins the room [17:12:00] dcolivares joins the room [17:12:07] ptth ftw [17:12:29] Lawson: snort. [17:12:43] it has its uses [17:12:46] polling is bad, by painful experience [17:12:50] Why all this work to build bidirectionality onto HTTP? [17:12:59] "Horrible hacks" :D [17:13:08] Randall: because XMPP doesn't use port 80 by default. [17:13:15] why are people okay with the long poll event queue over HTTP but bent out of shape re: putting services over putting service discovery over DNS? [17:13:17] because http solves all problems if you stare at GET/PUT long enough [17:13:25] so this is all just ways to hide from outbound firewalls [17:13:39] meadhbh.siobhan: because this is all in apps [17:13:43] dcolivares still tends to not like long poll.. lots of wasted threads. [17:13:54] i dont understand the DNS objections at all, it looks like a perfect application for the original promise of DNS [17:14:05] Mark: only somewhat. also access from JavaScript in a browser. [17:14:08] consider case of long poll for game use [17:14:15] cause we sorta forgot to implement v6, have a lot of clients behind a NATted firewall and we want to do MVC with a view-controller in the browser [17:14:29] (was responding to why we're doing this over HTTP) [17:14:41] thats a good argument, i am convienced by it [17:14:52] GW: yes it's verbose, but we can always compress the traffic [17:14:55] im not happy with the need, but i understand the usefulnes [17:14:57] hmm, do you think the view can really be in a browser? [17:15:06] Dave Cridland: sounds familiar... :) [17:15:16] Bayeux does not have an internet-scale addressing scheme. [17:15:17] so far, Flash, for example isn't 'quick' enough. [17:15:22] BOSH does. [17:15:22] sure. lotsa JS apps livign in browsers [17:15:23] rlbob leaves the room [17:15:33] (where app == view-conroller) [17:15:35] hildjj: does it have any addressing scheme? [17:15:48] stpeter: yes. the channel names. [17:15:53] Glenn Parsons joins the room [17:15:55] ah, so browser is synonymous with viewer in this case. [17:15:55] dcolivares leaves the room [17:16:11] or "client application" more generically [17:16:11] dcolivares joins the room [17:16:19] http://svn.cometd.org/trunk/bayeux/bayeux.html [17:16:23] ah, so browser is synonymous with viewer in this case. [17:16:28] (timeout would also vary with load, yes? i.e. the server might say "I'm over 10,000 clients; I'm only going to remember each of you for 20 seconds") [17:16:51] dan.hoopyfrood: it's usually the proxy timing out the connection, but yes, in theory, you're right. [17:16:56] msj joins the room [17:17:00] Blaine Cook joins the room [17:17:03] uh oh... i sense a header coming on... "Timeout-requested: XXX" [17:17:12] meadhbh.siobhan: BOSH has a solution to this problem. [17:17:14] followed by "Timeout: XXX" [17:17:21] BOSH? pointer? [17:17:23] "two connection limit!" Yeah! [17:17:23] msj leaves the room [17:17:28] http://xmpp.org/extensions/xep-0124.html [17:17:39] XMPP on BOSH: http://xmpp.org/extensions/xep-0206.html [17:17:48] tx [17:18:26] The solution is to just respond immediately on the first connection when the second one long-polls. [17:18:33] Mark Nottingham at the mic points out that the 2-connection limit is removed in httpbis [17:18:47] but not in any shipping browser. [17:18:54] hildjj: that's hard, but I don't think the many-connections concern is real. [17:19:02] yep, he's absolutely correct [17:19:19] Blaine Cook: it is if you're trying to fit it all on one server, since you don't have a real addressing scheme. [17:19:24] .. from the client side, give me mor connections. from the server side.. less! please! [17:19:24] dcolivares leaves the room [17:19:25] People aren't all okay with long poll event queues, because it's still a poll, and the repeated closing/reopening of connections is a total waste, a bad hack. It's a very browser-centric solution, and very poor in a concurrent world. I agree totally with the speaker. [17:19:29] dcolivares joins the room [17:19:31] Blaine Cook: in other words, i agree with you [17:19:43] .. from the client side, give me mor connections. from the server side.. less! please! [17:19:46] right... but there are deployments that have different services running on one server... so it's a major rewrite to get the server software to use a unified event queue [17:19:57] hildjj: yes; but even without addressing you can fake it asynchronously, etc. [17:20:19] stpeter leaves the room [17:20:21] cyrus leaves the room [17:20:26] stpeter joins the room [17:20:28] speaking as a scalable web service guy, building a scalable web service isnt that hard, just because most people dont do it [17:20:28] hildjj: even without addressing, as long as the naming is local to a server, a simple low-latency key-value store makes all these problems irrelevant. [17:20:37] Leslie Daigle leaves the room [17:20:46] that was Scott Lawrence at the mic [17:20:47] it should not be HARD to have a dozen connections to a user [17:20:48] Paging Jeff Mogul; Jeff Mogul to the white courtesy telephone, please. [17:20:50] maybe we could add something like "each server / client pair SHOULD have at most 2 connections" [17:20:58] meadhbh.siobhan likes the word SHOULD [17:20:59] cyrus joins the room [17:21:13] "SHOULD" hides a multitude of sins [17:21:19] Oh, lost audio. [17:21:30] Yep, audio died. [17:21:36] maybe the answer is HTTP over SCTP instead of TCP? ^_^ [17:21:42] Morgaine: It woke me up, at least. [17:21:50] hildjj: if we had Internet-scale addresses, perhaps frames could communicate among themselves? [17:21:50] :-) [17:21:52] brb [17:21:53] stpeter leaves the room [17:21:53] cyrus leaves the room [17:22:03] dcolivares keeps pinging the audio server [17:22:06] mmm.. how bout SCTP over v6? [17:22:17] Is the audio still working? I'm getting a 404 [17:22:26] sm: Same. [17:22:29] Nothing in the room appears to have changed. [17:22:30] sm: it's down [17:22:33] stpeter joins the room [17:22:33] loss of protection due to multiple connections [17:22:37] same. I'm sure someone is working on it. [17:22:51] cyrus joins the room [17:23:06] he says people are happy with long polling [17:23:34] he's not familiar with uses cases for which long polling aint so hot then I think [17:23:41] alexmcmahon leaves the room: Replaced by new connection [17:23:42] im thinking of rabble's presentation for how polling hammers flickr, too many polls have zero data, there is a N*M problem [17:24:09] there's also the worker 'thread' consideration [17:24:18] "people" may be happy, but ops type folks are not :) [17:24:32] FWIW, in the XMPP world, BOSH is out of favour for everything aside from web-page interaction, where we choose to love it dearly - but only because web browsers don't allow actual sockets. [17:24:36] right now we're unable to get < 300s latency for web apps. Two orders of magnitude, 1-3s latency, would make me and many others VERY happy. [17:25:19] 300 seconds of latency? [17:25:19] XMPP BOSH, Jack Moffitt * Peter Saint-Andre [17:25:20] FWIW, XMPP latency tends to sit just above TCP latency, which means that multi-hop latency (that you see when communicating amongst remote servers) sits realistically at about 1s. [17:25:29] Dave Cridland: Fabio Forno thinks it's great for everything [17:25:50] stpeter: Not what he told me - he wants to move off BOSH ASAP, he just doesn't have XEP-0198 yet. [17:25:54] meadhbh.siobhan: yes. If you're not using long polling, and you're just polling, it's really hard to support clients that poll more frequently than 5 minutes. [17:26:07] XMPP over HTTP, uses HTTP1, no special requirements [17:26:16] hta leaves the room [17:26:16] cyrus leaves the room [17:26:46] eburger joins the room [17:27:09] Are timeouts a problem with long polling? [17:27:09] payloads are XML [17:27:13] seriously. you cant get better than 300 _seconds_ of latency? is lotus notes somehow involved? that sounds high [17:27:22] Randall Gellens: yes, because of proxies [17:27:27] meadhbh.siobhan: It's not what you can get, it's what you can support. [17:27:29] Leslie Daigle joins the room [17:27:55] meadhbh.siobhan: you can allow more frequent polls, but everyone tends to cache at 5 minute intervals. So clients don't get fresh data. [17:28:00] dcolivares notes that the Linden Servers occasionally have thread issues also on the Long Poll EventQueue as is evidenced by some of the HTTP responses. [17:28:06] every time someone says "close and reopen the connection", i wince, thinking of the slowstart [17:28:17] turn off slowstart? [17:28:24] thats even worse [17:28:27] slowstart is killing me right now at seesmic [17:28:27] (yeah. i know. that's not good) [17:28:38] kdz joins the room [17:28:44] slowstart off is antisocial, and i refuse to implement when asked to [17:29:05] cyrus joins the room [17:29:08] MarkAtwood: Besides, I see no reason to give access to TCP internals within javascript apps. [17:29:12] sorry, the scribe was listening [17:29:14] yeah. and you should see what it does to noisy wireless networks that are close to their max rate [17:29:25] bear: lots of XMPP startup can be pipelined, if you've connected to the server recently, and know it's stream features. [17:29:25] stpeter: More than we can do. :-) [17:29:26] Jack Moffitt presenting [17:29:43] Jack describes some of the reliability and security aspects of BOSH [17:30:24] hta joins the room [17:30:24] Well in high-bandwidth applications like virtual worlds, you not only need the lowest latency you can get, but also the highest bandwidth for downstreamed world updates. That makes any poll-based technique (and long poll is still one) a very poor candidate. If you have a 2nd TCP link set up, it should be asynchronous and persistent, not synchronous through polling and broken after each response. COMET streamed response does at least address the latter though. [17:30:24] BOSH supports pings, https, has session ids and request ids, for attack protection [17:30:24] hmm... sliding window at the app request layer? i guess good design patterns find application at multiple layers. [17:30:30] hildjj: *nods* I just need to take a whip to some of the devs in house [17:30:55] ah, BOSH is cool, but.. the initial connection semantics are slightly more tricky then standard XMPP [17:31:07] Morgaine: Well, really, what we need is XMPP-enabled web browsers. I see BOSH and XMPP/BOSH as a path to that. [17:31:16] Audio is back [17:31:35] Thanks [17:31:35] Shame, the chatrooms are always more interesting with audio off... [17:31:48] dcolivares: it's not too bad. the hard part of BOSH implementations are the edge cases, for example when you want to send and both connections are busy. [17:31:48] there's no reason they need to be :D [17:32:45] Is Jack going to mention any examples not running his BOSH implementation? ;-) [17:32:52] MarkAtwood2 joins the room [17:33:14] signing [17:34:01] Open Issues [17:34:08] MarkAtwood2 leaves the room [17:34:27] (mostly security issues) [17:34:44] go zero [17:34:48] Mark Lentczner presenting [17:35:10] overview of "bidirectional HTTP" [17:35:17] And lost audio again. [17:35:21] buffer.... [17:35:21] (help me find the slides online, again, please?) [17:35:21] there goes stream :-/ [17:35:22] Atarashi Yoshifumi joins the room [17:35:43] four approachs: BOSH, Bayeux, WebSockets, rHTTP [17:35:45] I suspect there's more interest then was initially expected and it's dragging down the stream. [17:36:28] dan.hoopyfrood: http://tools.ietf.org/agenda/74/ is your friend. [17:36:34] dwould be worse video streaming I guess [17:36:40] different motivations behind these approaches [17:36:49] (someone in the back room is running the web server restart command probably.. :)) [17:37:06]