XMPP Council - 2011-08-03

  1. stpeter


  2. MattJ

    Greetings stpeter

  3. linuxwolf waves

  4. stpeter

    MattJ: are still in NYC?

  5. MattJ

    How was Quebec?

  6. MattJ

    I am

  7. stpeter

    it was enjoyable

  8. Kev

    Evening all.

  9. stpeter

    nice place

  10. stpeter

    enjoyable and busy, of course

  11. linuxwolf

    very French (-:

  12. MattJ


  13. Kev

    Right, it is time.

  14. Kev

    1) Roll call.

  15. Kev

    I'm here!

  16. Fritzy


  17. linuxwolf


  18. MattJ


  19. linuxwolf

    dang…a full house?! unpossible!

  20. linuxwolf

    oh, no ralphm

  21. MattJ

    Don't get your hopes up :)

  22. Kev

    2) Promote XEP-0260 to Draft? http://mail.jabber.org/pipermail/standards/2011-June/024722.html

  23. linuxwolf

    +1; I think I found a couple cosmetic grammatical error, but not enough to hold it up

  24. Fritzy

    no traffic on the mailing list?

  25. MattJ

    Am I correct in that we had no LC feedback?

  26. linuxwolf

    not until this morning

  27. Kev

    Tobias had feedback on both.

  28. Kev

    (A few minutes ago)

  29. MattJ

    Oh, Tobias

  30. 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.

  31. MattJ

    So, I've implemented most of 260 - but it was some time ago, I'd like to know interop with someone worked

  32. MattJ

    I'd like to test with Tobias in particular

  33. MattJ

    and Gajim implements it I think, if we can track down the code (I'm not sure it's in trunk)

  34. Fritzy

    ok, well, sounds like 260 has at least two implementers

  35. Fritzy


  36. linuxwolf

    yeah, that was my sense

  37. dwd

    IIRC, Gajim's Jingle-FT is in a branch, yes.

  38. MattJ

    Implementers, no real world experience

  39. Fritzy


  40. linuxwolf


  41. Kev

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

  42. linuxwolf


  43. Fritzy

    Should we hold off on draft until we see some interop, at least anecdotally?

  44. Tobias

    there's also a pidgin branch implementing 260 and 261..at least claiming that

  45. MattJ

    dwd, Asterix told me he was merging it "tomorrow" about 6 months ago

  46. Fritzy

    cool, let's give it a week

  47. stpeter

    MattJ: :)

  48. linuxwolf

    the same would be true for 261, yes?

  49. Tobias

    well..IBB to pidgin works for me

  50. MattJ

    I'd like to bring up the last call issues in AOB

  51. 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.

  52. Kev

    stpeter: Your thoughts?

  53. dwd

    I note that proof of interop is not required by XEP-0001 for Draft.

  54. stpeter

    fine with me

  55. Kev

    dwd: Not required, but if we have known implementors, it makes sense to me to try to get feedback.

  56. Fritzy

    dwd: *nod* -- still, seems like we're blind without at least some evidence that it works.

  57. 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? ;-)

  58. Kev

    For the sake of a week.

  59. linuxwolf

    stpeter: heh

  60. Kev

    So, assuming that covers 3) Advance 261 to Draft as well...

  61. dwd

    True. Just noting that you don't *have* to. But specifically pinging implementors seems like a plan.

  62. Kev

    4) Advance 266 to Draft http://mail.jabber.org/pipermail/standards/2011-June/024625.html

  63. MattJ

    +1 from me, I think

  64. ralphm


  65. MattJ

    Hey ralphm :)

  66. linuxwolf

    +1 from me

  67. Kev

    Hi Ralph.

  68. Tobias

    stpeter, what's the epub symbol there on the WebRTC WG page? IETF publishing in ePub now? :)

  69. linuxwolf

    damn…we do have a full house

  70. linuxwolf


  71. stpeter

    re codecs, see also http://tools.ietf.org/html/draft-cbran-rtcweb-codec-00

  72. linuxwolf

    Tobias: some things, yes…sort of (-:

  73. 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).

  74. linuxwolf


  75. stpeter


  76. MattJ

    Same logic from me

  77. Fritzy


  78. linuxwolf

    there's more consensus on jingle@ mailing list

  79. ralphm


  80. ralphm

    ehm, +1

  81. MattJ


  82. linuxwolf


  83. 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.

  84. stpeter

    I like +!

  85. ralphm

    and agreed about #2 and #3

  86. stpeter

    or +¡

  87. Fritzy


  88. Kev

    So, noting there's two AOB items (Matt and Matt).

  89. ralphm

    there doesn't seem to be a unicode code point for [approved]

  90. linuxwolf


  91. Kev

    5) Time of next meeting?

  92. Kev

    Next week, same time?

  93. stpeter


  94. ralphm


  95. linuxwolf

    no news from Quebéc?

  96. linuxwolf

    and that date/time works for me

  97. Kev

    linuxwolf: That's your AOB item :)

  98. Kev

    Well, yours/PSA's.

  99. stpeter

    actually Québec :)

  100. linuxwolf


  101. Kev

    6) AOB.

  102. ralphm


  103. Kev

    Québec report from Peter/Matt:

  104. linuxwolf


  105. ralphm

    (expecting a large paste here)

  106. linuxwolf digs up email sent earlier...

  107. stpeter

    the main topics were s2s/DNA, i18n, and e2e encryption

  108. linuxwolf

    so, on the XMPP front...

  109. ralphm

    (wow, why are linuxwolf's /me messages styled in a huge font?)

  110. MattJ

    They seem to be XHTML-IM

  111. linuxwolf


  112. linuxwolf

    I need to get a better client

  113. linuxwolf

    or write one /ducks

  114. linuxwolf


  115. ralphm

    Before the last upgrade I patched gajim to disregard certain styles

  116. MattJ

    linuxwolf, join the club

  117. Fritzy

    ssshh, we're hearing a report

  118. ralphm

    in particular font-color, family and size

  119. linuxwolf


  120. linuxwolf


  121. linuxwolf


  122. Fritzy

    "the main topics were s2s/DNA, i18n, and e2e encryption"

  123. linuxwolf

    the biggest concern seemed to be around requiring tedious software upgrades (DNSSEC-based)...

  124. linuxwolf

    …or sharing cert+keys from the hostee to the hoster (cert-based)

  125. linuxwolf

    post-session, there was some agreement to a compromise...

  126. 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

  127. linuxwolf

    Joe Hildebrand and Eric Rescola were working on a draft, so I think something should be emerging in the next week or two

  128. Kev

    Which is really just the age-old trick of shifting-the-problem-without-solving-much.

  129. linuxwolf


  130. MattJ

    brb, switching to wifi (198 would be so useful right now)

  131. stpeter


  132. ralphm

    based on .well-known?

  133. linuxwolf

    and with the CA trust anchors in x.509 being less-than-stellar...

  134. linuxwolf

    ralphm: yes

  135. dwd

    I basically agree, but I think it's an achievable goal and workable if one assumes that it's a fallback from DNSSEC.

  136. linuxwolf


  137. ralphm

    yeah I can imagine the approach

  138. ralphm

    dwd: agreed

  139. ralphm

    'assumes' or 'requires'

  140. linuxwolf

    on the i18n front…it's basically see what happens in PRECÍS, although stpeter can comment more there

  141. stpeter

    yes, I've been pushing for progress on internationalization

  142. linuxwolf

    we'll need to do something

  143. stpeter

    I need to update the precis-framework document based on feedback received in Québec City

  144. linuxwolf


  145. 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...

  146. ralphm

    linuxwolf: as in 'nobody is picking up the work'?

  147. linuxwolf

    ralphm: it's more that "this is hard, and we don't know what to do"

  148. stpeter

    ralphm: unfortunately, few people care about internationalization, and even fewer know how to help

  149. ralphm

    or can take time to work on it

  150. stpeter

    however, I think we can see a realistic path forward

  151. linuxwolf


  152. 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.

  153. stpeter

    I mean, what we're working on is based on / similar to what people are already using for domain names

  154. linuxwolf

    I think it's more that it's hard and daunting, so the motivation to work on it is less

  155. dwd

    FWIW, Isode folk have picked up some knowledge; I'll see if I can get some time from Alexey and Kurt on this.

  156. linuxwolf

    I've been getting a crash course from stpeter and hildjj

  157. linuxwolf

    it is daunting

  158. ralphm

    Kev: I see. And your point is that since the JIDs already appear in the stream header, you can't discover it?

  159. stpeter

    Kev: right -- we need to dig into those issues, which I plan to do Real Soon Now™

  160. stpeter

    ralphm: right

  161. linuxwolf

    Kev: it's not clear if it will really break in the practical sense, or just the theoretical sense

  162. linuxwolf

    or at least not clear to me

  163. stpeter


  164. stpeter

    well, further updates on the way :)

  165. stpeter

    next item?

  166. linuxwolf

    the fixed unicode is, or will be very soon, breaking in the practical sense

  167. MattJ

    I don't think it needs a version bump

  168. dwd

    Kev, I think we may need to signal in the <stream:stream>, but it's not clear this is a full version-break.

  169. linuxwolf

    MattJ: I don't think it's clear yet

  170. ralphm

    linuxwolf: so we need to assert the risk of breakage and decide if we think that is generally acceptable

  171. Fritzy

    So, how was the weather?

  172. linuxwolf

    ralphm: basically…there's more to it, but that's one of the big things

  173. 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

  174. Kev

    So, was that the total for the WG meet?

  175. linuxwolf

    Fritzy: warm, but not unpleasant (-:

  176. linuxwolf

    there was an E2E presentation of sorts (-:

  177. ralphm

    Well, if we ever change the version number, I have a wish list

  178. ralphm


  179. linuxwolf

    that is basically waiting on output from WOES cum JOSE

  180. dwd

    linuxwolf, That's just a tradition, now, right?

  181. 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.

  182. linuxwolf

    dwd: essentially (-:

  183. MattJ

    ralphm, you and how many other people? :)

  184. ralphm

    MattJ: how is that relevant :-P

  185. MattJ

    Kev, true, valid but "different" would be awkward

  186. stpeter

    forget about XMPP 1.0+, just use WebSocket

  187. Kev

    linuxwolf: Is there more to say on e2e?

  188. Kev

    Or shall we move onto MattJ's AOB for the last 2 minutes?

  189. MattJ

    stpeter, because those guys really have their act together

  190. ralphm

    stpeter: hehe

  191. dwd

    stpeter, Can't on S2S, neither end would know which one should be encrypting their output.

  192. Kev

    MattJ: You wanted to AOB about the LC feedback?

  193. MattJ


  194. linuxwolf

    Kev: there's a WG forming for "better" crypto options, which is now called JOSE…otherwise nothing concrete yet

  195. MattJ

    Kev, it was just a thought that I had before the meeting

  196. MattJ

    that it's not uncommon for us to have no LC feedback, despite implementations existing

  197. MattJ

    and I'm wondering if that's something we can improve on

  198. ralphm

    MattJ: which could either mean our specs are awesome, or nobody cares to write up issues?

  199. MattJ

    ralphm, nobody cares, most certainly :)

  200. linuxwolf


  201. Tobias

    the latter

  202. linuxwolf


  203. MattJ

    I'm just wondering if we should make it someone's responsibility to research implementations and reach out to these people

  204. Kev

    ralphm: If they were awesome, but people cared, they'd still reply to the "Is this spec alright?" mail.

  205. MattJ

    I know that's what we're doing already, typically

  206. MattJ

    but only after the first LC period fails

  207. Kev


  208. ralphm

    So would it help to approach the (known) implementers more directly?

  209. Kev

    A question to send out to list, probably.

  210. linuxwolf


  211. MattJ

    ralphm, that's the idea

  212. linuxwolf

    /nod even

  213. Kev

    As we've just hit half past so we're out of time.

  214. 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

  215. MattJ

    stpeter, you can be cynical sometimes :)

  216. linuxwolf

    stpeter: I don't think that's true at all

  217. stpeter

    MattJ: just reading the writing on the wall

  218. stpeter

    or maybe I just need a vacation

  219. Fritzy

    Well, stpeter is right that there is that trend

  220. MattJ

    Looking at a different wall to me

  221. MattJ

    There's hype

  222. Fritzy

    but I don't think it'll be ultimately to that side

  223. MattJ

    I don't know if that constitutes trend just yet

  224. linuxwolf

    stpeter: except those WS + JS end up using something that looks an awful lot like XMPP or SIP or IMAP d-:

  225. stpeter

    linuxwolf: perhaps, yeah

  226. Kev

    In any case, I think we're done.

  227. Kev

    Any other any other?

  228. MattJ

    None from me

  229. stpeter

    meeting is done, I think

  230. linuxwolf


  231. ralphm

    just like Ruby is taking over the world

  232. Kev


  233. Kev

    Thanks all

  234. Fritzy


  235. Tobias


  236. Fritzy


  237. linuxwolf


  238. stpeter

    ralphm: Ruby forever!

  239. Kev gangs the bavel.

  240. MattJ

    I'll email standards@ about LC

  241. stpeter

    MattJ: thanks

  242. linuxwolf


  243. ralphm

    MattJ: I'll bet you get loads of responses

  244. stpeter

    clearly Lua is taking over the world ;-)

  245. MattJ

    ralphm, :)

  246. linuxwolf


  247. stpeter glances at the Lua book that linuxwolf just loaned him

  248. MattJ

    stpeter, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html :)

  249. ralphm

    I do think lua is kinda cool

  250. linuxwolf

    stpeter: it's really hildjj's (-:

  251. Tobias

    MattJ, right there trending with Transact-SQL

  252. linuxwolf

    although JavaScript is the new Ruby…with Lua maybe the new Python d-:

  253. ralphm

    I /was/ kind of surprised finding out that prosody doesn't respond well to a 4G lua file with offline storage

  254. linuxwolf

    ok, off to my next meeting

  255. MattJ

    ralphm, lovely

  256. MattJ

    ralphm, FWIW we're working on that :)

  257. ralphm

    MattJ: well, it was also something I needed to fix on my end

  258. ralphm

    they were piling up pubsub notifications for resources that were no longer listening

  259. MattJ

    Sure, but if you want 4GB of offline messages...

  260. Tobias

    how long is a Last Call period?

  261. linuxwolf

    a fortnight, IIRC

  262. linuxwolf

    "The Last Call shall expire not less than fourteen (14) days after the date of issue."

  263. linuxwolf

    so, a fortnight is a minimum (-:

  264. stpeter

    sometimes we declare longer review periods

  265. stpeter

    e.g., for large or controversial specs

  266. ralphm

    15 is right out, so is 13, unless followed by 14

  267. stpeter

    or if there are some holidays in the middble

  268. linuxwolf

    or extend them

  269. stpeter

    that too

  270. ralphm


  271. 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.

  272. stpeter

    and we've done that in the past

  273. dwd

    Right, I recall a few times, actually.

  274. Tobias


  275. Tobias

    http://jabber.markmail.org/ <-- watching that activity graph we soon are at about 0 :)

  276. stpeter

    Tobias: interesting

  277. stpeter

    not that different from, say, http://spamassassin.markmail.org/

  278. Tobias

    stpeter, but spam is decreasing year over year..so that's no surprise ;)

  279. stpeter

    heh maybe

  280. 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

  281. stpeter

    Tobias: agreed

  282. stpeter

    I think XMPP has become a stable, boring technology

  283. stpeter

    or most of the energy is moving to things like node.js and websockets

  284. stpeter

    not quite sure yet

  285. dwd

    Tobias, It's a sign that we're not working on anything interesting right now.

  286. linuxwolf

    it's not the new hotness (-:

  287. stpeter


  288. stpeter

    it's the old hotness?

  289. Tobias

    dwd, file transfer is interesting...since it's the thing that never works :P

  290. 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.

  291. linuxwolf

    it could heat up again when people realize that WebSockets turned out to be warmed over cometd/BOSH (-: /ducks

  292. stpeter laughs

  293. 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.

  294. 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 [...]".

  295. linuxwolf

    dwd: yeah, we'll see

  296. Tobias

    isn't WebSocket still going over TCP?

  297. linuxwolf

    I've still got my doubts

  298. linuxwolf

    Tobias: it's worse than that

  299. dwd

    Tobias, Yes, but TCP is fine on mobile.

  300. dwd

    Tobias, You've got to get much worse networks for TCP to be a problem.

  301. 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.

  302. Tobias

    or not?

  303. linuxwolf

    I guess watching that train wreak…er, mailing list…made me a bit jaded

  304. 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.

  305. dwd

    Tobias, That is, without sending any traffic at all.

  306. linuxwolf


  307. Tobias

    dwd, while traveling through half the country?

  308. 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. :-)

  309. linuxwolf

    Tobias: from my limited experience, as long as I don't drop below a certain signal threshold, I've been fine

  310. linuxwolf

    but I'm in the US (-:

  311. stpeter

    OT: does anyone care about jabberpowered.org anymore? I need to decide whether to renew the domain registration :)

  312. linuxwolf

    we still had that?

  313. stpeter


  314. stpeter

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

  315. linuxwolf


  316. stpeter decides to register a different domain name instead

  317. linuxwolf


  318. Tobias


  319. stpeter