XMPP Council - 2011-09-21

  1. xask has joined
  2. xask has left
  3. xask has joined
  4. xask has left
  5. stpeter has joined
  6. linuxwolf has joined
  7. stpeter greetings, and 30-minute warning :)
  8. Kev Moin.
  9. linuxwolf hola
  10. MattJ has joined
  11. stpeter and my dent didn't get posted at identi.ca -- perhaps their xmpp interface is not happy
  12. stpeter tweeted it instead :P
  13. Neustradamus stpeter: http://identi.ca/notice/84187967
  14. Kev has left
  15. linuxwolf yeah, I got nuttin'
  16. Kev has joined
  17. MattJ Kev's -30s meeting
  18. Neustradamus stpeter: oups: http://identi.ca/conversation/84183552#notice-84188156
  19. MattJ Interesting, what Gajim says the time is doesn't match my system clock...
  20. dbanes has joined
  21. stpeter Neustradamus: perhaps I need to use their website instead of the xmpp interface...
  22. Kev It's currently 2 minutes to the meeting in the Chair's time.
  23. linuxwolf MattJ: is it off by minutes, or hours? (-:
  24. MattJ Minutes
  25. MattJ Maybe it's drift from suspend/resume
  26. MattJ which one is correct I'm not sure :)
  27. linuxwolf hehe
  28. MattJ Ok, Gajim matches `date`, so it's just my taskbar that's wrong
  29. Neustradamus stpeter: yes
  30. dbanes Hi all, random visit while having a coffee...
  31. Kev Right, time for the meeting.
  32. Kev 1) Roll call.
  33. Kev I'm here.
  34. stpeter hi dbanes
  35. linuxwolf presente
  36. dbanes hi @stpeter [on mute now]
  37. Kev MattJ: Present?
  38. MattJ Present
  39. MattJ Sorry
  40. Kev Goodo.
  41. Kev No sign of Ralph, and Fritzy Is No More.
  42. MattJ :'(
  43. Kev Or, well, sign of Ralph but he's DND.
  44. stpeter Ralph is dnd with some strange status messages
  45. linuxwolf Ralph is doing development for some legacy social media site, apparently (-:
  46. stpeter heh yeah
  47. Kev 3) Move -260 to Draft?
  48. MattJ It could be XMPP related :)
  49. MattJ +1
  50. Kev 2, rather.
  51. linuxwolf +1
  52. Kev I'm assuming this is an easy +1 as we reviewed it not long ago and it's been marginally updated to reflect feedback since.
  53. Kev I'm +1 anyway
  54. Kev 3) 261?
  55. Kev +1
  56. MattJ +1
  57. stpeter Kev: I was going to double-check all threads related to 260 yesterday, but I wasn't feeling well so didn't get to it
  58. Tobias has joined
  59. Kev Something going around? I've been rough for a week.
  60. MattJ Something going around, my brother's ill
  61. Kev My understanding was that 260 feedback had now been addressed.
  62. linuxwolf scary that it's jumping continents
  63. Kev And the same for 261.
  64. Kev linuxwolf: I was in the US when I caught it.
  65. linuxwolf that's my understanding, too
  66. Kev Now in the UK.
  67. stpeter Kev is the transmission mechanism!
  68. linuxwolf Kev: oh, well, congrats on being a Typhoid Mary (-:
  69. linuxwolf patient zero
  70. Kev Thanks.
  71. Kev linuxwolf: Do you have a vote on 261?
  72. linuxwolf +1
  73. linuxwolf sorry
  74. Kev 4) 249 1.2?
  75. Kev +1
  76. MattJ +1
  77. linuxwolf +1 also
  78. Kev 5) http://www.xmpp.org/extensions/inbox/account-management.html - accept as XEP?
  79. Kev This doesn't look right to me.
  80. MattJ I only managed to get halfway in my review
  81. MattJ (I underestimated how long it was)
  82. Kev I don't believe these things are really stream features, for a start.
  83. Kev I don't think password setting is done the right way (we're not trying to protect against the server knowing our password for the server)
  84. remko has joined
  85. Kev Various other things are quite funky.
  86. linuxwolf /nod
  87. Kev I'm also quite interested in the suggestion that server may either store passworddata in more or less secure forms than plaintext.
  88. stpeter Kev: yeah, if you're worried about an attack from the server then run your own server
  89. Kev I've taken advice on what less secure storage than plaintext could be, and have had both Twitter and billboards in the West End suggested.
  90. Kev :)
  91. stpeter BTW Jehan wanted to be here but the timezone difference was too much
  92. linuxwolf (-:
  93. Kev stpeter: I saw that.
  94. Kev So, despite my opinion that we should accept everything that isn't obviously wrong, this seems sufficiently wrong in sufficiently many ways to me to want to reject it.
  95. Kev I can be talked down on this if my fellow Council members feel I'm wrong.
  96. MattJ I'm prepared to accept it
  97. MattJ But I'll follow up on list after I finish reviewing
  98. linuxwolf I'm prepared to accept it, but not to talk someone down from their position
  99. MattJ Heh
  100. Kev MattJ: Because you don't believe using non-stream-features as stream-features is the wrong approach etc., or because you think it's the wrong approach but not strongly enough to block it?
  101. Kev I read through this (and it took a while) and my opinion is roughly thus:
  102. MattJ Kev, because I see it has potential, and isn't obviously terrible to the point of not accepting (though I already have a list of feedback)
  103. MattJ Experimental is not final, we're not forcing people to implement it
  104. MattJ and we're not saying it's perfect
  105. Kev 77 could do with updating. This tries to update 77. Yay. It does it in several wrong ways and the protoXEP needs a lot of work. If such work were put in fairly early, I don't really mind it happening on the vine. If this were to go on the vine for 12 months and get implemented in that time without attention from the author, I think it's harmful.
  106. stpeter right, I see Experimental as "this is reasonable a starting point for discussion"
  107. MattJ I agree with both your statements
  108. stpeter heh
  109. MattJ I suspect it won't get implemented anywhere though without a push
  110. linuxwolf I see Kev's point, but there is a reason a big red warning is at the top of experimental XEPs
  111. MattJ Indeed
  112. Kev linuxwolf: Right. Although the quality of Experimentals is *generally* fairly high.
  113. linuxwolf *generally* (-:
  114. Kev Right.
  115. linuxwolf I'm not disagreeing that this has problems
  116. MattJ Me neither
  117. linuxwolf IMO, I think doing something non-XMPP would be an overall better approach, but that's me
  118. MattJ If it makes you happier, we can push it off for a week
  119. Kev Right - it's just a question of whether they're severe enough to need fixing before even going to Experimental.
  120. MattJ We can give our feedback, and see how we feel after it's been hashed out on-list
  121. linuxwolf /nod
  122. Kev I'm generally in favour of accepting just about anything non-broken as Experimental.
  123. Kev Ok, this seems like a reasonable approach, thanks.
  124. linuxwolf I haven't decided yet if account-management is broken, either
  125. linuxwolf but that's me
  126. Kev So we'll start list feedback, and hold off accepting until feedback's underway, but not actively reject it?
  127. MattJ Ah yes
  128. MattJ Yes
  129. linuxwolf agreed
  130. Kev Ok, WFM, thanks.
  131. Kev 6) Replace Fritzy
  132. linuxwolf well
  133. linuxwolf there's only about 4-5 weeks left in the term
  134. Kev We have the ability to replace our missing member. Do we want to, when we have days left of the term?
  135. MattJ I see no need
  136. linuxwolf neither do I
  137. Kev I'd rather have a full Council, but simply getting someone started would probably take the rest of the term.
  138. dwd has joined
  139. Kev I've not checked Bylaws recently. From memory it's at Council's discretion whether to replace a shortfall, but if someone calls us out on list for being bad people we can check and do what's appropriate.
  140. dwd It's at the discretion of COuncil.
  141. stpeter it is
  142. Kev Jolly good.
  143. Kev 7) Date of next meeting.
  144. Kev SBTSBC?
  145. MattJ +1
  146. linuxwolf wfm
  147. Kev Lovely.
  148. Kev 8) AOB?
  149. MattJ None here I think
  150. linuxwolf nay
  151. MattJ Oh
  152. dwd "The Council shall at its discretion determine whether to fill any vacancies on the Council caused by resignation or removal of an existing Council member."
  153. stpeter needs to finalize the XEP-0045 fixes
  154. MattJ MUC...
  155. MattJ stpeter, great minds :)
  156. stpeter FND!
  157. Kev Incidentally, I'm implementing MUC in Swift at the moment.
  158. MattJ Great
  159. dwd stpeter, "Seldom", as I recall the expression.
  160. linuxwolf it's always fun (-:
  161. stpeter Kev: re-implementing?
  162. MattJ A long long time ago, Dave and I had a wishlist thread on MUC iirc
  163. Kev stpeter: Implementing. It only has join/message functionality atm.
  164. stpeter ah
  165. dwd MattJ, Me Dave? Did we?
  166. Kev I want to be able to kick people :D
  167. stpeter Kev: I'm in no great hurry if you'd like me to wait for more implementation feedback
  168. MattJ I'm still keen on some of those things, but I might dig it up and see what /really/ needs to go into 45 and what could be a new XEP
  169. stpeter MattJ: right
  170. Kev I'm assuming we're not pushing to Final quite yet, anyway.
  171. stpeter MattJ: I have some things, too, but they're add-ons
  172. stpeter Kev: no
  173. Kev So even if I have feedback after the current push, no foul.
  174. Kev Anything we need to discuss about MUC?
  175. stpeter BTW it seems that we never published http://xmpp.org/extensions/inbox/mucstatus.html ?
  176. dwd I'm thinking, FWIW, that various bits like the voice requests do need hiving off into other XEPs.
  177. Kev I know I've not reviewed the diffs yet.
  178. stpeter ahwe did
  179. stpeter n/m
  180. stpeter creates the http redirect
  181. Kev Ok, so AOAOB?
  182. MattJ None here
  183. linuxwolf naynay
  184. Kev stpeter?
  185. Kev Anyone else?
  186. stpeter nothing here
  187. Kev Fab.
  188. Kev Thanks all.
  189. linuxwolf grazie
  190. Kev gangs beh tavel
  191. dbanes has left
  192. stpeter thanks, guys
  193. Kev I vaguely remember promising members@ that I'd put together a summary of the term, with a list of times people managed to be late or fail to turn up for meetings.
  194. Kev That sounds like fun :/
  195. stpeter :)
  196. linuxwolf hehe
  197. remko has left
  198. stpeter sends an email about i18n insanity
  199. ralphm has joined
  200. ralphm sorry guys
  201. Kev Too busy chatting on Facebook? :)
  202. stpeter heh
  203. stpeter ralphm: feel free to vote on agenda items while you're here
  204. stpeter http://xmpp.org:5290/muc_log/muc.xmpp.org/council/110921/
  205. ralphm Kev: hehe. No, releasing several sites to production
  206. stpeter ralphm: shall we wait for you to vote on-list about 260, 261, and 249?
  207. stpeter no big hurry, and I need to check a few things about 260 anyway
  208. ralphm +1 on both really
  209. Kev There are three :)
  210. ralphm oh, hehe
  211. ralphm oh, yeah, that change to 249 is great too
  212. ralphm +1
  213. ralphm and +1 on making that protoxep experimenal
  214. ralphm +t
  215. stpeter ralphm: ok thanks
  216. stpeter your reviews are appreciated :)
  217. ralphm fwiw, I think replacing fritzy at this point is useless
  218. ralphm about muc status conditions
  219. ralphm could we not model it more like we did with stanza errors, just adding a child to <status/>?
  220. ralphm I've also thought about something similar to the type attribute we have in stanza errors, to denote the different types of conditions
  221. ralphm (as a 'replacement' of the numbering scheme of the current status codes)
  222. ralphm stpeter: what do you think?
  223. stpeter ralphm: did you look at http://xmpp.org/extensions/xep-0306.html ?
  224. ralphm yes, I tried to implement it
  225. ralphm and found it a bit cumbersome
  226. stpeter aha
  227. ralphm if we are going to have a migration path, it would be nice if the different status codes and conditions are more closely related in the protocol. As with stanza errors, we can eventually lose the 'code' attribute
  228. stpeter I'm all in favor of simpler
  229. stpeter right, I see
  230. ralphm I think modelling it exactly like with stanza errors would work great, here
  231. ralphm I'm not sure if we actually need a new namespace in that setting
  232. ralphm but that's a detail imo
  233. stpeter ok
  234. stpeter I think the concern was duplication when you have multiple <status/> elements
  235. linuxwolf /nod
  236. dwd Well, you can't, in practical terms.
  237. ralphm so, more like: <presence from='coven@chat.shakespeare.lit/thirdwitch' id='n13mt3l' to='hag66@shakespeare.lit/pda'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='member' role='participant'/> <status code='100' type='informational'> <status code='110'/> <conditions xmlns='urn:xmpp:muc:conditions:0'> <realjid-public/> <self-presence/> </conditions> </x> </presence>
  238. stpeter dwd: you can't what?
  239. ralphm oops
  240. dwd stpeter, Have multiple status codes.
  241. dwd stpeter, There's enough clients out there that can't handle more than one. And those that can't aren't consistent with which ones they ignore.
  242. ralphm <presence from='coven@chat.shakespeare.lit/thirdwitch' id='n13mt3l' to='hag66@shakespeare.lit/pda'> <x xmlns='http://jabber.org/protocol/muc#user'> <item affiliation='member' role='participant'/> <status code='100' type='informational'> <realjid-public/> </status> <status code='110' type='informational'> <self-presence/> </status> </x> </presence>
  243. stpeter dwd: right, so I've heard
  244. ralphm I'm not sure about the @type, yet.
  245. stpeter needs to pay attention to the discussion in xsf@muc.xmpp.org (server certification) but will dip in here once in a while
  246. ralphm going to commute now
  247. ralphm I'll check back in a bit
  248. linuxwolf goes back to work
  249. ralphm has left
  250. Kev has joined
  251. dwd has joined
  252. stpeter has joined
  253. Kooda has joined
  254. Neustradamus has joined
  255. MattJ has joined
  256. drасо has joined
  257. linuxwolf has joined
  258. linuxwolf has left
  259. linuxwolf has joined
  260. linuxwolf has left
  261. linuxwolf has joined
  262. Neustradamus has joined
  263. Neustradamus has joined
  264. linuxwolf has left
  265. linuxwolf has joined
  266. linuxwolf has left