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