XMPP Council - 2018-02-14


  1. Dave

    [[ Ten minute warning Kev SamWhited daniel Ge0rG ]]

  2. SamWhited

    Thank you ten

  3. Ge0rG

    Is it that time again?

  4. Dave

    It is indeed.

  5. Dave

    1) Roll Call

  6. Dave

    I'm here, by the way.

  7. Ge0rG

    .o/

  8. daniel

    hi

  9. Dave

    SamWhited, Kev ?

  10. SamWhited

    I'm here

  11. Dave

    Kev did say he might struggle to attend.

  12. Dave

    2) Embarrassed shuffling as everyone realises it's St Valentine's Day and nobody thought to buy the Chair some nice flowers.

  13. Dave

    Did anyone?

  14. Dave

    Pfft.

  15. Ge0rG

    🌹

  16. SamWhited

    *crickets*

  17. Dave

    Ge0rG, Colour me impressed.

  18. Dave

    3) Deprecate XEP-0071 XHTML-IM https://xmpp.org/extensions/xep-0071.html

  19. Ge0rG

    +1

  20. SamWhited

    +1

  21. Ge0rG

    initially I was against, but I really ended up liking Styling, and I think it will cover most use cases

  22. daniel

    +1

  23. Dave

    +1, noting that this is very specifically deprecating XHTML-IM, and not banning XHTML over XMPP in any form.

  24. SamWhited

    It at least provides us with a good starting point; hopefully it ends up being actually adopted, but we'll see.

  25. Ge0rG

    Can we add Styling to the 2018 Compliance Suite now?

  26. SamWhited

    *2019

  27. Dave

    4) Deprecate XEP-0013 Flexible Offline Message Retrieval https://xmpp.org/extensions/xep-0013.html

  28. Ge0rG

    SCNR.

  29. SamWhited

    +1, while noting that people do use this to clear history, but having a whole confusing XEP for one small feature (that clients will continue to do) seems confusing.

  30. Ge0rG

    -1, this seems to be the only way to suppress offline messages for a MAM enabled client

  31. SamWhited

    So? Clients can continue to do that. If they need legacy compatibility, they will have to implement parts of deprecated XEPs, that's why it's "legacy"

  32. Ge0rG

    SamWhited: I'm not sure since when "offline messages" is legacy.

  33. SamWhited

    Since MAM became widely adopted

  34. Dave

    SamWhited, It's not clear this is only useful for legacy compatibility - this seems to be the only way to do something currently desirable.

  35. Ge0rG

    SamWhited: then MAM needs a way to suppress that legacy.

  36. daniel

    i mean existing implementations wont go away and it feels wrong to implement xep13 just for the purge

  37. daniel

    even though i was actually considering to do that for prosody

  38. Ge0rG

    daniel: how do you handle offline messages when MAM is used?

  39. daniel

    i purge

  40. Ge0rG

    see!

  41. SamWhited

    And presumably it will continue to purge even if we stop recommending that people implement this entire XEP.

  42. Ge0rG

    my server also recently had a meltdown because a user requested 32K of messages from MAM, of which ~32K were chat states.

  43. SamWhited

    That seems like an unrelated problem

  44. Ge0rG

    it is.

  45. Dave

    Anyway, I'm -1 on deprecating this. Seems like it's needed at least in part.

  46. Ge0rG

    somebody should send a mail to standards@ asking for more discussion

  47. daniel

    im +/-0

  48. Ge0rG

    I also think that we need to leverage the MAM-sync / carbons / session2 thing for that

  49. SamWhited

    I very much disagree; we'll never move on or get an alternative if we keep recommending the existing thing.

  50. SamWhited

    And in the mean time it's confusing and clients have to cherry-pick parts of the XEP, which feels poor.

  51. Ge0rG

    SamWhited: so you think cherry-picking parts of a deprecated XEP is better?

  52. Dave

    SamWhited, I'm happy to say it's the old way of doing X once there's either no need to do X or if there's a more modern way.

  53. Ge0rG

    What Dave said.

  54. SamWhited

    Ge0rG: no, I think encouraging us to come up with a solution is better.

  55. SamWhited

    We will never get a modern way unless we deprecate the old way

  56. Ge0rG

    SamWhited: that doesn't depend on (not) deprecating 13.

  57. Dave

    SamWhited, I'd argue we'll never get a modern way unless we make a modern way.

  58. Ge0rG

    SamWhited: apparently the old way was good enough for the last year.

  59. SamWhited

    We being the people in this room? Because if we don't encourage someone else to do it, we'll just end up doing everything (eg. like styling)

  60. Ge0rG

    SamWhited: "we" being the people implementing MAM clients.

  61. Dave

    5) Deprecate XEP-0137 Publishing Stream Initiation Requests https://xmpp.org/extensions/xep-0137.html

  62. Dave

    +1

  63. SamWhited

    It's good enough except that there's a whole huge XEP attatched to it that people aren't using; by deprecating existing clients will continue to use it, new clients will hopefully find a new way.

  64. Ge0rG

    What is the context for 0137 - where is it used/needed?

  65. daniel

    whats the argument for the deprecation?

  66. Dave

    SamWhited, But there isn't a new way. Which means our current recommendation would be to use the old way. :-)

  67. Dave

    XEP-0137 is SI-PUB, and its dependent on Session Initiation which we already deprecated.

  68. SamWhited

    Dave: we're going in circles, our current recommendation *is* to use the old way, I am trying to change that and encourage someone to come up with a new way.

  69. daniel

    +1

  70. Ge0rG

    +1

  71. SamWhited

    We have this same problem and argument on almost everything; there will *never* be a new way if we keep encouraging use of the old way. In the mean time, we don't break anything by deprecating and changing our recommendation.

  72. SamWhited

    Deprecation, not obsoletion.

  73. Dave

    Only caveat I have with XEP-0137 is that we never duplicated this in Jingle FT. But that might be because nobody cared.

  74. Dave

    Anyway - SamWhited - XEP-0137?

  75. SamWhited

    +1 from me, obviously

  76. Dave

    6) Voting Reminders

  77. SamWhited

    But I don't understand why we think we have to have all functionality identical up front. This exact same thing happens almost every time a new replacement comes out, and it's bad policy, this is why we can never move the state of the art forward.

  78. Dave

    So obviously Kev hasn't voted on anything, but he's not here. Otherwise Ge0rG and XEP-0234 to Draft.

  79. Ge0rG

    Dave: still working on it.

  80. Dave

    SamWhited, I don't think that's the case here.

  81. Dave

    7) AOB

  82. SamWhited

    It absolutely is; it was for XHTML-IM too, it means if we don't do it it will never get done because we don't put any pressure on the community and just keep confusing old alternatives around.

  83. Dave

    No, we are in the process of deprecating XHTML-IM not by creating a new XEP with identical functionality, but by ensuring the basic use-cases are still possible.

  84. daniel

    no aob from me

  85. Ge0rG

    Apparently people had a problem they needed to solve (disable offline messages), and they found 0013.

  86. SamWhited

    We wouldn't have had to create a new XEP at all except that this argument was used, is my point. We could have encouraged the community to do it.

  87. Ge0rG

    I'd like to have some more discusion regarding HTTP-Upload and custom HTTP headers.

  88. daniel

    lol

  89. Ge0rG

    SamWhited: we are the community.

  90. Dave

    SamWhited, To put it another way, Deprecation means "No new implementations", and right now people seem to need a small chunk of XEP-0013, and no other way of doing it.

  91. Dave

    Ge0rG, Here?

  92. daniel

    Ge0rG, because we haven't been discussing this for the last five hours?

  93. SamWhited

    That seems perfectly fine to me; if it's a feature that's really needed, then a new XEP or a part of MAM can be added to make it work.

  94. SamWhited

    We are encouraging confusion and entire 0013 implementations just for one small part.

  95. Flow

    Dave, isn't the jingle counterpart of xep137 xep358?

  96. Dave

    Ge0rG, I'm basically sticking on -1 for XEP-0363 on the basis that I'm pretty sure the Security Considerations need to mention these kinds of things.

  97. daniel

    also purging is actually a pretty bad way of dealing with that

  98. Ge0rG

    SamWhited: We are not encouraging anything at all, 0013 is just the only solution to that problem.

  99. Dave

    Flow, Good point.

  100. daniel

    i know i'm doing this myself. but it breaks stuff

  101. SamWhited

    We're encouraging it by having a big green "Draft" banner at the top of the XEP. That makes it our recommendation.

  102. Ge0rG

    indeed, purging causes race conditions.

  103. Ge0rG

    SamWhited: most people don't even understand what "Draft" actually means.

  104. Dave

    SamWhited, Right, but if it's a real problem, and this is the way we recommend solving it, I don't see a way out.

  105. daniel

    Ge0rG, not only that. it breaks stuff if your server annouces mam but your personal policy is set to never

  106. daniel

    then you purge but don't get anything from ma

  107. daniel

    then you purge but don't get anything from mam

  108. Ge0rG

    Yay.

  109. Dave

    SamWhited, And no, it shouldn't be up to us to create a new one. But equally, it's not up to us to try to force others to do so if people think it's good enough.

  110. SamWhited

    It is a real problem, because until recently if you tried to figure out how to do history with XMPP you found MAM, Archiving, and offline messages. We're now down to two, but that's not less confusing.

  111. daniel

    (i'm planning on annoucing the current mam policy in disco)

  112. Ge0rG

    daniel: on the server or on the client?

  113. SamWhited

    I disagree, it's absolutely on us to put pressure on and guide the community on the technical aspects of XMPP

  114. daniel

    the account

  115. Ge0rG

    daniel: could you also address (c) from https://mail.jabber.org/pipermail/standards/2017-November/033762.html

  116. Dave

    SamWhited, But not by just deprecating everything we don't like.

  117. Dave

    SamWhited, BTW, I'd suggest reviewing XEP-0160 as well, if you're keen to get rid of offline messages.

  118. daniel

    Ge0rG, getting stuff into 313 is a pain in the ass though

  119. SamWhited

    It's not about things we don't like, it's about reducing confusion. Deprecating seems like a perfectly good way to put a bit of pressure on to move in a certain way

  120. SamWhited

    Dave: I have that one on my list to look into as well

  121. Dave

    SamWhited, Sure, but only if there's a way to move. Otherwise I don't see that as reducing confusion.

  122. Ge0rG

    Dave: is it too late to vote on 0234 and get that into the minutes? Or should I properly on-list my +1?

  123. Dave

    Ge0rG, Nah, go for it.

  124. Dave

    Ge0rG, You can always take on the minutes and add it yourself. ;-)

  125. Ge0rG

    Dave: +1 to advancing 0234

  126. SamWhited

    There is a way to move: if there is no longer a solution, someone needs to write a new one. That seems fine to me.

  127. daniel

    Ge0rG, but i think putting the current setting in a form in the account disco would address (c)

  128. Ge0rG

    SamWhited: people will just stick to 0013, which never was the right way to handle it anyway

  129. Ge0rG

    daniel: essentially just removing the default value.

  130. Dave

    SamWhited, That's a way for the community as a whole to move, not for individual client developers.

  131. SamWhited

    Individual client developers won't drop support for 0013 overnight, you're right, and that also seems fine.

  132. SamWhited

    Anyways, obviously this is doing no good, I just think this argument is always used and it always bites us later.

  133. Dave

    SamWhited, Just as a note, assuming that all the other votes go through, we'll have deprecated 5 XEPs so far this session. We're doing pretty good on clearing cruft. If we're always using this argument, it's not been very effective.

  134. Dave

    So, in the closing moments:

  135. Dave

    8) Next Meeting

  136. SamWhited

    Mostly only because I've forced the issue again with a new council, or one of us has just done the work ourselves.

  137. Dave

    Same time next week?

  138. Ge0rG

    +1W WFM

  139. SamWhited

    WFM

  140. daniel

    wfm

  141. Dave

    OK, then thanks all.

  142. Dave

    9) It, Meeting Est

  143. Dave

    Ite, even.

  144. Dave

    Look at that - squeezed under 30 minutes.

  145. Ge0rG

    Damn, we forgot the 2018 Compliance Suite.

  146. SamWhited

    Thanks all

  147. SamWhited

    Ge0rG: what about them?

  148. Ge0rG

    Oh, wait. They are Draft already. Everything is good.

  149. Ge0rG

    Sorry.

  150. Dave

    Oh. We should probably deprecate any old ones that haven't been.

  151. SamWhited

    The last ones that were accepted were 2012 I think, and we already deprecated those last term

  152. SamWhited

    Unless we missed some I *think* we're good

  153. Ge0rG

    0375 is retracted, 0302 is obsolete

  154. Dave

    Oh, good stuff.

  155. Ge0rG

    0270 is obsolete too. Looks good to me

  156. SamWhited

    Although I'll note that people pushed to keep the 2012 ones around even though they were confusing and dated and it just looked terrible using the same argument of "there's no replacement yet". I don't remember how I convinced people that it just made us look bad to keep them, but it took longer than it should have. *grumble, grumble*

  157. Kev

    Sorry, dragged into meetings so couldn't be here.

  158. Ge0rG

    Hi Kev

  159. Dave

    Kev, Did you just forget to buy me flowers?

  160. Dave

    Going to take that as a yes.

  161. Ge0rG

    Lol.

  162. Dave

    Done some minutes.