XMPP Council - 2011-09-21

  1. stpeter

    greetings, and 30-minute warning :)

  2. Kev


  3. linuxwolf


  4. stpeter

    and my dent didn't get posted at identi.ca -- perhaps their xmpp interface is not happy

  5. stpeter

    tweeted it instead :P

  6. Neustradamus

    stpeter: http://identi.ca/notice/84187967

  7. linuxwolf

    yeah, I got nuttin'

  8. MattJ

    Kev's -30s meeting

  9. Neustradamus

    stpeter: oups: http://identi.ca/conversation/84183552#notice-84188156

  10. MattJ

    Interesting, what Gajim says the time is doesn't match my system clock...

  11. stpeter

    Neustradamus: perhaps I need to use their website instead of the xmpp interface...

  12. Kev

    It's currently 2 minutes to the meeting in the Chair's time.

  13. linuxwolf

    MattJ: is it off by minutes, or hours? (-:

  14. MattJ


  15. MattJ

    Maybe it's drift from suspend/resume

  16. MattJ

    which one is correct I'm not sure :)

  17. linuxwolf


  18. MattJ

    Ok, Gajim matches `date`, so it's just my taskbar that's wrong

  19. Neustradamus

    stpeter: yes

  20. dbanes

    Hi all, random visit while having a coffee...

  21. Kev

    Right, time for the meeting.

  22. Kev

    1) Roll call.

  23. Kev

    I'm here.

  24. stpeter

    hi dbanes

  25. linuxwolf


  26. dbanes

    hi @stpeter [on mute now]

  27. Kev

    MattJ: Present?

  28. MattJ


  29. MattJ


  30. Kev


  31. Kev

    No sign of Ralph, and Fritzy Is No More.

  32. MattJ


  33. Kev

    Or, well, sign of Ralph but he's DND.

  34. stpeter

    Ralph is dnd with some strange status messages

  35. linuxwolf

    Ralph is doing development for some legacy social media site, apparently (-:

  36. stpeter

    heh yeah

  37. Kev

    3) Move -260 to Draft?

  38. MattJ

    It could be XMPP related :)

  39. MattJ


  40. Kev

    2, rather.

  41. linuxwolf


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

  43. Kev

    I'm +1 anyway

  44. Kev

    3) 261?

  45. Kev


  46. MattJ


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

  48. Kev

    Something going around? I've been rough for a week.

  49. MattJ

    Something going around, my brother's ill

  50. Kev

    My understanding was that 260 feedback had now been addressed.

  51. linuxwolf

    scary that it's jumping continents

  52. Kev

    And the same for 261.

  53. Kev

    linuxwolf: I was in the US when I caught it.

  54. linuxwolf

    that's my understanding, too

  55. Kev

    Now in the UK.

  56. stpeter

    Kev is the transmission mechanism!

  57. linuxwolf

    Kev: oh, well, congrats on being a Typhoid Mary (-:

  58. linuxwolf

    patient zero

  59. Kev


  60. Kev

    linuxwolf: Do you have a vote on 261?

  61. linuxwolf


  62. linuxwolf


  63. Kev

    4) 249 1.2?

  64. Kev


  65. MattJ


  66. linuxwolf

    +1 also

  67. Kev

    5) http://www.xmpp.org/extensions/inbox/account-management.html - accept as XEP?

  68. Kev

    This doesn't look right to me.

  69. MattJ

    I only managed to get halfway in my review

  70. MattJ

    (I underestimated how long it was)

  71. Kev

    I don't believe these things are really stream features, for a start.

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

  73. Kev

    Various other things are quite funky.

  74. linuxwolf


  75. Kev

    I'm also quite interested in the suggestion that server may either store passworddata in more or less secure forms than plaintext.

  76. stpeter

    Kev: yeah, if you're worried about an attack from the server then run your own server

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

  78. Kev


  79. stpeter

    BTW Jehan wanted to be here but the timezone difference was too much

  80. linuxwolf


  81. Kev

    stpeter: I saw that.

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

  83. Kev

    I can be talked down on this if my fellow Council members feel I'm wrong.

  84. MattJ

    I'm prepared to accept it

  85. MattJ

    But I'll follow up on list after I finish reviewing

  86. linuxwolf

    I'm prepared to accept it, but not to talk someone down from their position

  87. MattJ


  88. 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?

  89. Kev

    I read through this (and it took a while) and my opinion is roughly thus:

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

  91. MattJ

    Experimental is not final, we're not forcing people to implement it

  92. MattJ

    and we're not saying it's perfect

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

  94. stpeter

    right, I see Experimental as "this is reasonable a starting point for discussion"

  95. MattJ

    I agree with both your statements

  96. stpeter


  97. MattJ

    I suspect it won't get implemented anywhere though without a push

  98. linuxwolf

    I see Kev's point, but there is a reason a big red warning is at the top of experimental XEPs

  99. MattJ


  100. Kev

    linuxwolf: Right. Although the quality of Experimentals is *generally* fairly high.

  101. linuxwolf

    *generally* (-:

  102. Kev


  103. linuxwolf

    I'm not disagreeing that this has problems

  104. MattJ

    Me neither

  105. linuxwolf

    IMO, I think doing something non-XMPP would be an overall better approach, but that's me

  106. MattJ

    If it makes you happier, we can push it off for a week

  107. Kev

    Right - it's just a question of whether they're severe enough to need fixing before even going to Experimental.

  108. MattJ

    We can give our feedback, and see how we feel after it's been hashed out on-list

  109. linuxwolf


  110. Kev

    I'm generally in favour of accepting just about anything non-broken as Experimental.

  111. Kev

    Ok, this seems like a reasonable approach, thanks.

  112. linuxwolf

    I haven't decided yet if account-management is broken, either

  113. linuxwolf

    but that's me

  114. Kev

    So we'll start list feedback, and hold off accepting until feedback's underway, but not actively reject it?

  115. MattJ

    Ah yes

  116. MattJ


  117. linuxwolf


  118. Kev

    Ok, WFM, thanks.

  119. Kev

    6) Replace Fritzy

  120. linuxwolf


  121. linuxwolf

    there's only about 4-5 weeks left in the term

  122. Kev

    We have the ability to replace our missing member. Do we want to, when we have days left of the term?

  123. MattJ

    I see no need

  124. linuxwolf

    neither do I

  125. Kev

    I'd rather have a full Council, but simply getting someone started would probably take the rest of the term.

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

  127. dwd

    It's at the discretion of COuncil.

  128. stpeter

    it is

  129. Kev

    Jolly good.

  130. Kev

    7) Date of next meeting.

  131. Kev


  132. MattJ


  133. linuxwolf


  134. Kev


  135. Kev

    8) AOB?

  136. MattJ

    None here I think

  137. linuxwolf


  138. MattJ


  139. 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."

  140. stpeter needs to finalize the XEP-0045 fixes

  141. MattJ


  142. MattJ

    stpeter, great minds :)

  143. stpeter


  144. Kev

    Incidentally, I'm implementing MUC in Swift at the moment.

  145. MattJ


  146. dwd

    stpeter, "Seldom", as I recall the expression.

  147. linuxwolf

    it's always fun (-:

  148. stpeter

    Kev: re-implementing?

  149. MattJ

    A long long time ago, Dave and I had a wishlist thread on MUC iirc

  150. Kev

    stpeter: Implementing. It only has join/message functionality atm.

  151. stpeter


  152. dwd

    MattJ, Me Dave? Did we?

  153. Kev

    I want to be able to kick people :D

  154. stpeter

    Kev: I'm in no great hurry if you'd like me to wait for more implementation feedback

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

  156. stpeter

    MattJ: right

  157. Kev

    I'm assuming we're not pushing to Final quite yet, anyway.

  158. stpeter

    MattJ: I have some things, too, but they're add-ons

  159. stpeter

    Kev: no

  160. Kev

    So even if I have feedback after the current push, no foul.

  161. Kev

    Anything we need to discuss about MUC?

  162. stpeter

    BTW it seems that we never published http://xmpp.org/extensions/inbox/mucstatus.html ?

  163. dwd

    I'm thinking, FWIW, that various bits like the voice requests do need hiving off into other XEPs.

  164. Kev

    I know I've not reviewed the diffs yet.

  165. stpeter

    ahwe did

  166. stpeter


  167. stpeter creates the http redirect

  168. Kev

    Ok, so AOAOB?

  169. MattJ

    None here

  170. linuxwolf


  171. Kev


  172. Kev

    Anyone else?

  173. stpeter

    nothing here

  174. Kev


  175. Kev

    Thanks all.

  176. linuxwolf


  177. Kev gangs beh tavel

  178. stpeter

    thanks, guys

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

  180. Kev

    That sounds like fun :/

  181. stpeter


  182. linuxwolf


  183. stpeter sends an email about i18n insanity

  184. ralphm

    sorry guys

  185. Kev

    Too busy chatting on Facebook? :)

  186. stpeter


  187. stpeter

    ralphm: feel free to vote on agenda items while you're here

  188. stpeter


  189. ralphm

    Kev: hehe. No, releasing several sites to production

  190. stpeter

    ralphm: shall we wait for you to vote on-list about 260, 261, and 249?

  191. stpeter

    no big hurry, and I need to check a few things about 260 anyway

  192. ralphm

    +1 on both really

  193. Kev

    There are three :)

  194. ralphm

    oh, hehe

  195. ralphm

    oh, yeah, that change to 249 is great too

  196. ralphm


  197. ralphm

    and +1 on making that protoxep experimenal

  198. ralphm


  199. stpeter

    ralphm: ok thanks

  200. stpeter

    your reviews are appreciated :)

  201. ralphm

    fwiw, I think replacing fritzy at this point is useless

  202. ralphm

    about muc status conditions

  203. ralphm

    could we not model it more like we did with stanza errors, just adding a child to <status/>?

  204. ralphm

    I've also thought about something similar to the type attribute we have in stanza errors, to denote the different types of conditions

  205. ralphm

    (as a 'replacement' of the numbering scheme of the current status codes)

  206. ralphm

    stpeter: what do you think?

  207. stpeter

    ralphm: did you look at http://xmpp.org/extensions/xep-0306.html ?

  208. ralphm

    yes, I tried to implement it

  209. ralphm

    and found it a bit cumbersome

  210. stpeter


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

  212. stpeter

    I'm all in favor of simpler

  213. stpeter

    right, I see

  214. ralphm

    I think modelling it exactly like with stanza errors would work great, here

  215. ralphm

    I'm not sure if we actually need a new namespace in that setting

  216. ralphm

    but that's a detail imo

  217. stpeter


  218. stpeter

    I think the concern was duplication when you have multiple <status/> elements

  219. linuxwolf


  220. dwd

    Well, you can't, in practical terms.

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

  222. stpeter

    dwd: you can't what?

  223. ralphm


  224. dwd

    stpeter, Have multiple status codes.

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

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

  227. stpeter

    dwd: right, so I've heard

  228. ralphm

    I'm not sure about the @type, yet.

  229. stpeter needs to pay attention to the discussion in xsf@muc.xmpp.org (server certification) but will dip in here once in a while

  230. ralphm

    going to commute now

  231. ralphm

    I'll check back in a bit

  232. linuxwolf goes back to work