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


  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


  22. Fritzy has joined

  23. Kev

    Right, it is time.

  24. Kev

    1) Roll call.

  25. Kev

    I'm here!

  26. Fritzy


  27. linuxwolf


  28. MattJ


  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


  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


  50. linuxwolf


  51. Kev

    Can we put off 260 and 261 until next week, and chase people in the meantime for feedback?

  52. linuxwolf


  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


  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


  86. stpeter


  87. MattJ

    Same logic from me

  88. Fritzy


  89. linuxwolf

    there's more consensus on jingle@ mailing list

  90. ralphm


  91. ralphm

    ehm, +1

  92. MattJ


  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


  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


  102. Kev

    5) Time of next meeting?

  103. Kev

    Next week, same time?

  104. stpeter


  105. ralphm


  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


  112. Kev

    6) AOB.

  113. ralphm


  114. Kev

    Québec report from Peter/Matt:

  115. linuxwolf


  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


  123. linuxwolf

    I need to get a better client

  124. linuxwolf

    or write one /ducks

  125. linuxwolf


  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


  131. linuxwolf


  132. linuxwolf


  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


  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


  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


  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


  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


  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


  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


  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


  214. Tobias

    the latter

  215. linuxwolf


  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


  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


  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


  244. ralphm

    just like Ruby is taking over the world

  245. Kev


  246. Kev

    Thanks all

  247. Fritzy


  248. Tobias


  249. Fritzy


  250. linuxwolf


  251. stpeter

    ralphm: Ruby forever!

  252. Kev gangs the bavel.

  253. MattJ

    I'll email standards@ about LC

  254. stpeter

    MattJ: thanks

  255. linuxwolf


  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


  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


  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


  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


  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


  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


  341. stpeter

    every year I try to decide whether I still need to renew it :)

  342. linuxwolf


  343. stpeter decides to register a different domain name instead

  344. linuxwolf


  345. Tobias


  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