XMPP Council - 2011-10-05

  1. Kev has joined

  2. Neustradamus has left

  3. Neustradamus has joined

  4. Kev has left

  5. Kev has joined

  6. stpeter has joined

  7. Kev

    I'm going to pop out for a couple of minutes. Should be back for the meeting in 40mins, but if I'm a couple of minutes late...apologies.

  8. stpeter

    ok, no worries

  9. linuxwolf has joined

  10. linuxwolf has left

  11. linuxwolf has joined

  12. Neustradamus has left

  13. Neustradamus has joined

  14. linuxwolf


  15. linuxwolf has left

  16. linuxwolf has joined

  17. linuxwolf has left

  18. linuxwolf has joined

  19. linuxwolf


  20. linuxwolf

    this is going to be interesting …

  21. linuxwolf

    the power is on and off at home today

  22. linuxwolf

    so I might not be able to stay in this meeting

  23. Lance Stout has joined

  24. Kev


  25. linuxwolf


  26. Kev

    A neutrino walks into a bar.

  27. linuxwolf

    "No charge"

  28. stpeter

    An infinite number of mathematicians walk into a bar.

  29. linuxwolf

    so, I'm getting solar panels installed today…was supposed to be done yesterday

  30. MattJ has joined

  31. linuxwolf

    so if I drop, it's because they're switching from evil grid-based electricity to good sun-based electricity

  32. stpeter

    but at least you're saving the planet!

  33. Kev

    Remind me where the energy for the grid-based electricity comes from :)

  34. linuxwolf


  35. Kev

    It's some big glowing thing somewhere.

  36. Kev

    But I'm sure it must be evil :D

  37. linuxwolf

    mostly I don't want another rate hike

  38. linuxwolf

    "since you're doing such a good job conserving energy, we're rewarding you with a higher rate"

  39. linuxwolf

    ok, quick run for caffeine … should be back in two minutes

  40. stpeter

    Ralph appears to be offline

  41. Kev

    And it's 4pm.

  42. stpeter

    correction, he's just away

  43. Kev

    So let's start.

  44. Kev

    1) Roll call.

  45. Kev

    I'm here.

  46. Kev

    MattJ? linuxwolf?

  47. MattJ


  48. stpeter

    clearly linuxwolf hasn't found coffee yet

  49. linuxwolf


  50. linuxwolf

    now I'm here

  51. Kev


  52. Kev

    2) 296.

  53. Kev

    linuxwolf: do you want to call for a vote on this, or leave it in Last Call for a while?

  54. Kev

    I still think that this breaks caps.

  55. linuxwolf

    it can stay in LC awhile longer

  56. linuxwolf

    can you explain how it break capabilities

  57. Kev

    Whenever you unlock a chat, you no longer have caps available to you for the current chat.

  58. Kev

    So, for example, CSN will stop working every time you unbind the chat.

  59. Kev

    Currently 296 recommends/mandates unlocking in situations where it's completely redundant (only one resource available, but you still unbind because it changed status) - but beyond this all this unbinding means you break caps far more often than you need to.

  60. linuxwolf

    I'll think about language for single resource

  61. linuxwolf

    I will tell you that when multiple clients are in place, this is working very wonderfully

  62. Kev

    I take the point of there being some semi-broken clients out there on board as an argument for always unlocking on presence of anything anywhere, but the consequences of this for well-behaved clients (and this *is* a list of best practise, rather than how to work around dodgy clients and gateways) are negative.

  63. Kev


  64. linuxwolf

    you're assuming that a change availability MUST mean a change in <show/>

  65. Kev

    I'm assuming that's the typical case, yes.

  66. Kev

    Without statistics to the contrary, I think it's probably true, too.

  67. linuxwolf

    I don't think that's a vaild assumption

  68. Astro has joined

  69. linuxwolf

    it's not a valid assumption on the networks I've worked with … some of them being buggy clients but a lot of them having legitimate reasons for it

  70. stpeter

    it's not infrequent that I change from dnd "in a meeting" to dnd "on a conference call" or whatever

  71. Kev

    linuxwolf: Networks on the Internet?

  72. linuxwolf

    still available but in a meeting

  73. Kev

    stpeter: These are the same status, though - you're still DND.

  74. stpeter

    different status, same show

  75. Kev

    Right, I didn't mean same <status/>

  76. Zash has joined

  77. Kev

    You are still saying "Don't disturb me".

  78. Kev

    With the proposed unlocking scheme, you start getting messages because of this change, which doesn't seem right at all.

  79. linuxwolf

    when I had more capable clients, I would switch priorities and statuses, but not <show/>

  80. stpeter

    Kev: clearly I need to review it more closely

  81. linuxwolf

    and there are clients that allow for that, even if the user doesn't really realize it

  82. Kev

    linuxwolf: A switch of priority is a good reason to unlock, I think.

  83. linuxwolf

    it's a crucial reason to unlock

  84. linuxwolf

    I think it's also important to unlock if you get a new caps hash

  85. Kev

    I'll buy that, too.

  86. linuxwolf

    but instead of adding a million special cases, we tried this

  87. linuxwolf

    it seems to be working very well

  88. linuxwolf

    for about 6 years now between all the clients I've had influence with (-:

  89. Kev

    I'm not arguing that there's no deployments, especially when using corporate gateways potentially, where the proposed scheme works well.

  90. Kev

    I don't think it's the right thing for the Internet, though.

  91. linuxwolf

    the internet is not the majority of users

  92. linuxwolf

    not by a long long shot

  93. Tobias has joined

  94. linuxwolf

    if we're going to write our protocols for a minority, we're going to get into trouble

  95. MattJ

    I wouldn't call the internet a minority either :)

  96. linuxwolf

    of XMPP users, it most certainly is

  97. MattJ

    I'm quiet because I'm not sure what the correct solution is... resource locking in general feels more like a hack to me daily

  98. linuxwolf

    *most* of us are on some sort of private or corporate service

  99. linuxwolf

    MattJ: While I can see that, I'm not sure how else we get there

  100. MattJ

    When I say I'm not sure what the correct solution is, I suggest there might not be one... we need to decide what we're designing for and choose the best option possible

  101. linuxwolf

    SIMPLE+MSRP seems worse to me (-:

  102. MattJ

    Well you're clearly using this in production, and you're saying this logic works

  103. linuxwolf


  104. Kev

    linuxwolf: If you're writing this XEP for non-federating deployments, then call it Best Practices for Internal Corporate Resource Locking or something, and I don't have issue with it, and we can come up with another one for the public network.

  105. linuxwolf

    Kev: this is federating

  106. MattJ

    I agree with Kev though that e.g. a repeated <presence/> shouldn't really cause an unlock

  107. stpeter

    I think it's difficult to say where the majority of deployment occurs.....

  108. linuxwolf

    for the most part, presence changes don't happen that often for a given indivdual

  109. stpeter

    perhaps do we need to do a bit of research here?

  110. Kev

    Or just listing the assumptions and requirements in the protoXEP as a start.

  111. linuxwolf

    I can add a list of assumptions

  112. Kev

    Ok, moving on then.

  113. Kev

    3) Account management.

  114. Kev

    Are we satisfied with the state of community feedback to the point that we can now reject/accept it?

  115. linuxwolf

    in it's current form, I think so

  116. Kev

    In the weeks the discussion's been open, I've yet to see anyone argue in favour of it, so if we're doing this now I'm -1.

  117. linuxwolf


  118. stpeter will read 296 again

  119. linuxwolf

    Jehan did just state he'd been out of contact, so was not able to respond

  120. Kev


  121. Kev

    Although ideally I'd like to see someone other than the author think it's a good idea to publish it.

  122. Kev

    But I'm happy to put this off for another week.

  123. MattJ

    Yes, I don't see his reply yet

  124. linuxwolf

    so, calling the linuxwolf from a minute ago a moron, we might want to give him a few days to respond

  125. Kev

    4) Server Dialback - the way forward.

  126. MattJ

    I'm in favour of that

  127. MattJ

    Quite an agenda today :)

  128. linuxwolf


  129. stpeter


  130. Kev

    stpeter: Over to you.

  131. stpeter

    so I updated XEP-0220 to incorporate a few bug reports

  132. stpeter

    have not heard from fippo since then, although it took me months to reply to him the last time!

  133. stpeter

    it might make sense to hold another Last Call

  134. Kev

    I think the way forward is for Peter to put out a new version 220, start a new LC and go from there. If Fippo, or any other authors, think there are bugs in the spec, they can also propose a new version (or a rollback), and we can compare in LC.

  135. stpeter


  136. linuxwolf


  137. stpeter


  138. Kev


  139. Kev

    5) 234.

  140. MattJ

    Me too

  141. linuxwolf

    we need to push on that

  142. linuxwolf

    or maybe the next council does (-:

  143. stpeter

    so, about 234, I think the primary thing is the hashes spec http://xmpp.org/extensions/xep-0300.html

  144. stpeter

    Tobias and others might have feedback more directly related to 234

  145. Kev

    I think we can probably LC 300 if we want to.

  146. Kev

    It's fairly simple.

  147. stpeter

    but we can't advance 234 until we advance 300

  148. linuxwolf

    /nod to both

  149. stpeter

    one thought: we might want to look at how 300 would slot into other extensions

  150. Kev

    stpeter: Is that a prerequisite to advancing 300?

  151. stpeter

    so that we can figure out if it's generic enough

  152. stpeter

    Kev: well, I'd hate to advance it while thinking that it solves all problems when it solves only the file transfer problem

  153. Kev


  154. stpeter

    one concern I have is that existing protocols might use hashes as attributes, not elements

  155. MattJ

    I seem to remember a post where you listed the possible other protocols that could use it

  156. stpeter

    so we'd need to see how to retrofit

  157. stpeter

    MattJ: probably, I need need to go back and look at those

  158. stpeter

    but we could do that during LC

  159. linuxwolf


  160. stpeter

    I just wanted to raise the issue so we're thinking about it

  161. linuxwolf

    It's hard to apply multiple hashes in an attribute though (-:

  162. stpeter

    that's all from me

  163. stpeter

    linuxwolf: right :)

  164. Kev

    Ok then. So I see this as nothing for Council to do but wait for Peter to look at updating other XEPs for 300.

  165. Kev

    6) -0009

  166. Kev

    Not something I ever expected to discuss in a Council meeting.

  167. stpeter

    Kev: sure

  168. stpeter


  169. Kev

    I thought it was a) dead and b) ancient :)

  170. stpeter

    it would require a new version to correct that error

  171. linuxwolf


  172. stpeter


  173. stpeter


  174. stpeter

    well, periodically we receive reports of people using it

  175. MattJ

    Wait, what's up with 0009? Have I missed a mail?

  176. stpeter

    MattJ: yes, you have

  177. Kev

    [Standards] Regarding capitalization of base64 type in Jabber-RPC (XEP-0009)

  178. linuxwolf

    <base64/> vs <Base64/>

  179. MattJ

    Ah, that one!

  180. stpeter


  181. MattJ

    Sorry, I remember now... forgot which spec was under discussion in that thread :)

  182. Kev

    So we should just update -9 to use the right caps, shouldn't we?

  183. stpeter

    I think so

  184. linuxwolf


  185. Kev


  186. stpeter

    I think the book from which we borrowed the XML schema is simply wrong

  187. Kev

    It's final. This is an incompatible change.

  188. stpeter

    I am happy to check with Dave Winer

  189. Kev

    So I guess we shouldn't and should live with the wart.

  190. linuxwolf


  191. linuxwolf


  192. MattJ

    Time for XMPP-RPC? :)

  193. linuxwolf

    we have that with XEP-0004 d-:

  194. linuxwolf


  195. Kev

    We *could* update -9 with a new namespace and a note saying that in the new namespace you use the right case but everything else is identical.

  196. linuxwolf

    I'm not convinced we should change −0009, personally

  197. linuxwolf

    if we change it, it's to add language that we acknowledge our fallibilities

  198. stpeter

    we might want to at least document the wart

  199. linuxwolf


  200. Kev


  201. MattJ

    OTOH, it's just a schema issue, right?

  202. linuxwolf


  203. MattJ

    Well, we've typically declared our schemas as informational only

  204. Kev

    MattJ: Right, but unfortunately the schema is the only content of xep9.

  205. stpeter


  206. Kev

    So there's no text that contradicts the schema or anything.

  207. stpeter


  208. MattJ

    So this could be construed as an editorial issue... perhaps ;)

  209. stpeter

    the spec says: There is no official XML schema for XML-RPC. The main body of this schema has been borrowed from an unofficial schema representation contained in the book "Processing XML With Java" by Elliotte Rusty Harold

  210. stpeter

    I would expect existing XML-RPC libraries to use <base64/>

  211. stpeter

    so I think further research might be useful

  212. Kev


  213. Kev

    So is the right/easy thing to do to copy/paste xep9 into xep3xx, change that one thing plus the namespace, and obsolete xep9?

  214. MattJ

    +1 to research, what actually breaks if we change it is what counts

  215. stpeter


  216. linuxwolf

    +1 to research

  217. Kev

    Asking people who've implemented what happens if we change it is fine by me.

  218. Kev


  219. Kev

    7) Next date.

  220. linuxwolf

    SBTSBC works for me

  221. Kev

    Next week's going to be somewhere between impossible and P(0) for me, i think.

  222. stpeter

    http://groovy.codehaus.org/Groovy+Jabber-RPC and all that

  223. linuxwolf

    or not (-:

  224. stpeter

    I will be offline next week

  225. Kev

    Council *can* have a meeting without me if they want, but it's being a bit optimistic expecting quorum :)

  226. MattJ is calculating dates

  227. linuxwolf

    so … is this the last meeting this term?

  228. stpeter


  229. stpeter

    possibly, yes

  230. MattJ

    I can do next week, the week after is hard for me

  231. MattJ


  232. Kev

    Next term starts 25th, IIRC

  233. linuxwolf

    anytime in Oct works for me

  234. stpeter

    October 19 would be within this term

  235. linuxwolf

    10/12 is impossible for Kev, and 10/19 is hard for MattJ

  236. linuxwolf

    assuming elections are the week of 10/23, that would make this meeting the last

  237. Kev

    I'm working, but I'm in the office and there are only a few hours everyone will be there.

  238. MattJ

    Maybe different days for next week could work?

  239. MattJ

    We can always pick one on list if we need to discuss something

  240. linuxwolf

    I'm open to any day but Tuesday

  241. Kev

    Well, I'm in the office all week next week, but can probably sort something out on Tuesday... :)

  242. Kev

    Monday, maybe, at a pinch, but it'd be hard.

  243. linuxwolf

    Tuesday is impossible for me, unless it's after 13:00 MDT

  244. linuxwolf

    I have a sprint planning meeting, and they go about 4 hours

  245. Kev

    We could try Monday or Tuesday of the week of the 25th.

  246. Kev

    Just before term ends.

  247. Kev

    Assuming we have anything to discuss, of course.

  248. stpeter

    http://search.cpan.org/~qmacro/Jabber-RPC-0.01/lib/Jabber/RPC.pm uses http://search.cpan.org/~rtfirefly/Frontier-RPC-0.07b4p1/lib/Frontier/RPC2.pm and that has <base64>

  249. linuxwolf

    let's see where we're at on Friday, and go from there

  250. stpeter

    just FYI :)

  251. MattJ


  252. stpeter

    and Fronter::RPC2 is probably the reference implementation

  253. Kev

    stpeter: So maybe no-one implements the XEP and we should fix it.

  254. Kev


  255. Kev

    We're way gone tolerance now.

  256. stpeter


  257. linuxwolf


  258. MattJ


  259. stpeter

    I'll do more research

  260. MattJ

    Kev is going to explode

  261. Kev

    Shall we call for a meeting onlist if it turns out we have something to discuss, but otherwise assume this was the last meeting?

  262. linuxwolf

    that's what I was suggesting (-:

  263. stpeter


  264. MattJ


  265. Kev

    8) AOB

  266. Kev

    And risk my wrath :p

  267. Kev


  268. Kev

    Jolly good :)

  269. Kev

    Thanks all.

  270. Kev bangs the gavel.

  271. MattJ


  272. MattJ

    I had an AOB for 17 minutes!

  273. MattJ

    Just to see what would happen

  274. stpeter watches Kev press the Smite button on his keyboard

  275. linuxwolf

    I've already blown off one meeting

  276. linuxwolf considers slapping MattJ with a dead trout

  277. Kev

    I hope they enjoyed that.

  278. linuxwolf

    I'll find out in about 30 seconds (-:

  279. linuxwolf

    it's at 9:30 MDT

  280. Kev

    We seem to be short of a MattJ on the Council applications at the moment.

  281. MattJ


  282. MattJ

    I'll write it

  283. Kev

    Jolly good.

  284. linuxwolf

    you have until Sunday

  285. MattJ

    Oh, that's ok then

  286. MattJ

    I'll write it on Sunday

  287. MattJ

    I'm useless at writing about myself

  288. linuxwolf


  289. linuxwolf

    1) find last year's page

  290. linuxwolf

    2) copy

  291. MattJ


  292. linuxwolf

    3) paste

  293. linuxwolf


  294. linuxwolf

    4) minor edits for changes in priorities

  295. linuxwolf


  296. MattJ

    The wiki looks very smart, I rarely go to the front page

  297. stpeter

    http://svn.python.org/projects/python/trunk/Lib/xmlrpclib.py has <base64>

  298. MattJ

    We're winning

  299. linuxwolf

    no, we're losing (-:

  300. stpeter

    I'll keep pasting data points here

  301. linuxwolf digs up JSO

  302. MattJ

    linuxwolf, I'm still in favour of changing the schema

  303. MattJ

    It's 1 byte!

  304. stpeter is of the opinion that this is a schema correction and the schema was always informative anyway

  305. linuxwolf

    I know there's a few people using it for PRC

  306. linuxwolf

    RPC even

  307. MattJ

    Me too

  308. linuxwolf


  309. Kev

    In this situation I'm not opposed to correcting the XEP.

  310. Zash

    case is 1 bit diff in ASCII

  311. MattJ

    Update the schema with a note that the update was made to correct the schema and reflect reality

  312. linuxwolf

    I use UTF-32, you insensitive clods

  313. linuxwolf

    (which is also a 1-bit difference, yes)

  314. linuxwolf

    I starting to accept a schema change, as long as we add some text about what it used to be

  315. linuxwolf

    and that such text is not only found in the Revision History!

  316. stpeter

    for sure

  317. stpeter

    http://ditchnet.org/xmlrpc/ has <base64>

  318. Kev

    Ok, Jury's in, then.

  319. stpeter

    the qxmpp library seems to have <base64>

  320. stpeter

    http://www.ntecs.de/ruby/xmlrpc4r/ has <base64>

  321. MattJ


  322. Lance Stout

    SleekXMPP uses Base64, but I can change that

  323. MattJ


  324. MattJ

    Lance Stout, nice :)

  325. stpeter

    http://hg.python.org/cpython/file/2.7/Lib/xmlrpclib.py has <base64>

  326. stpeter

    I might be finding repeats at this point....

  327. stpeter

    all this because someone pressed the shift key a little too long

  328. MattJ


  329. linuxwolf

    and it's the only one that's capitalized, too

  330. linuxwolf

    that's even funnier

  331. stpeter

    which one?

  332. linuxwolf


  333. stpeter


  334. stpeter


  335. stpeter

    the xmppframework libraryhas <base64> .... http://code.google.com/p/xmppframework/source/browse/Extensions/XEP-0009/XMPPIQ%2BJabberRPC.m?spec=svnb6dfb5e2b007bb59043f82a7156a3710e4bbcb13&r=b6dfb5e2b007bb59043f82a7156a3710e4bbcb13

  336. Astro has left

  337. Zash has left

  338. Lance Stout has left

  339. linuxwolf has left

  340. linuxwolf has joined

  341. Astro has joined

  342. Tobias has joined

  343. linuxwolf has left

  344. linuxwolf has joined

  345. linuxwolf has left

  346. linuxwolf has joined

  347. linuxwolf has left

  348. linuxwolf has joined

  349. Neustradamus has joined

  350. Tobias has left

  351. linuxwolf has left

  352. Astro has left