XMPP Council - 2011-08-03


  1. Neustradamus has left
  2. Kev has joined
  3. linuxwolf has joined
  4. dwd has joined
  5. MattJ has joined
  6. stpeter has joined
  7. stpeter greetings
  8. MattJ Greetings stpeter
  9. linuxwolf waves
  10. stpeter MattJ: are still in NYC?
  11. linuxwolf has left
  12. Tobias has joined
  13. MattJ How was Quebec?
  14. MattJ I am
  15. linuxwolf has joined
  16. stpeter it was enjoyable
  17. Kev Evening all.
  18. stpeter nice place
  19. stpeter enjoyable and busy, of course
  20. linuxwolf very French (-:
  21. MattJ Heh
  22. Fritzy has joined
  23. Kev Right, it is time.
  24. Kev 1) Roll call.
  25. Kev I'm here!
  26. Fritzy howdy
  27. linuxwolf presente
  28. MattJ Presents
  29. linuxwolf dang…a full house?! unpossible!
  30. linuxwolf oh, no ralphm
  31. MattJ Don't get your hopes up :)
  32. Kev 2) Promote XEP-0260 to Draft? http://mail.jabber.org/pipermail/standards/2011-June/024722.html
  33. linuxwolf +1; I think I found a couple cosmetic grammatical error, but not enough to hold it up
  34. Fritzy no traffic on the mailing list?
  35. MattJ Am I correct in that we had no LC feedback?
  36. linuxwolf not until this morning
  37. Kev Tobias had feedback on both.
  38. Kev (A few minutes ago)
  39. MattJ Oh, Tobias
  40. Kev It bothers me somewhat that we're promoting stuff to draft that only a single person says they've implemented or intend to implement.
  41. MattJ So, I've implemented most of 260 - but it was some time ago, I'd like to know interop with someone worked
  42. MattJ I'd like to test with Tobias in particular
  43. MattJ and Gajim implements it I think, if we can track down the code (I'm not sure it's in trunk)
  44. Fritzy ok, well, sounds like 260 has at least two implementers
  45. Fritzy 3
  46. linuxwolf yeah, that was my sense
  47. dwd IIRC, Gajim's Jingle-FT is in a branch, yes.
  48. MattJ Implementers, no real world experience
  49. Fritzy right
  50. linuxwolf true
  51. Kev Can we put off 260 and 261 until next week, and chase people in the meantime for feedback?
  52. linuxwolf wfm
  53. Fritzy Should we hold off on draft until we see some interop, at least anecdotally?
  54. Tobias there's also a pidgin branch implementing 260 and 261..at least claiming that
  55. MattJ dwd, Asterix told me he was merging it "tomorrow" about 6 months ago
  56. Fritzy cool, let's give it a week
  57. stpeter MattJ: :)
  58. linuxwolf the same would be true for 261, yes?
  59. Tobias well..IBB to pidgin works for me
  60. MattJ I'd like to bring up the last call issues in AOB
  61. Kev It doesn't seem that waiting a week will significantly hurt anything, and it may give us a much better-informed position to comment from.
  62. Kev stpeter: Your thoughts?
  63. dwd I note that proof of interop is not required by XEP-0001 for Draft.
  64. stpeter fine with me
  65. Kev dwd: Not required, but if we have known implementors, it makes sense to me to try to get feedback.
  66. Fritzy dwd: *nod* -- still, seems like we're blind without at least some evidence that it works.
  67. stpeter personally I've been having dark thoughts about how everyone will just use http://tools.ietf.org/wg/rtcweb/ before long anyway, but what do I know? ;-)
  68. Kev For the sake of a week.
  69. linuxwolf stpeter: heh
  70. Kev So, assuming that covers 3) Advance 261 to Draft as well...
  71. dwd True. Just noting that you don't *have* to. But specifically pinging implementors seems like a plan.
  72. Kev 4) Advance 266 to Draft http://mail.jabber.org/pipermail/standards/2011-June/024625.html
  73. ralphm has joined
  74. MattJ +1 from me, I think
  75. ralphm hello
  76. MattJ Hey ralphm :)
  77. linuxwolf +1 from me
  78. Kev Hi Ralph.
  79. Tobias stpeter, what's the epub symbol there on the WebRTC WG page? IETF publishing in ePub now? :)
  80. linuxwolf damn…we do have a full house
  81. linuxwolf (-:
  82. stpeter re codecs, see also http://tools.ietf.org/html/draft-cbran-rtcweb-codec-00
  83. linuxwolf Tobias: some things, yes…sort of (-:
  84. Kev So, I know there was some amount of discussion on list about 266/Opus, but as far as I can tell the XEP does address that (we shouldn't be recommending it/we're not, we should be noting the claim/we are).
  85. linuxwolf exactly
  86. stpeter rightio
  87. MattJ Same logic from me
  88. Fritzy +1
  89. linuxwolf there's more consensus on jingle@ mailing list
  90. ralphm +!
  91. ralphm ehm, +1
  92. MattJ Heh
  93. linuxwolf (-:
  94. Kev There was someone offering to list all the reasons it was bad, then not doing so when asked to, so I'm +1 on this in the absence of any clearly unaddressed issues.
  95. stpeter I like +!
  96. ralphm and agreed about #2 and #3
  97. stpeter or +¡
  98. Fritzy haha
  99. Kev So, noting there's two AOB items (Matt and Matt).
  100. ralphm there doesn't seem to be a unicode code point for [approved]
  101. linuxwolf fußy
  102. Kev 5) Time of next meeting?
  103. Kev Next week, same time?
  104. stpeter WFM
  105. ralphm yup
  106. linuxwolf no news from Quebéc?
  107. linuxwolf and that date/time works for me
  108. Kev linuxwolf: That's your AOB item :)
  109. Kev Well, yours/PSA's.
  110. stpeter actually Québec :)
  111. linuxwolf haha
  112. Kev 6) AOB.
  113. ralphm :-)
  114. Kev Québec report from Peter/Matt:
  115. linuxwolf grazíe
  116. ralphm (expecting a large paste here)
  117. linuxwolf digs up email sent earlier...
  118. stpeter the main topics were s2s/DNA, i18n, and e2e encryption
  119. linuxwolf so, on the XMPP front...
  120. ralphm (wow, why are linuxwolf's /me messages styled in a huge font?)
  121. MattJ They seem to be XHTML-IM
  122. linuxwolf ugh
  123. linuxwolf I need to get a better client
  124. linuxwolf or write one /ducks
  125. linuxwolf anyway
  126. ralphm Before the last upgrade I patched gajim to disregard certain styles
  127. MattJ linuxwolf, join the club
  128. Fritzy ssshh, we're hearing a report
  129. ralphm in particular font-color, family and size
  130. linuxwolf hehe
  131. linuxwolf so
  132. linuxwolf DNA
  133. Fritzy "the main topics were s2s/DNA, i18n, and e2e encryption"
  134. linuxwolf the biggest concern seemed to be around requiring tedious software upgrades (DNSSEC-based)...
  135. linuxwolf …or sharing cert+keys from the hostee to the hoster (cert-based)
  136. linuxwolf post-session, there was some agreement to a compromise...
  137. linuxwolf …to use a descriptor file served from the hostee's HTTPS server that listed the valid name (or certificate) for the _xmpp-server._tcp service
  138. linuxwolf Joe Hildebrand and Eric Rescola were working on a draft, so I think something should be emerging in the next week or two
  139. Kev Which is really just the age-old trick of shifting-the-problem-without-solving-much.
  140. linuxwolf right
  141. MattJ brb, switching to wifi (198 would be so useful right now)
  142. stpeter :)
  143. ralphm based on .well-known?
  144. linuxwolf and with the CA trust anchors in x.509 being less-than-stellar...
  145. linuxwolf ralphm: yes
  146. dwd I basically agree, but I think it's an achievable goal and workable if one assumes that it's a fallback from DNSSEC.
  147. linuxwolf /nod
  148. ralphm yeah I can imagine the approach
  149. ralphm dwd: agreed
  150. ralphm 'assumes' or 'requires'
  151. linuxwolf on the i18n front…it's basically see what happens in PRECÍS, although stpeter can comment more there
  152. MattJ has left
  153. MattJ has joined
  154. stpeter yes, I've been pushing for progress on internationalization
  155. linuxwolf we'll need to do something
  156. stpeter I need to update the precis-framework document based on feedback received in Québec City
  157. linuxwolf /nod
  158. stpeter I worry a bit about Kev's point that changing the address format might require a version change to XMPP itself, but we'll see if that's needed...
  159. ralphm linuxwolf: as in 'nobody is picking up the work'?
  160. linuxwolf ralphm: it's more that "this is hard, and we don't know what to do"
  161. stpeter ralphm: unfortunately, few people care about internationalization, and even fewer know how to help
  162. ralphm or can take time to work on it
  163. stpeter however, I think we can see a realistic path forward
  164. linuxwolf /nod
  165. Kev stpeter: I realise I'm speaking as someone who does't understand this stuff, but I only see two options - either updating away from 'prep gives us something new and therefore isn't compatible, or it's not giving us anything that stringprep/fixed unicode versioning doesn't.
  166. stpeter I mean, what we're working on is based on / similar to what people are already using for domain names
  167. linuxwolf I think it's more that it's hard and daunting, so the motivation to work on it is less
  168. dwd FWIW, Isode folk have picked up some knowledge; I'll see if I can get some time from Alexey and Kurt on this.
  169. linuxwolf I've been getting a crash course from stpeter and hildjj
  170. linuxwolf it is daunting
  171. ralphm Kev: I see. And your point is that since the JIDs already appear in the stream header, you can't discover it?
  172. stpeter Kev: right -- we need to dig into those issues, which I plan to do Real Soon Now™
  173. stpeter ralphm: right
  174. linuxwolf Kev: it's not clear if it will really break in the practical sense, or just the theoretical sense
  175. linuxwolf or at least not clear to me
  176. stpeter yeah
  177. stpeter well, further updates on the way :)
  178. stpeter next item?
  179. linuxwolf the fixed unicode is, or will be very soon, breaking in the practical sense
  180. MattJ I don't think it needs a version bump
  181. dwd Kev, I think we may need to signal in the <stream:stream>, but it's not clear this is a full version-break.
  182. linuxwolf MattJ: I don't think it's clear yet
  183. ralphm linuxwolf: so we need to assert the risk of breakage and decide if we think that is generally acceptable
  184. Fritzy So, how was the weather?
  185. linuxwolf ralphm: basically…there's more to it, but that's one of the big things
  186. MattJ if the JID is valid, who cares about the version? if it's invalid (and should be valid) then there's a broken interop whether we bump the version or no
  187. Kev So, was that the total for the WG meet?
  188. linuxwolf Fritzy: warm, but not unpleasant (-:
  189. linuxwolf there was an E2E presentation of sorts (-:
  190. ralphm Well, if we ever change the version number, I have a wish list
  191. ralphm :-D
  192. linuxwolf that is basically waiting on output from WOES cum JOSE
  193. dwd linuxwolf, That's just a tradition, now, right?
  194. Kev MattJ: Unless it's valid, or different, under different profiles and you need to signal the profile. If you have a profile in common you can interop, otherwise not. This can be a version number, or just another top level attribute on the stream header.
  195. linuxwolf dwd: essentially (-:
  196. MattJ ralphm, you and how many other people? :)
  197. ralphm MattJ: how is that relevant :-P
  198. MattJ Kev, true, valid but "different" would be awkward
  199. stpeter forget about XMPP 1.0+, just use WebSocket
  200. Kev linuxwolf: Is there more to say on e2e?
  201. Kev Or shall we move onto MattJ's AOB for the last 2 minutes?
  202. MattJ stpeter, because those guys really have their act together
  203. ralphm stpeter: hehe
  204. dwd stpeter, Can't on S2S, neither end would know which one should be encrypting their output.
  205. Kev MattJ: You wanted to AOB about the LC feedback?
  206. MattJ Right
  207. linuxwolf Kev: there's a WG forming for "better" crypto options, which is now called JOSE…otherwise nothing concrete yet
  208. MattJ Kev, it was just a thought that I had before the meeting
  209. MattJ that it's not uncommon for us to have no LC feedback, despite implementations existing
  210. MattJ and I'm wondering if that's something we can improve on
  211. ralphm MattJ: which could either mean our specs are awesome, or nobody cares to write up issues?
  212. MattJ ralphm, nobody cares, most certainly :)
  213. linuxwolf heh
  214. Tobias the latter
  215. linuxwolf yeah
  216. MattJ I'm just wondering if we should make it someone's responsibility to research implementations and reach out to these people
  217. Kev ralphm: If they were awesome, but people cared, they'd still reply to the "Is this spec alright?" mail.
  218. MattJ I know that's what we're doing already, typically
  219. MattJ but only after the first LC period fails
  220. Kev Right.
  221. ralphm So would it help to approach the (known) implementers more directly?
  222. Kev A question to send out to list, probably.
  223. linuxwolf /hnod
  224. MattJ ralphm, that's the idea
  225. linuxwolf /nod even
  226. Kev As we've just hit half past so we're out of time.
  227. stpeter it seems to me that dedicated protocols like SIP and XMPP and IMAP are going away for client-to-server interactions, and we'll just be left with WebSocket and JavaScript APIs -- however, we'll still need s2s protocols for federation purposes (if anyone ever wants to federate in the brave new world of web silos
  228. MattJ stpeter, you can be cynical sometimes :)
  229. linuxwolf stpeter: I don't think that's true at all
  230. stpeter MattJ: just reading the writing on the wall
  231. stpeter or maybe I just need a vacation
  232. Fritzy Well, stpeter is right that there is that trend
  233. MattJ Looking at a different wall to me
  234. MattJ There's hype
  235. Fritzy but I don't think it'll be ultimately to that side
  236. MattJ I don't know if that constitutes trend just yet
  237. linuxwolf stpeter: except those WS + JS end up using something that looks an awful lot like XMPP or SIP or IMAP d-:
  238. stpeter linuxwolf: perhaps, yeah
  239. Kev In any case, I think we're done.
  240. Kev Any other any other?
  241. MattJ None from me
  242. stpeter meeting is done, I think
  243. linuxwolf nay
  244. ralphm just like Ruby is taking over the world
  245. Kev Righty.
  246. Kev Thanks all
  247. Fritzy :)
  248. Tobias lol
  249. Fritzy ciao!
  250. linuxwolf haha
  251. stpeter ralphm: Ruby forever!
  252. Kev gangs the bavel.
  253. MattJ I'll email standards@ about LC
  254. stpeter MattJ: thanks
  255. linuxwolf grazíe
  256. ralphm MattJ: I'll bet you get loads of responses
  257. stpeter clearly Lua is taking over the world ;-)
  258. MattJ ralphm, :)
  259. linuxwolf ¡chao!
  260. stpeter glances at the Lua book that linuxwolf just loaned him
  261. MattJ stpeter, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html :)
  262. ralphm I do think lua is kinda cool
  263. linuxwolf stpeter: it's really hildjj's (-:
  264. Tobias MattJ, right there trending with Transact-SQL
  265. linuxwolf although JavaScript is the new Ruby…with Lua maybe the new Python d-:
  266. ralphm I /was/ kind of surprised finding out that prosody doesn't respond well to a 4G lua file with offline storage
  267. linuxwolf ok, off to my next meeting
  268. MattJ ralphm, lovely
  269. MattJ ralphm, FWIW we're working on that :)
  270. ralphm MattJ: well, it was also something I needed to fix on my end
  271. ralphm they were piling up pubsub notifications for resources that were no longer listening
  272. MattJ Sure, but if you want 4GB of offline messages...
  273. Tobias has left
  274. Fritzy has left
  275. Tobias has joined
  276. linuxwolf has left
  277. linuxwolf has joined
  278. MattJ has left
  279. MattJ has joined
  280. Neustradamus has joined
  281. Tobias how long is a Last Call period?
  282. linuxwolf a fortnight, IIRC
  283. linuxwolf "The Last Call shall expire not less than fourteen (14) days after the date of issue."
  284. linuxwolf so, a fortnight is a minimum (-:
  285. stpeter sometimes we declare longer review periods
  286. stpeter e.g., for large or controversial specs
  287. ralphm 15 is right out, so is 13, unless followed by 14
  288. stpeter or if there are some holidays in the middble
  289. linuxwolf or extend them
  290. stpeter that too
  291. ralphm :-D
  292. ralphm has left
  293. Neustradamus has left
  294. MattJ has left
  295. Neustradamus has joined
  296. stpeter has left
  297. stpeter has joined
  298. dwd Tobias, Extending Last Calls is specifically allowed: If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the XMPP Council, extend the Last Call or issue a new Last Call if the XEP requires further discussion.
  299. stpeter and we've done that in the past
  300. dwd Right, I recall a few times, actually.
  301. Tobias interesting
  302. Tobias http://jabber.markmail.org/ <-- watching that activity graph we soon are at about 0 :)
  303. stpeter Tobias: interesting
  304. stpeter not that different from, say, http://spamassassin.markmail.org/
  305. Tobias stpeter, but spam is decreasing year over year..so that's no surprise ;)
  306. stpeter heh maybe
  307. Tobias but it's not just that graph..i've been noticing quite a decline in xmpp related mailing list activity...don't know if that's due to work on new standard or whatever
  308. stpeter Tobias: agreed
  309. stpeter I think XMPP has become a stable, boring technology
  310. stpeter or most of the energy is moving to things like node.js and websockets
  311. stpeter not quite sure yet
  312. dwd Tobias, It's a sign that we're not working on anything interesting right now.
  313. linuxwolf it's not the new hotness (-:
  314. stpeter heh
  315. stpeter it's the old hotness?
  316. Tobias dwd, file transfer is interesting...since it's the thing that never works :P
  317. dwd Tobias, But I wouldn't read too much into that - IMAP went dead for several years then popped back up for all the mobile mail stuff.
  318. linuxwolf it could heat up again when people realize that WebSockets turned out to be warmed over cometd/BOSH (-: /ducks
  319. stpeter laughs
  320. dwd linuxwolf, WS is, in principle, faster, except that the repeated buffering and XORs are, I think, going to wear away some of that benefit.
  321. dwd linuxwolf, The interesting question is whether it'll fly on mobile. Very little mobile experience in that group, and there's the usual crop of "Well, I heard that on mobile [...]".
  322. linuxwolf dwd: yeah, we'll see
  323. Tobias isn't WebSocket still going over TCP?
  324. linuxwolf I've still got my doubts
  325. linuxwolf Tobias: it's worse than that
  326. dwd Tobias, Yes, but TCP is fine on mobile.
  327. dwd Tobias, You've got to get much worse networks for TCP to be a problem.
  328. Tobias dwd, Apple seems to think different, watched a couple of sessions from their last WWDC, they discourage any long living connection. I guess other mobile vendors think different. Opening TCP connections over and over again can't be that good for speed/latency/battery/etc.
  329. Tobias or not?
  330. linuxwolf I guess watching that train wreak…er, mailing list…made me a bit jaded
  331. dwd Tobias, On the vast majority of mobile networks, you can leave a TCP session open and happy for 15 minutes or more, these days.
  332. dwd Tobias, That is, without sending any traffic at all.
  333. linuxwolf /nod
  334. Tobias dwd, while traveling through half the country?
  335. dwd I've certainly held TCP sessions whilst on a train. I even held them through the Severn Tunnel a couple of times during Council meetings. :-)
  336. linuxwolf Tobias: from my limited experience, as long as I don't drop below a certain signal threshold, I've been fine
  337. linuxwolf but I'm in the US (-:
  338. stpeter OT: does anyone care about jabberpowered.org anymore? I need to decide whether to renew the domain registration :)
  339. linuxwolf we still had that?
  340. stpeter yep
  341. stpeter every year I try to decide whether I still need to renew it :)
  342. linuxwolf heh
  343. stpeter decides to register a different domain name instead
  344. linuxwolf thefutureiswebsocketsnotxmpp.com?
  345. Tobias heh
  346. stpeter :)
  347. Marcus has joined
  348. stpeter has left
  349. linuxwolf has left
  350. Neustradamus has left
  351. Neustradamus has joined
  352. linuxwolf has joined
  353. Marcus has left
  354. linuxwolf has left
  355. Tobias has left