XMPP Council - 2017-12-06

  1. pep. has joined

  2. daniel has left

  3. daniel has joined

  4. daniel has left

  5. daniel has joined

  6. Zash has joined

  7. Tobias has joined

  8. Tobias has joined

  9. ralphm has left

  10. ralphm has joined

  11. Zash has left

  12. SamWhited has joined

  13. jere has left

  14. daniel has left

  15. daniel has joined

  16. SamWhited has left

  17. jcbrand has joined

  18. Zash has joined

  19. ralphm has left

  20. Kev has joined

  21. ralphm has left

  22. daniel has left

  23. daniel has left

  24. daniel has left

  25. daniel has left

  26. genofire has left

  27. daniel has left

  28. daniel has left

  29. daniel has left

  30. Tobias has left

  31. daniel has left

  32. jere has joined

  33. daniel has left

  34. daniel has left

  35. daniel has left

  36. genofire has joined

  37. daniel has left

  38. vanitasvitae has left

  39. vanitasvitae has joined

  40. ralphm has joined

  41. daniel has left

  42. ralphm has left

  43. daniel has left

  44. ralphm has left

  45. ralphm has left

  46. daniel has left

  47. ralphm has left

  48. ralphm has joined

  49. ralphm has left

  50. ralphm has joined

  51. ralphm has left

  52. daniel has left

  53. ralphm has joined

  54. ralphm has left

  55. ralphm has joined

  56. ralphm has left

  57. vanitasvitae has joined

  58. ralphm has joined

  59. ralphm has left

  60. ralphm has joined

  61. ralphm has left

  62. Ge0rG has left

  63. ralphm has joined

  64. Ge0rG has joined

  65. Ge0rG has left

  66. ralphm has left

  67. ralphm has joined

  68. Ge0rG has joined

  69. ralphm has left

  70. ralphm has joined

  71. ralphm has left

  72. ralphm has joined

  73. daniel has left

  74. vanitasvitae has joined

  75. ralphm has left

  76. vanitasvitae has left

  77. vanitasvitae has joined

  78. ralphm has left

  79. vanitasvitae has left

  80. ralphm has left

  81. ralphm has left

  82. vanitasvitae has joined

  83. ralphm has left

  84. ralphm has left

  85. genofire has left

  86. ralphm has left

  87. daniel has left

  88. ralphm has left

  89. ralphm has left

  90. moparisthebest has joined

  91. daniel has left

  92. ralphm has left

  93. ralphm has joined

  94. daniel has left

  95. ralphm has joined

  96. Zash has left

  97. Zash has left

  98. Zash has left

  99. Zash has left

  100. genofire has left

  101. Zash has left

  102. Zash has left

  103. Zash has left

  104. ralphm has joined

  105. daniel has left

  106. ralphm has left

  107. Zash has left

  108. genofire has left

  109. vanitasvitae has left

  110. vanitasvitae has joined

  111. Lance has joined

  112. Kev

    'tis time, 'tis time.

  113. jonasw

    the harpie cries

  114. Syndace has left

  115. Kev

    1) Bread products!

  116. jonasw

    I gotta leave at 1630Z, so I won’t be able to properly take minutes

  117. Kev

    jonasw: I can do minutes, it's ok ta.

  118. Kev

    Dave sends apologies. daniel, Ge0rG, SamWhited - you here?

  119. jonasw

    two out of those have spoken in other MUCs just a few minutes ago :)

  120. Ge0rG here

  121. SamWhited

    I'm here

  122. daniel


  123. Kev

    2) 186 LC

  124. daniel has left

  125. Kev

    I'm +1

  126. Kev

    (This is a re-issue because the last one expired without Council voting)

  127. SamWhited

    What are we voting on?

  128. SamWhited

    Oops, too slow

  129. SamWhited

    I don't think we have to vote on this; editor will just reissue the LC

  130. SamWhited

    (but +1 FWIW)

  131. Ge0rG

    +1 for LC

  132. Kev

    I think that's right, as it happens.

  133. daniel


  134. jonasw

    editor will take notice that this is the councils opinion and re-issue the LC sometime tomorrow, maybe tonight (or somebody besides me does it)

  135. Kev

    And same for

  136. Kev

    3) 352 LC

  137. Kev

    jonasw: More than Council's opinion, it's what xep1 says :)

  138. Kev

    4) Deprecating 84

  139. jonasw

    Kev, we could also simply move it back to experimental, couldn’t we?

  140. Kev

    No, xep1 says that if there's a vote that wasn't completed, the Editors will re-issue an LC.

  141. jonasw

    ah okay

  142. Kev

    So, deprecating '84, which I think was Link Mauve's request.

  143. Kev

    (That's pubsub avatars, for anyone who needs to know)

  144. daniel

    has there been any argument on why?

  145. Ge0rG

    I haven't yet compared pubsub avatars to vcard avatars, so I'm impartial.

  146. jonasw

    IIRC, vcard works today

  147. Kev

    It just appeared on the Council board without an argument why.

  148. jonasw

    IIRC, the argument was "vcard works today"

  149. Kev

    Link Mauve can probably say why, though.

  150. Ge0rG

    jonasw: weren't there special cases where vcard doesn't work in MUCs?

  151. Kev

    Ge0rG: none that PEP does work in, I think.

  152. SamWhited

    I'd prefer to deprecate 0153. 0084 has its problems, but seems like a better more future-compatible platform, but I don't care as long as we move towards a single way to do avatars.

  153. Ge0rG

    0153 is Historical already.

  154. Kev

    Indeed, deprecating 153 is likely not the right thing to do.

  155. SamWhited

    I disagree; it appears right now that we're recommending two different ways to do avatars, which seems to be the main problem here to me.

  156. Kev

    I'm not convinced that we should be deprecating 84. I'm -1 for the moment, but in the minutes I'll invite an argument why it should happen.

  157. Kev

    No, I mean that a Historical XEP doesn't need deprecating, because of its nature :)

  158. Kev

    (Although we can do so, certainly)

  159. Ge0rG

    SamWhited: which are the two? 84 and 153?

  160. SamWhited

    Ge0rG: Yes

  161. Ge0rG

    SamWhited: and where are we recommending 153?

  162. Ge0rG

    (and for what reasons)

  163. daniel

    and the other two :-)

  164. SamWhited

    It's got a big green block of text that says "This is draft" at the top

  165. Kev

    Ge0rG: We're not, but it's the de facto standard.

  166. jonasw

    (which I learnt the hard way which I find annoying)

  167. Kev

    Anyway, with one -1 in place, let's gather votes for this and move on.

  168. daniel


  169. Ge0rG

    387 goes with 84, so it might be not smart to deprecate it.

  170. SamWhited

    Sounds good; I'll discuss on list if necessary.

  171. Kev

    SamWhited: "sounds good" is voting which way?

  172. Kev

    Same question for contestant number Ge0rG.

  173. Ge0rG

    -1 for now, until reasons for deprecation are provided

  174. SamWhited

    Kev: "let's move on" sounds good, I mean. On list.

  175. Kev


  176. Kev

    5) Reverting 48 to 49

  177. Kev

    That's reverting bookmarks to iq:private instead of private pubsub.

  178. daniel

    is there an argument on why?

  179. SamWhited

    I'm not sure why this one was brought up either; is there a problem with them as they are today?

  180. Kev

    This isn't a voting point, because there's no vote to be made.

  181. jonasw

    I did

  182. Kev

    But let's discuss.

  183. jonasw

    the argument is that the change from private XML to pubsub happened in draft state, which is a major breakage of the protocol. many deployments are still on Private XML

  184. daniel has left

  185. jonasw

    which is indiscoverable to new developers

  186. Kev

    jonasw: So it's a point of process?

  187. jonasw

    no, also a point of usability by developers

  188. Ge0rG

    I think deployments are on private XML because some major XMPP server implementations lack persistent PEP.

  189. Kev

    I think 'indiscoverable' is pushing it a bit, when the XEP says this explicitly.

  190. jonasw

    so the point is, as a new developer, you see the XEP, you think "neat, PEP", implement it, and find no bookmarks

  191. Kev

    I think private pubsub is a better mechanism to be storing these data than iq:private, so reverting to say it should be iq:private seems wrong, and the XEP already says that existing implementations do iq:private, so implementors know that they'll want to consider at least read access to it.

  192. jonasw

    I agree that it is a better mechanism.

  193. Kev

    jonasw: Except you wouldn't, because the XEP notes that people used to do iq:private.

  194. jonasw

    "used to do" implies that it isn’t that way anymore

  195. jonasw

    and also, only read access isn’t sufficient, because there are enough clients and servers out there which still can only do private XML

  196. Ge0rG

    So maybe we should extend 48 with a compat behavior spec?

  197. Ge0rG

    0387 does not enforce the type of backend storage.

  198. Kev

    I think the note that we used to recommend iq:private is sufficient, but we could add an extra sentence to say "and it's still widely used" if it'll make people feel better, and then new implementors are forewarned.

  199. Ge0rG

    We might add both 49 and 223 to 0387 as well

  200. Kev

    But I don't think that saying "you SHOULD use iq:private" instead of the better private pubsub mechanism is right.

  201. SamWhited


  202. Ge0rG

    Kev: in theory, you are right. In practice, implementations of private pubsub will learn about the lack of persistence, the hard way.

  203. jonasw

    Kev, I agree with your second part, I disagree with the precedent this change sets

  204. Ge0rG

    ...of private pubsub bookmarks

  205. daniel

    Ge0rG, more importantly the implementation you are talking about doesn't support making the node private

  206. Kev

    Ge0rG: I am not inclined to avoid doing the Right Thing here because one (popular!) server implementation doesn't have a feature.

  207. daniel

    which arguably is the bigger issue

  208. Kev

    Else we end up with all our XEPs saying "But instead you need to do X for Prosody".

  209. Ge0rG

    Kev: apparently we can not force implementations to do anything.

  210. daniel has left

  211. jonasw

    I gotta run, see you later

  212. Kev

    I don't think I've successfully forced anyone to do anything in my life :)

  213. Kev

    Thanks Jonas.

  214. Ge0rG

    I'm not arguing in favor of "you SHOULD use iq:private", merely pointing out that usage of iq:private is self-reinforcing.

  215. Kev

    It is, certainly.

  216. Kev

    But not all deployments are based on Prosody.

  217. Kev

    I suggest that someone proposes an additional line as I did above to 48, and we vote on that once it's done.

  218. Kev

    I can do that.

  219. Ge0rG

    Kev: please do.

  220. Kev

    Moving on

  221. Kev

    6) Date of next.

  222. Kev

    I can't do next week, and I possibly can't do anything else until the new year, at this point, but will vote on list.

  223. Kev

    Does everyone else want to SBTSBC?

  224. SamWhited


  225. daniel has left

  226. Ge0rG

    +1W WFM

  227. Kev


  228. daniel

    next week works for me

  229. Kev

    7) AOB

  230. SamWhited

    I would like to ask that we vote on XEP-0286: Mobile Considerations for LTE Networks (or pull it in next week)

  231. SamWhited

    It's been sitting in the proposed agendums for a few weeks

  232. Kev

    I only grabbed for the Agenda today what Dave'd put on it, so I've not reviewed (and assume no-one else has) 286 and trying to vote on it now would be unhelpful.

  233. Kev

    So I propose I drag it to the Agenda for next week, and we look at it then.

  234. SamWhited

    Works for me; thanks.

  235. Kev

    Anything else?

  236. Kev

    Looks like not. Thanks all.

  237. Kev gangs the bavel

  238. SamWhited

    Thanks Kev

  239. Ge0rG

    Thanks Kev

  240. SamWhited

    Would anyone complain if I removed the "For Editors" column and asked people to move them straight to the editors board's TODO column? That way editors can get alerts

  241. SamWhited

    Everyone *should* have access to the editors board if you're already on the council one

  242. Kev

    I think it only affects Dave and the Editors.

  243. Kev

    Maybe check with him, but it seems sensible to me.

  244. SamWhited

    *nods* going to do it and if he doesn't like it or doesn't have access he can always unarchive it next week

  245. Ge0rG

    "Dave and the Editors" sounds like an awesome name for a Punk band.

  246. Lance has left

  247. daniel has left

  248. daniel has left

  249. moparisthebest

    sounds boring

  250. jere has joined

  251. moparisthebest

    "and then he consulted XEP-0001 for the proper procedure, dum dum dum"

  252. moparisthebest

    it sounds like blues in my brain

  253. Kev

    https://github.com/xsf/xeps/pull/554 - 48 patch.

  254. Ge0rG

    Kev: 👍

  255. jcbrand has left

  256. ralphm has left

  257. daniel has left

  258. daniel has left

  259. Lance has joined

  260. daniel has left

  261. daniel has left

  262. genofire has left

  263. Tobias has joined

  264. genofire has joined

  265. daniel has left

  266. Lance has left

  267. daniel has left

  268. ralphm has joined

  269. genofire has left

  270. jonasw has left

  271. daniel has left

  272. ralphm has joined

  273. ralphm has joined

  274. daniel has left

  275. daniel has left

  276. ralphm has left

  277. ralphm has joined

  278. pep. has left

  279. ralphm has joined

  280. ralphm has left

  281. ralphm has joined

  282. ralphm has left

  283. ralphm has joined

  284. ralphm has left

  285. ralphm has joined

  286. daniel has joined

  287. ralphm has left

  288. ralphm has joined

  289. Tobias has joined

  290. Zash has left

  291. moparisthebest has joined

  292. daniel has left

  293. Zash has left

  294. Zash has joined

  295. daniel has left

  296. jere has left

  297. jere has joined

  298. Syndace has joined

  299. Syndace has left

  300. Syndace has joined

  301. ralphm has left

  302. SamWhited has left

  303. pep. has left

  304. ralphm has left

  305. genofire has joined

  306. ralphm has joined