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 pong?
  15. linuxwolf has left
  16. linuxwolf has joined
  17. linuxwolf has left
  18. linuxwolf has joined
  19. linuxwolf testing
  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 pong
  25. linuxwolf ping?
  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 coal
  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 Present
  48. stpeter clearly linuxwolf hasn't found coffee yet
  49. linuxwolf ugh
  50. linuxwolf now I'm here
  51. Kev Righty.
  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 *practice
  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 yes
  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 although
  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 Yes.
  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 yes
  129. stpeter :P
  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 right
  136. linuxwolf /nod
  137. stpeter WFM
  138. Kev Ok.
  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 Ok.
  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 /nod
  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 no?
  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 oh
  173. stpeter heh
  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 right
  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 yeah
  185. Kev Although...
  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 /sigh
  191. linuxwolf probably
  192. MattJ Time for XMPP-RPC? :)
  193. linuxwolf we have that with XEP-0004 d-:
  194. linuxwolf /ducks
  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 right
  200. Kev Yes.
  201. MattJ OTOH, it's just a schema issue, right?
  202. linuxwolf "just"
  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 heh
  206. Kev So there's no text that contradicts the schema or anything.
  207. stpeter well
  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 Right.
  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 nod
  216. linuxwolf +1 to research
  217. Kev Asking people who've implemented what happens if we change it is fine by me.
  218. Kev Ok.
  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 hmm
  229. stpeter possibly, yes
  230. MattJ I can do next week, the week after is hard for me
  231. MattJ probably
  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 Yay
  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 Anyway.
  255. Kev We're way gone tolerance now.
  256. stpeter right
  257. linuxwolf (-:
  258. MattJ Heh
  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 yes
  264. MattJ +1
  265. Kev 8) AOB
  266. Kev And risk my wrath :p
  267. Kev No?
  268. Kev Jolly good :)
  269. Kev Thanks all.
  270. Kev bangs the gavel.
  271. MattJ Wait!
  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 Yes...
  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 dude
  289. linuxwolf 1) find last year's page
  290. linuxwolf 2) copy
  291. MattJ :D
  292. linuxwolf 3) paste
  293. linuxwolf (-:
  294. linuxwolf 4) minor edits for changes in priorities
  295. linuxwolf DONE
  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 http://louizatakk.fedorapeople.org/sleekxmpp-1.0-Beta2-0/sleekxmpp/plugins/xep_0009.py
  322. Lance Stout SleekXMPP uses Base64, but I can change that
  323. MattJ Base64
  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 Heh
  329. linuxwolf and it's the only one that's capitalized, too
  330. linuxwolf that's even funnier
  331. stpeter which one?
  332. linuxwolf Base64
  333. stpeter oh
  334. stpeter yeah
  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