XMPP Council - 2019-01-09

  1. Ge0rG

    Good morning!

  2. Link Mauve


  3. Link Mauve

    Did we have an agenda btw?

  4. Ge0rG


  5. dwd

    We did, because I got around to it.

  6. Kev

    Yes, Dave sent it out yesterday.

  7. Ge0rG

    !praise dwd

  8. dwd

    I've not got around to my Voting Bot, though.

  9. Link Mauve

    Oh, just now I see it. :x

  10. jonas’

    I still don’t see the agenda

  11. jonas’

    where is it?

  12. Kev

    [Council] Council Agenda 2019-01-09

  13. jonas’

    is that a mailing list?

  14. jonas’

    separate from standards@?

  15. Link Mauve

    jonas’, it is council@.

  16. jonas’

    I’m not on that list

  17. Link Mauve


  18. Kev

    Alex should have added you after the elections.

  19. jonas’

    haven’t been added, afaict

  20. Kev

    If you mail me, I'm probably capable of doing the magic.

  21. jonas’

    I have two things which look like they may be email addresses of yours

  22. Kev

    isode please.

  23. jonas’


  24. jonas’


  25. Kev


  26. jonas’


  27. Kev

    'tis time.

  28. jonas’

    let’s just do IM over email!

  29. jonas’

    (oh somebody already did ;-))

  30. dwd

    Oh, it's time for a meeting!

  31. Kev

    It's not IM over email, it's TODO list over email :)

  32. jonas’


  33. dwd

    1) Roll Call

  34. Kev

    I'm here. I think.

  35. jonas’ is here

  36. jonas’


  37. Link Mauve is here too.

  38. jonas’

    Ge0rG, ?

  39. Ge0rG .o/

  40. jonas’


  41. dwd

    I'm here too. Apologies for last week.

  42. dwd

    2) Agenda Bashing

  43. jonas’

    same, I was caught up in house cleaning and totally forgot about day of week and time of day

  44. dwd

    Did I forget anything?

  45. Ge0rG


  46. jonas’

    I can’t tell, I haven’t seen the agenda

  47. dwd

    jonas’, Have you not?

  48. Ge0rG

    probably we should split 6a (PR #727) into individual LCs for process' sake

  49. jonas’

    no, I’m not on council@ as we discussed just now

  50. jonas’

    Kev will take care

  51. jonas’

    but I’ll just shout in AOB if something is missing or so

  52. dwd

    Oh. Whoops. I normally cc it to standards as well.

  53. Ge0rG also just bounced the Agenda mail to jonas’, just in case.

  54. dwd

    My mistake, anyway.

  55. jonas’


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

  57. Ge0rG

    Is that a vote or discussion first?

  58. dwd

    That's a vote for adoption, I believe.

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

  60. 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 ;-)

  61. jonas’

    Ge0rG, note, it defines properties which live *outside* the items, determined by the server

  62. jonas’

    it could easily be extended to support XPath or anything like that though

  63. Kev

    I'm not keen on it, but it clears my bar-of-incompetence for Experimental. So +1.

  64. Ge0rG

    jonas’: yes. But is there any reason not to embed those properties in the items?

  65. dwd

    Ge0rG, Yeah, this is indeed ordering by metadata external to the item payload.

  66. jonas’

    Ge0rG, yes, the server shalt not modify the items

  67. Ge0rG

    jonas’: what's wrong with the client adding the respective stamps?

  68. jonas’

    Ge0rG, goffi doesn’t find that correct (which I disagree with), because it can be "spoofed"

  69. jonas’

    see the discussion on-list for that

  70. Ge0rG

    oh, didn't catch-up on that.

  71. Ge0rG

    So I'm on-list, with fallback to -1.

  72. jonas’

    what’s your rationale for your fallback -1?

  73. Ge0rG

    At least this needs to be renamed "PubSub MAM retrieval ordered by creation or modification"

  74. Link Mauve

    I’m on list on that, I haven’t caught up with anything yet.

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

  76. Link Mauve

    (I’ll try to get better soon!)

  77. jonas’

    (OT: Subject: Welcome to the "Council" mailing list. Thanks Kev)

  78. jonas’

    dwd, it doesn’t have an impact on RSM, it happens before RSM even comes into play.

  79. jonas’

    although, the server might have to use different identifiers in RSM to make it work with RSM

  80. dwd

    jonas’, I think that needs mentioning. Or thinking about.

  81. Kev

    It does have an interaction with RSM, at least. Whether 'impact' or not is up to linguists :)

  82. jonas’

    dwd, I agree

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

  84. jonas’

    afaict, all except Kev are on-list?

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

  86. jonas’

    no, dwd hasn’t said anything yet

  87. dwd

    Yeah, I'll go with +0.

  88. jonas’

    it doesn’t require changes to XEPs

  89. dwd

    (Though I reserve the right to change that while others are still on-list).

  90. Ge0rG

    jonas’: it implies changes to their implementation.

  91. jonas’

    that’s true

  92. jonas’

    but those are two different things

  93. jonas’

    (kinda important when one of the affected XEPs is Draft)

  94. dwd

    OK, moving on.

  95. dwd

    4) Outstanding Votes

  96. dwd

    I don't think we have any, do we? I can't imagine we do anyway.

  97. dwd

    5) Next Meeting

  98. Ge0rG

    I can't remember any, but maybe this is the right time to remind about the Spreadsheet of Doom?

  99. dwd

    Or something.

  100. dwd

    Same time next week?

  101. jonas’


  102. Kev

    WFM, I think.

  103. dwd

    I'll assume 2019-01-16 1600Z unless anyone shouts.

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

  105. dwd

    Ge0rG, Ah... Should we reschedule now?

  106. Ge0rG

    My employer translocates me into another city for a full-time engagement, and I don't know the specific business hours there yet

  107. Ge0rG

    I'll hopefully know more by +1W

  108. dwd

    Ah, OK. Keep us posted; we can rearrange via email if it's a semi-permanent thing.

  109. dwd

    6) AOB a) Cleaning up Deferred items. Link's PR #727 seems unresolved - we should decide on a suitable way to handle this.

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

  111. Kev

    That's the obsoleting? We vote on the obsoletes don't we?

  112. jonas’

    the PR as is cannot be applied, so I (Council Member) propose I (Editor) just close this

  113. Link Mauve

    So, a) is a process issue.

  114. Ge0rG

    Kev: IIRC we can't vote to obsolete without an LC, and probably we shouldn't anyway

  115. jonas’

    and if we want to have process for that, we need to propose a modification of XEP-0001

  116. Link Mauve

    We are not allowed (?) to obsolete without a last call first.

  117. Ge0rG

    So why not just vote on an LC for all of them?

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

  119. Ge0rG

    So why not just vote on an LC for each of them?

  120. Link Mauve

    But I still believe obsolete is the correct status for these three XEPs (and more, but I wanted to start small).

  121. jonas’

    they have to pass to draft to allow obsoleetion, Ge0rG

  122. dwd

    jonas’, There's Proposed->Rejected

  123. jonas’

    Rejected ≠ Obsolete, but Rejecting would be an option, too

  124. Kev

    Sorry, why can't we go from Deprecated to Obsolete? That's what 9.10 says we can do :)

  125. dwd

    I'd be fine with Rejected, actually. Feels more accurate. But again, process.

  126. jonas’

    Kev, they’re deferred, not deprecated

  127. dwd

    Kev, We can -but these are Deferred, not Deprecated, I thought?

  128. Kev

    Oh, right.

  129. dwd

    We have Retracted, but I'd prefer not to use that personally. I'd happily go for allowing Deferred->Rejected though.

  130. jonas’

    vote for rejection without asking the community at all?

  131. dwd

    So, two questions: What do we want the process to be, and who wants to draft the PR to XEP-0001?

  132. Ge0rG

    issue a "Call for Deprecation"?

  133. jonas’

    I can do the PR to XEP-0001

  134. Kev

    And the third question: Is there a problem with Deferred XEPs staying Deferred?

  135. jonas’

    not for me (as Editor)

  136. dwd

    Kev, Well, yes - if we're happy with the process as-is.

  137. Ge0rG

    I suggest that we add an arrow from "Proposed" to "Deprecated"

  138. dwd

    I would note that it's much the same as expired Internet Drafts in the IETF, and those sometimes get "unexpired" years later.

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

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

  141. Ge0rG

    Kev: I think that "Deprecated" is a stronger signal not to implement it than "Deferred"

  142. Ge0rG

    What Link Mauve says!

  143. jonas’

    Link Mauve, but then it is more worthwhile to tackle the XEPs which actually have a chance to advance

  144. jonas’

    and which should advance

  145. jonas’

    and not those which are dead anyways

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

  147. Link Mauve

    jonas’, sure, in the end I’d like to do both.

  148. Ge0rG

    jonas’: you can't force other people to implement your XEPs

  149. dwd

    Link Mauve, Right, moving a XEP from Deferred is easy. And I'm not sure how we could make it "faster".

  150. Link Mauve

    Kev, whynotboth.jpg

  151. jonas’

    focus on the other part first, maybe, becauise the Deferred ones which are actually abandoned and should be aren’t the actual issue

  152. dwd

    Ge0rG, You don't need to, to move to Draft.

  153. jonas’

    Ge0rG, you don’t need implementations to move to Draft

  154. Link Mauve

    Also, I’ve in the past fixed a typo in a deferred XEP which put it back to experimental.

  155. Ge0rG

    ah well.

  156. Link Mauve

    I’d like to avoid doing that everytime there is a typo.

  157. jonas’

    Link Mauve, I agree

  158. Link Mauve

    (And I hate typos. :p)

  159. Ge0rG

    Link Mauve: that shouldn't happen, as editorial changes shouldn't count against Deferral

  160. jonas’

    this needs fixing, but is also separate

  161. jonas’

    Ge0rG, there are varying opinions on that

  162. jonas’

    we should ask Board to clarify maybe

  163. jonas’

    some people say "if someone cares enough to fix a typo, it should become undeferred"

  164. Ge0rG

    I still propose a new arrow from "Proposed" to "Deprecated", after which we can LC those and bury them.

  165. jonas’

    others (me, for example) say "only non-editorial changes should un-defer"

  166. Ge0rG

    jonas’: next time I submit a proto-XEP, I'll add a dozen typos to keep it in Experimental

  167. dwd

    OK, so no agreement - can someone take this to standards@ please? (I suggest someone who wants things to change)

  168. Ge0rG volunteers Link Mauve :D

  169. Kev

    If we allow proposed going to deprecation, I don't oppose it.

  170. Link Mauve volunteers too.

  171. Kev

    I'm just not convinced it's worth any of my cycles.

  172. dwd

    ... and if nobody does, I'll assume nobody wants it to change.

  173. Ge0rG

    dwd: we could vote on allowing "Proposed" --> "Deprecated" and then add it to tomorrow's Board agenda.

  174. dwd

    b) Tidying examples in XEP-0045 Flow's PR #715 remains unmerged.

  175. dwd

    Ge0rG, Nah. I don't think there's sufficient agreement to worry, and I'd rather ping the community first.

  176. Ge0rG

    6b: IIRC we had a discussion that ended with disagreement between some council members and flow about what's the right thing.

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

  178. dwd

    Which was another (related) PR.

  179. dwd

    (Also by Flow)

  180. Link Mauve

    Imo fixing examples to match 0030’s text is a no brainer.

  181. Ge0rG

    Right. This PR only adds disco#info to examples.

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

  183. Link Mauve

    That’s also what I remember.

  184. dwd

    (I mean, I dissented on that one, but whatever)

  185. Ge0rG

    dwd: that will make the examples look more normative and less example-y, won't it?

  186. dwd

    Ge0rG, I think they'll still look exampley, they'll just be better examples.

  187. jonas’

    for certain definitions of better

  188. dwd

    jonas’, More accurate.

  189. jonas’

    it is not relevant to the implementation of XEP-0045 itself

  190. jonas’

    and more noisy

  191. Ge0rG

    I think that an example should focus on the things relevant to *this* XEP and not on boilerplate from other specs.

  192. dwd

    jonas’, And pointless. But that's what Council voted for, so...

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

  194. Ge0rG

    dwd: Council voted on disco#info being part of the response, not part of the examples of each XEP.

  195. Ge0rG

    I'm -0 on PR#715, because I like my examples short and focused.

  196. dwd

    I'm happy not to care. I'm unhappy if we don't close this one way or another though.

  197. dwd

    So, apply or not: It's votin' time!

  198. jonas’


  199. Kev

    -0. Don't care.

  200. dwd


  201. dwd

    Link Mauve, ?

  202. Link Mauve

    I think it’d be useful to add “...” on a separate line to make them look more exampl-y, but +1.

  203. jonas’

    Link Mauve, that would be even better IMO

  204. Ge0rG

    Link Mauve: that's an excellent proposal!

  205. dwd

    Link Mauve, Yeah, I'd be fine with that. I'd consider it editorial too.

  206. jonas’

    or even better, <!-- ... -->, which wuoldn’t break schema validation

  207. dwd

    jonas’, That too.

  208. Ge0rG

    jonas’: 👍

  209. Link Mauve

    jonas’, a previous council rejected this usage. :p

  210. jonas’


  211. dwd

    Link Mauve, Really?

  212. jonas’

    this council seems to be rather happy with it

  213. Link Mauve

    dwd, I think it was for the CLIENT: and SERVER: parts.

  214. dwd

    Ah, probably.

  215. Link Mauve

    But I’m +1 for this usage too.

  216. jonas’

    those are kaputt anyways

  217. dwd

    Anyway, that's all folks.

  218. dwd

    7) Ite, Meeting Est.

  219. jonas’

    Link Mauve, you +1’d the other PR so we’ll have both now?

  220. Link Mauve

    jonas’, both sounds more fine than none or either.

  221. jonas’

    how does it sound more fine than either, considering the noise factor?

  222. Ge0rG

    Thanks Dave