XMPP Council - 2018-04-11

  1. Kev

    Do we have agenda for today?

  2. moparisthebest

    the proposal to write 2 MUC PRs I think

  3. moparisthebest

    the vote on whether someone should bother writing the PRs specifically :)

  4. Kev

    Pretty sure im-ng should be on there too.

  5. Kev

    Or should have been last week, but wasn't.

  6. Dave

    Kev, I've been busy, I do apologise. I'll knock this out. FWIW, im-ng was fractionally too late for last week, IIRC. Unless I'm thinking of the week before, and just forgot last week.

  7. Kev

    The latter.

  8. jonasw

    +1 for the latter because I’m fairly certain that I didn’t do any editor work last week

  9. Dave

    Oh. Whoops.

  10. Dave

    Right, time.

  11. Kev

    Think so.

  12. Dave

    1) Roll Call

  13. daniel


  14. Ge0rG


  15. Dave

    SamWhited, ?

  16. Dave

    2) Agenda Bashing

  17. Dave

    So I've not managed to do an Agenda this week, for which I apologise.

  18. Kev

    I would love to bash an Agenda.

  19. Dave

    I think we have two CFEs, Kev's IM-NG protoXEP, and... anything else?

  20. jonasw

    .oO(piñarta agenda?)

  21. jonasw

    Dave, the GC1.0 abolishment vote

  22. Dave

    Oh, yes, of course.

  23. Ge0rG

    I also have a proposal for MUC self-ping

  24. daniel

    i want to register the muc config option for mam

  25. daniel

    or at least get the process going / clarify what the process is exactly

  26. Dave

    OK - I'm going to guess that between the protoXEP, CFEs, and GC-1.0 we'll probably fill the half hour, but we'll see.

  27. SamWhited

    sorry, I'm here

  28. Ge0rG

    No need to be sorry.

  29. Ge0rG

    Dave: 3) minute taker?

  30. Dave

    Ge0rG, Good plan.

  31. Dave

    3) Minute Taker

  32. Dave

    Either Tedd Sterr will do it or else I will.

  33. Ge0rG

    It looks like the abolition of Pidgin is a Board agendum now.

  34. Dave


  35. Ge0rG


  36. daniel

    ,oO(can you just get rid of pidgin be removing session support on the server?)

  37. Ge0rG

    daniel: it will probably break other clients as well

  38. Dave

    Right, bear with me while I figure out which CFEs have completed.

  39. jonasw

    Dave, 0131, 0141, 0229 AFAICT

  40. Dave

    jonasw, Thanks.

  41. Dave

    So with that:

  42. jonasw

    (provided you already voted on 0092 and 0122)

  43. Dave

    4) Advance XEP-0131 to Final

  44. Dave

    jonasw, Yes, we did.

  45. jonasw


  46. Dave

    This one is SHIM, BTW.

  47. Kev

    -1, doesn't have the implementations (and other reasons).

  48. SamWhited

    Also -1, this doesn't feel like it fits a need in the ecosystem and doesn't have the implementations. We should kill it instead.

  49. Dave

    I'm going to vote on-list for all of these, I warn in advance - however, in the case of SHIM I can't help feeling I'd *like* to ditch it but it's referred to by other XEPs.

  50. jonasw

    isn’t it used by PubSub?

  51. Dave

    jonasw, Pubsub and XEP-0149.

  52. daniel

    i actually implemented this once. but i feel like this is so niche that who ever needs it can just make up their own syntax and/or use the deprecated one. so -1

  53. Ge0rG

    I've had a tough fight against generic headers in 0363. -1

  54. Dave

    5) Advance XEP-0141 to Final

  55. Dave

    Data forms layout, BTW.

  56. Kev

    -1 doesn't have the implementations

  57. Ge0rG

    is that referenced from others as well?

  58. Dave

    Ge0rG, Nope. I've seen it used, though, in XEP-0346 implementations.

  59. daniel


  60. Ge0rG


  61. Kev

    I'd like to advance 141, but we didn't have the numbers in the CfE, that I saw.

  62. Kev

    Someone tell me I'm wrong, by all means.

  63. SamWhited

    -1, same reason as Kev, but also think forms is too complex already and we don't need to shoehorn layout information into the document structure.

  64. Dave

    5) Advance XEP-0229 to Final

  65. Dave

    LZW stream compression

  66. Dave

    I do have a vote for this: -1 for implementations and also I don't see a driving need for it.

  67. SamWhited

    I have used this and have implementations, but it's underspecified so -1.

  68. Kev


  69. daniel


  70. Ge0rG

    -1 for the security issues of mixing different data classes into a compressed stream

  71. daniel

    Ge0rG, that argument applies to compression in general though?

  72. daniel

    not to that particular xep

  73. SamWhited

    Either way, we need to figure out what we're doing with 0138 and then this should probably just follow whatever happens with that.

  74. Ge0rG

    daniel: it applies to compression in general and thus to this XEP by extension

  75. Dave

    6) Adopt "IM Routingng"

  76. Dave

    ProtoXEP: https://xmpp.org/extensions/inbox/im-ng.html

  77. Kev

    This is clearly going to need to adapt as we make further decisions, but I'd like to get it under XSF control.

  78. Ge0rG

    How could I have missed that submission? on-list

  79. Kev

    So I'm +1.

  80. daniel

    Ge0rG, I'm just saying it feels 'unfair' to punish the lzw xep instead of 138

  81. Dave

    I worry that this might end up the bike shed of bike sheds, but I'm not going to veto, so 0.

  82. Ge0rG

    daniel: I agree. Please put 0138 on the next agenda.

  83. Kev

    Dave: It might, but I think it's something we have to work on, and there was reasonable (not particularly rough) consensus at the Summit, I think.

  84. daniel

    +1 to get it under xsf control. but i'm not really sure i like it in it's current form

  85. Ge0rG

    I've heard somebody gave a speech, or somesuch.

  86. SamWhited


  87. Kev

    daniel: Sure, that's fine (not liking the current form) - but I thought step one was getting some words down that people can disagree with.

  88. Dave

    7) Kill GC-1.0

  89. Dave

    Kev, "Get a number". :-)

  90. Ge0rG

    obviously +1

  91. Kev

    I am, in principle, ok with removing gc1 from 45, but only if we can do so in a way that makes everything better.

  92. daniel

    link to pr?

  93. Kev

    daniel: There's no PR, this is just raising the idea up a flagpole and seeing who salutes.

  94. Dave

    daniel, There's no PR, so this is a vote on the principle.

  95. Kev

    i.e. this is a vote on position, rather than standards advancement.

  96. Ge0rG

    I promise to prepare a PR if this vote is accepted. Although I don't promise *when* I will be able to submit it.

  97. SamWhited

    I am tentatively +1 on the general idea; can't hurt to see a PR either way.

  98. Kev

    I'm fine with seeing a PR, and if you *can* produce one that doesn't break anything I'll be ok with it, but I think that's a big ask and I'm not sure it's possible.

  99. Dave

    I'm fine with removing "bare" presence as a mechanism for joining a chatroom. However, I worry about what existing clients would do is they fall out of sync and *inadvertantly* join using GC-1.0, and have that then perform a different action.

  100. Ge0rG

    We have ~two weeks worth of numbers from prosody.im and yax.im, showing that there was only one client not supporting MUC protocol

  101. Dave

    Ge0rG, Right, but that is a different problem to the one I outline.

  102. Kev

    Ge0rG: Yes, that's why I'm in principle ok with the idea, as long as it can be done such that nothing existing breaks.

  103. Ge0rG

    Dave: yes. My position is that it's better to uncover to the user that they were gone than to silently re-join a MUC and probably missing a part of history.

  104. Dave

    Ge0rG, In any case, I think I'm keen to see what this would do in practise, so +1 to someone else writing a PR. :-)

  105. daniel


  106. Dave

    Ge0rG, Ah. So yes. But that presumes a client will gracefully handle an unexpected join rejection to a presence stanza they didn't think was a join in the first place.

  107. Ge0rG

    Dave: I hope that sane clients will handle a presence error from a MUC as "you are not there anymore"

  108. Dave

    Ge0rG, As such, when I see what you're aiming to do, it might nudge me into a couter-proposal.

  109. Dave

    Ge0rG, That is extremely optimistic of you. Possibly right, too. But certainly optimistic.

  110. Ge0rG

    Dave: I don't have a proposal beyond what I wrote on standards@

  111. Ge0rG

    Dave: I'm not sure I'm sane enough to fix insane clients. Nor that I want to volunteer my sanity for that goal.

  112. Dave

    Ge0rG, Sure. But it might be fun to trial any change and see what clients do.

  113. Ge0rG

    Kev: I'm not sure whether your position boils down to a -1 essentially, because I can't fix what is broken with MUCs getting out of sync, and GC1 is just a cover-up for it.

  114. Dave

    Anyway, as I say, I'm in favour of doing this given your evidence thus far.

  115. Kev

    Ge0rG: I am trying to be open that I think it's an impossible job, while not wanting to stop you trying if you're convinced you can.

  116. Ge0rG

    Kev: I'm pretty sure I can't fulfill your requirement. And I still think that it's based on a flawed assumption

  117. Dave

    SamWhited, I don't think I have a vote from you on this one.

  118. Kev

    My requirement basically being that it's a Draft XEP so we shouldn't break anything that's currently deployed against it?

  119. SamWhited

    > I am tentatively +1 on the general idea; can't hurt to see a PR either way.

  120. Dave

    SamWhited, Oh, sorry - just spotted that.

  121. Kev

    I think it'll come down to what breaks and where.

  122. Ge0rG

    Kev: do you consider sending an error to non-joined clients a "break"?

  123. Dave

    So we're unanimously in favour of Georg writing a PR we can vote on. :-)

  124. Kev

    Ge0rG: Maybe, depending how clients react to it.

  125. Kev

    If all clients do a sensible thing, I can probably be talked into it.

  126. Ge0rG

    Kev: Alright. Could you please perform a study of the clients that you care about?

  127. Kev

    Not likely.

  128. Ge0rG

    I mean, realistically we'll have to reduce the subset of clients.

  129. Dave

    Ge0rG, I know I don't have access to all the clients I'd want to know about.

  130. Ge0rG

    I suggest we test all clients that comply with this year's Compliance Suite.

  131. daniel


  132. Dave

    Ge0rG, I don't know how clients I actually work with would react.

  133. Dave

    Anyway, we've voted, so:

  134. Dave

    8) AOB

  135. daniel

    whats the process for registering a new muc config option?

  136. Ge0rG

    I'd like to put the MUC self-ping suggestion up for a vote-on-principal

  137. daniel

    can we take a vote and order the registry to include it?

  138. Ge0rG

    I'd like to put the MUC self-ping suggestion up for a vote-on-principle

  139. Ge0rG

    The one from here: https://mail.jabber.org/pipermail/standards/2018-April/034763.html

  140. daniel

    (since changing the xep45 has been rejected by council members who still serve this year)

  141. Dave

    daniel, Do you know, I've actually no idea. I'll look into the process. I'd expect it's a matter of "document it".

  142. Ge0rG

    This one is at least less probable to break all clients.

  143. Dave

    daniel, I don't think "changing xep45" is quite the same as "adding a new option". Servers add new options all the time, so unless it's changing existing behaviour, a XEP defining the additional behaviour should be uncontentious.

  144. Dave

    Ge0rG, Looks fine to me. Feels like it could be documented in a new XEP, too.

  145. Ge0rG

    Dave: what's wrong with adding a use-case into 0045?

  146. Kev

    I'm fine with adding a self-ping to MUC to check you're there. I'm not ok with intercepting 199 pings to users and replying from the server.

  147. Ge0rG

    Kev: not to users, to yourself.

  148. Dave

    Kev, Not to users, to occupants.

  149. Dave

    Kev, You already have to implement vcard IQs, after all.

  150. Kev

    Only to your own occupant JID might be ok.

  151. daniel

    i'm ok with specifying that a ping to self should be handled (and responded to) by the server

  152. Dave

    9) Next Meeting

  153. Dave

    Same time next week?

  154. SamWhited


  155. Kev


  156. daniel


  157. Ge0rG


  158. Dave

    10) Ite, Meeting est

  159. Ge0rG

    The self-ping-to-occupant was the only useful and O(1) way for a client to check whether it's still joined, anyway.

  160. Dave

    Once again, sorry for the disorganised lack of agenda,, and thanks for bearing with me.

  161. Ge0rG

    Dave: next time we expect an organised lack of agenda

  162. Kev

    Thanks all.

  163. Ge0rG


  164. daniel

    > I don't think "changing xep45" is quite the same as "adding a new option". Servers add new options all the time, so unless it's changing existing behaviour, a XEP defining the additional behaviour should be uncontentious. well you vetod https://github.com/xsf/xeps/pull/204 last time. that’? what i meant by 'changing the xep'

  165. daniel

    (re config option for muc)

  166. daniel

    so apparently this is not the right way to do it

  167. daniel

    would you like me to create a full new xep just for this config option?

  168. Dave

    That was a long time ago, no wonder I'd forgotten.

  169. daniel

    i would just like to find the 'correct way' and then just do it. instead of bike shedding it to death again

  170. Dave

    daniel, Registry is at https://xmpp.org/registrar/formtypes.html#http:--jabber.org-protocol-mucroomconfig and the submission process is https://xmpp.org/extensions/xep-0068.html#registrar-reg-formtypes-process

  171. daniel

    and it's up to the registrar to decide whether to accept this?

  172. flow

    daniel, appears so