XMPP Council - 2019-01-09


  1. pep. has left
  2. vanitasvitae has joined
  3. oli has left
  4. oli has left
  5. oli has left
  6. pep. has joined
  7. oli has left
  8. oli has left
  9. oli has joined
  10. oli has left
  11. oli has joined
  12. oli has left
  13. oli has joined
  14. Zash has joined
  15. oli has left
  16. Tobias has joined
  17. Link Mauve has left
  18. Tobias has left
  19. Tobias has joined
  20. labdsf has left
  21. labdsf has joined
  22. ivucica has left
  23. oli has joined
  24. Zash has left
  25. ralphm has left
  26. pep. has joined
  27. Zash has left
  28. Tokodomo has joined
  29. Zash has left
  30. Tokodomo has left
  31. Tokodomo has joined
  32. Tokodomo has left
  33. Tokodomo has joined
  34. pep. has left
  35. Tokodomo has left
  36. Tokodomo has joined
  37. Tokodomo has left
  38. Tokodomo has joined
  39. Tokodomo has left
  40. Tokodomo has joined
  41. Tokodomo has left
  42. dwd has joined
  43. Link Mauve has joined
  44. Tokodomo has joined
  45. Tokodomo has left
  46. Tokodomo has joined
  47. Tokodomo has left
  48. Zash has left
  49. oli has joined
  50. Link Mauve has left
  51. SouL has left
  52. Link Mauve has joined
  53. Zash has left
  54. vanitasvitae has left
  55. oli has joined
  56. Zash has left
  57. oli has left
  58. oli has joined
  59. Tokodomo has joined
  60. Tokodomo has left
  61. Link Mauve has left
  62. Link Mauve has joined
  63. pep. has joined
  64. Tokodomo has joined
  65. Tokodomo has left
  66. Holger has left
  67. Zash has left
  68. Holger has left
  69. Zash has left
  70. labdsf has left
  71. lnj has joined
  72. labdsf has joined
  73. Holger has left
  74. Holger has left
  75. Zash has left
  76. Ge0rG has joined
  77. Ge0rG Good morning!
  78. Link Mauve Hi.
  79. Link Mauve Did we have an agenda btw?
  80. Ge0rG yeah!
  81. dwd We did, because I got around to it.
  82. Kev Yes, Dave sent it out yesterday.
  83. Ge0rG !praise dwd
  84. dwd I've not got around to my Voting Bot, though.
  85. Link Mauve Oh, just now I see it. :x
  86. Zash has left
  87. jonas’ I still don’t see the agenda
  88. jonas’ where is it?
  89. Kev [Council] Council Agenda 2019-01-09
  90. jonas’ is that a mailing list?
  91. jonas’ separate from standards@?
  92. Link Mauve jonas’, it is council@.
  93. jonas’ I’m not on that list
  94. Link Mauve Oh.
  95. Kev Alex should have added you after the elections.
  96. jonas’ haven’t been added, afaict
  97. Kev If you mail me, I'm probably capable of doing the magic.
  98. jonas’ I have two things which look like they may be email addresses of yours
  99. Kev isode please.
  100. jonas’ okay
  101. jonas’ sent
  102. Kev Received.
  103. jonas’ awsum
  104. Kev 'tis time.
  105. jonas’ let’s just do IM over email!
  106. jonas’ (oh somebody already did ;-))
  107. dwd Oh, it's time for a meeting!
  108. Kev It's not IM over email, it's TODO list over email :)
  109. jonas’ :D
  110. dwd 1) Roll Call
  111. Kev I'm here. I think.
  112. jonas’ is here
  113. jonas’ afaict
  114. Link Mauve is here too.
  115. jonas’ Ge0rG, ?
  116. lnj has left
  117. Ge0rG .o/
  118. jonas’ \o/
  119. dwd I'm here too. Apologies for last week.
  120. dwd 2) Agenda Bashing
  121. jonas’ same, I was caught up in house cleaning and totally forgot about day of week and time of day
  122. dwd Did I forget anything?
  123. Ge0rG LGTM
  124. jonas’ I can’t tell, I haven’t seen the agenda
  125. dwd jonas’, Have you not?
  126. Ge0rG probably we should split 6a (PR #727) into individual LCs for process' sake
  127. jonas’ no, I’m not on council@ as we discussed just now
  128. jonas’ Kev will take care
  129. jonas’ but I’ll just shout in AOB if something is missing or so
  130. dwd Oh. Whoops. I normally cc it to standards as well.
  131. Ge0rG also just bounced the Agenda mail to jonas’, just in case.
  132. dwd My mistake, anyway.
  133. jonas’ thanks
  134. dwd 3) Items for voting: a) Proposed XMPP Extension: Order-By Abstract: This specification allows to change order of items retrieval in a Pubsub or MAM query URL: https://xmpp.org/extensions/inbox/order-by.html
  135. Ge0rG Is that a vote or discussion first?
  136. dwd That's a vote for adoption, I believe.
  137. Ge0rG I tend to -1, because it's a very specific use case, and it defines two hard-coded properties to order by. A clean approach would allow ordering by any field of the items, using some XSLT magic or something.
  138. jonas’ I’m on-list in any case, I want to discuss with goffi a bit, because I’m pretty sure that I’m right about the points I raised ;-)
  139. jonas’ Ge0rG, note, it defines properties which live *outside* the items, determined by the server
  140. jonas’ it could easily be extended to support XPath or anything like that though
  141. Kev I'm not keen on it, but it clears my bar-of-incompetence for Experimental. So +1.
  142. Ge0rG jonas’: yes. But is there any reason not to embed those properties in the items?
  143. dwd Ge0rG, Yeah, this is indeed ordering by metadata external to the item payload.
  144. jonas’ Ge0rG, yes, the server shalt not modify the items
  145. Ge0rG jonas’: what's wrong with the client adding the respective stamps?
  146. jonas’ Ge0rG, goffi doesn’t find that correct (which I disagree with), because it can be "spoofed"
  147. jonas’ see the discussion on-list for that
  148. Ge0rG oh, didn't catch-up on that.
  149. Ge0rG So I'm on-list, with fallback to -1.
  150. jonas’ what’s your rationale for your fallback -1?
  151. Ge0rG At least this needs to be renamed "PubSub MAM retrieval ordered by creation or modification"
  152. Link Mauve I’m on list on that, I haven’t caught up with anything yet.
  153. dwd I did notice this applies to MAM, too, but doesn't disucss it, and presumably has quite an impact on RSM, but doesn't mention that.
  154. Link Mauve (I’ll try to get better soon!)
  155. jonas’ (OT: Subject: Welcome to the "Council" mailing list. Thanks Kev)
  156. jonas’ dwd, it doesn’t have an impact on RSM, it happens before RSM even comes into play.
  157. jonas’ although, the server might have to use different identifiers in RSM to make it work with RSM
  158. dwd jonas’, I think that needs mentioning. Or thinking about.
  159. Kev It does have an interaction with RSM, at least. Whether 'impact' or not is up to linguists :)
  160. jonas’ dwd, I agree
  161. Kev I wouldn't be unhappy to see this have more work on it before it's published, but I couldn't find a reason to veto it using my usual criteria.
  162. lnj has joined
  163. jonas’ afaict, all except Kev are on-list?
  164. Ge0rG jonas’: my rationale is that it's only adressing a very specific use case, and requires changes to multiple other XEPs, like PubSub (for storing metadata). However, I suppose that's not an appropriate reason for rejecting a proto-XEP
  165. jonas’ no, dwd hasn’t said anything yet
  166. dwd Yeah, I'll go with +0.
  167. jonas’ it doesn’t require changes to XEPs
  168. dwd (Though I reserve the right to change that while others are still on-list).
  169. Ge0rG jonas’: it implies changes to their implementation.
  170. jonas’ that’s true
  171. jonas’ but those are two different things
  172. jonas’ (kinda important when one of the affected XEPs is Draft)
  173. dwd OK, moving on.
  174. dwd 4) Outstanding Votes
  175. dwd I don't think we have any, do we? I can't imagine we do anyway.
  176. dwd 5) Next Meeting
  177. Ge0rG I can't remember any, but maybe this is the right time to remind about the Spreadsheet of Doom?
  178. dwd Or something.
  179. dwd Same time next week?
  180. jonas’ wfm
  181. Kev WFM, I think.
  182. dwd I'll assume 2019-01-16 1600Z unless anyone shouts.
  183. Ge0rG will *probably* work for me. If it does not, it will be impacting my availability for the next ~3mo, so we might need to reschedule or to on-list Ge0rG
  184. dwd Ge0rG, Ah... Should we reschedule now?
  185. Ge0rG My employer translocates me into another city for a full-time engagement, and I don't know the specific business hours there yet
  186. Ge0rG I'll hopefully know more by +1W
  187. dwd Ah, OK. Keep us posted; we can rearrange via email if it's a semi-permanent thing.
  188. dwd 6) AOB a) Cleaning up Deferred items. Link's PR #727 seems unresolved - we should decide on a suitable way to handle this.
  189. dwd These two AOBs are basically about cleaning the github issues and PRs out, so it's more obvious what I should put on the agenda.
  190. Kev That's the obsoleting? We vote on the obsoletes don't we?
  191. jonas’ the PR as is cannot be applied, so I (Council Member) propose I (Editor) just close this
  192. Link Mauve So, a) is a process issue.
  193. Ge0rG Kev: IIRC we can't vote to obsolete without an LC, and probably we shouldn't anyway
  194. jonas’ and if we want to have process for that, we need to propose a modification of XEP-0001
  195. Link Mauve We are not allowed (?) to obsolete without a last call first.
  196. Ge0rG So why not just vote on an LC for all of them?
  197. dwd We can't apply #727 as-is, due to a mismatch in the process, so does someone want to take on changing the process, or do we just not care about clearing out old deferred XEPs?
  198. Ge0rG So why not just vote on an LC for each of them?
  199. Link Mauve But I still believe obsolete is the correct status for these three XEPs (and more, but I wanted to start small).
  200. jonas’ they have to pass to draft to allow obsoleetion, Ge0rG
  201. dwd jonas’, There's Proposed->Rejected
  202. jonas’ Rejected ≠ Obsolete, but Rejecting would be an option, too
  203. Kev Sorry, why can't we go from Deprecated to Obsolete? That's what 9.10 says we can do :)
  204. dwd I'd be fine with Rejected, actually. Feels more accurate. But again, process.
  205. jonas’ Kev, they’re deferred, not deprecated
  206. dwd Kev, We can -but these are Deferred, not Deprecated, I thought?
  207. Kev Oh, right.
  208. dwd We have Retracted, but I'd prefer not to use that personally. I'd happily go for allowing Deferred->Rejected though.
  209. jonas’ vote for rejection without asking the community at all?
  210. dwd So, two questions: What do we want the process to be, and who wants to draft the PR to XEP-0001?
  211. Ge0rG issue a "Call for Deprecation"?
  212. jonas’ I can do the PR to XEP-0001
  213. Kev And the third question: Is there a problem with Deferred XEPs staying Deferred?
  214. jonas’ not for me (as Editor)
  215. dwd Kev, Well, yes - if we're happy with the process as-is.
  216. Ge0rG I suggest that we add an arrow from "Proposed" to "Deprecated"
  217. dwd I would note that it's much the same as expired Internet Drafts in the IETF, and those sometimes get "unexpired" years later.
  218. Kev I'm not sure I see a particular problem with something being Deferred for eternity, when it seems to reflect the actual state - abandoned before advancement.
  219. Link Mauve Kev, the main problem I want to solve is that we’ve asked people to read (big red warning) deferred XEPs for quite a while, because our process is way too slow.
  220. Ge0rG Kev: I think that "Deprecated" is a stronger signal not to implement it than "Deferred"
  221. Ge0rG What Link Mauve says!
  222. jonas’ Link Mauve, but then it is more worthwhile to tackle the XEPs which actually have a chance to advance
  223. jonas’ and which should advance
  224. jonas’ and not those which are dead anyways
  225. Kev Link Mauve: Isn't the problem there getting things out of Deferred when they're not really Deferred, rather than getting them out when they are.
  226. Link Mauve jonas’, sure, in the end I’d like to do both.
  227. Ge0rG jonas’: you can't force other people to implement your XEPs
  228. dwd Link Mauve, Right, moving a XEP from Deferred is easy. And I'm not sure how we could make it "faster".
  229. Link Mauve Kev, whynotboth.jpg
  230. jonas’ focus on the other part first, maybe, becauise the Deferred ones which are actually abandoned and should be aren’t the actual issue
  231. dwd Ge0rG, You don't need to, to move to Draft.
  232. jonas’ Ge0rG, you don’t need implementations to move to Draft
  233. Link Mauve Also, I’ve in the past fixed a typo in a deferred XEP which put it back to experimental.
  234. lnj has left
  235. Ge0rG ah well.
  236. Link Mauve I’d like to avoid doing that everytime there is a typo.
  237. jonas’ Link Mauve, I agree
  238. Link Mauve (And I hate typos. :p)
  239. Ge0rG Link Mauve: that shouldn't happen, as editorial changes shouldn't count against Deferral
  240. jonas’ this needs fixing, but is also separate
  241. jonas’ Ge0rG, there are varying opinions on that
  242. jonas’ we should ask Board to clarify maybe
  243. jonas’ some people say "if someone cares enough to fix a typo, it should become undeferred"
  244. Ge0rG I still propose a new arrow from "Proposed" to "Deprecated", after which we can LC those and bury them.
  245. jonas’ others (me, for example) say "only non-editorial changes should un-defer"
  246. Ge0rG jonas’: next time I submit a proto-XEP, I'll add a dozen typos to keep it in Experimental
  247. dwd OK, so no agreement - can someone take this to standards@ please? (I suggest someone who wants things to change)
  248. Ge0rG volunteers Link Mauve :D
  249. Kev If we allow proposed going to deprecation, I don't oppose it.
  250. Link Mauve volunteers too.
  251. Kev I'm just not convinced it's worth any of my cycles.
  252. dwd ... and if nobody does, I'll assume nobody wants it to change.
  253. Ge0rG dwd: we could vote on allowing "Proposed" --> "Deprecated" and then add it to tomorrow's Board agenda.
  254. dwd b) Tidying examples in XEP-0045 Flow's PR #715 remains unmerged.
  255. dwd Ge0rG, Nah. I don't think there's sufficient agreement to worry, and I'd rather ping the community first.
  256. lnj has joined
  257. Ge0rG 6b: IIRC we had a discussion that ended with disagreement between some council members and flow about what's the right thing.
  258. dwd So this PR came up last year, and I think we buried it in discussion about whether disco#info needed to be listed in a disco#info response.
  259. dwd Which was another (related) PR.
  260. dwd (Also by Flow)
  261. Link Mauve Imo fixing examples to match 0030’s text is a no brainer.
  262. Ge0rG Right. This PR only adds disco#info to examples.
  263. dwd My recollection is that Council decided that disco#info MUST be listed, as XEP-0030 says. Therefore we should presumably apply this one to fix the examples?
  264. Link Mauve That’s also what I remember.
  265. dwd (I mean, I dissented on that one, but whatever)
  266. Ge0rG dwd: that will make the examples look more normative and less example-y, won't it?
  267. dwd Ge0rG, I think they'll still look exampley, they'll just be better examples.
  268. jonas’ for certain definitions of better
  269. dwd jonas’, More accurate.
  270. jonas’ it is not relevant to the implementation of XEP-0045 itself
  271. jonas’ and more noisy
  272. Ge0rG I think that an example should focus on the things relevant to *this* XEP and not on boilerplate from other specs.
  273. dwd jonas’, And pointless. But that's what Council voted for, so...
  274. Kev I'm low-F on this. I'd rather like it if we were able to list only the bits relevant to a XEP in a XEP's example disco, but whatever.
  275. Ge0rG dwd: Council voted on disco#info being part of the response, not part of the examples of each XEP.
  276. Ge0rG I'm -0 on PR#715, because I like my examples short and focused.
  277. dwd I'm happy not to care. I'm unhappy if we don't close this one way or another though.
  278. dwd So, apply or not: It's votin' time!
  279. jonas’ -0
  280. Kev -0. Don't care.
  281. dwd -0
  282. dwd Link Mauve, ?
  283. Link Mauve I think it’d be useful to add “...” on a separate line to make them look more exampl-y, but +1.
  284. jonas’ Link Mauve, that would be even better IMO
  285. Ge0rG Link Mauve: that's an excellent proposal!
  286. dwd Link Mauve, Yeah, I'd be fine with that. I'd consider it editorial too.
  287. jonas’ or even better, <!-- ... -->, which wuoldn’t break schema validation
  288. dwd jonas’, That too.
  289. Ge0rG jonas’: 👍
  290. lnj has left
  291. Link Mauve jonas’, a previous council rejected this usage. :p
  292. jonas’ pft
  293. dwd Link Mauve, Really?
  294. jonas’ this council seems to be rather happy with it
  295. Link Mauve dwd, I think it was for the CLIENT: and SERVER: parts.
  296. dwd Ah, probably.
  297. Link Mauve But I’m +1 for this usage too.
  298. jonas’ those are kaputt anyways
  299. dwd Anyway, that's all folks.
  300. dwd 7) Ite, Meeting Est.
  301. jonas’ Link Mauve, you +1’d the other PR so we’ll have both now?
  302. Link Mauve jonas’, both sounds more fine than none or either.
  303. jonas’ how does it sound more fine than either, considering the noise factor?
  304. Ge0rG Thanks Dave
  305. lnj has joined
  306. lnj has left
  307. lnj has joined
  308. lnj has left
  309. lnj has joined
  310. Zash has left
  311. labdsf has left
  312. bear has left
  313. bear has joined
  314. Zash has left
  315. ralphm has left
  316. labdsf has joined
  317. labdsf has left
  318. labdsf has joined
  319. labdsf has left
  320. labdsf has joined
  321. labdsf has left
  322. labdsf has joined
  323. Tokodomo has joined
  324. Tokodomo has left
  325. Tokodomo has joined
  326. Tokodomo has left
  327. labdsf has left
  328. Tokodomo has joined
  329. Tokodomo has left
  330. labdsf has joined
  331. labdsf has left
  332. oli has left
  333. labdsf has joined
  334. Tokodomo has joined
  335. Tokodomo has left
  336. lnj has left
  337. pep. has left
  338. labdsf has left
  339. labdsf has joined
  340. labdsf has left
  341. labdsf has joined
  342. Tokodomo has joined
  343. Tokodomo has left
  344. lnj has joined
  345. oli has joined
  346. labdsf has left
  347. labdsf has joined
  348. lnj has left
  349. Tokodomo has joined
  350. Tokodomo has left
  351. Tokodomo has joined
  352. Tokodomo has left
  353. Tokodomo has joined
  354. Tokodomo has left
  355. lnj has joined
  356. pep. has left
  357. pep. has left
  358. Tobias has left
  359. lnj has left
  360. Zash has left
  361. Zash has left
  362. Zash has left