XMPP Council - 2017-10-25

  1. Tobias

    Hi daniel, dwd, Link Mauve, SamWhited. It's about time

  2. Tobias

    1) Roll call

  3. SamWhited


  4. daniel


  5. dwd

    Whoops. Here.

  6. Tobias

    2) Minute taker

  7. Tobias

    any volunteers?

  8. Tobias

    jcbrand, maybe you? :)

  9. jcbrand

    Tobias: I'd be happy to :)

  10. Tobias


  11. SamWhited


  12. Tobias

    3) Obsoleting XHTML-IM

  13. Tobias

    Where are we on this topic?

  14. dwd

    I think discussing has stalled.

  15. dwd

    I think discussion has stalled.

  16. Tobias

    last message 6 days ago, yes

  17. Tobias

    pretty much cross read everything

  18. SamWhited

    It seems like most people on list (with a few exceptions of course) were interested in a replacement, and that a large group (unsure if majority) were interested in deprecating before a replacement is ready given the history of security issues with this spec.

  19. dwd

    SamWhited, I largely agree; however it doesn't feel like we have consensus across the standards participants, and I'm not sure how we could get it.

  20. SamWhited

    I don't think we can or ever will reach a consensus and it's up to the council to make a decision taking the community feeling into account.

  21. SamWhited

    Anything this big is impossible to get consensus on, that's why we have a council.

  22. Tobias

    yeah...there are definitly reasonable opinions on wanting to keep it

  23. SamWhited

    It did seem to me that most were in favor of a replacement though, and that "go ahead and deprecate" or "push forward on a replacement and wait then deprecate" is the place where there was more contention

  24. SamWhited

    Or is that just me?

  25. dwd

    SamWhited, I don't think that's a bad reading. Just that the minority against deprecation were both vocal and reasonable.

  26. Tobias

    that's also the impression i got

  27. Tobias


  28. SamWhited

    Cool; obviously I'm biased so I wanted to make sure I didn't misread the temperature of that thread

  29. Kev

    I think the conversation stalled because some people are watiing to see the alternative.

  30. dwd

    SamWhited, Don't get me wrong, I'd like to kill XHTML-IM with fire. All the opinion I've got from dedicated web developers is that handling user-entered XHTML is playing with fire.

  31. Kev

    I thought we were going to see the new spec that wasn't likely to be easy to mis-implement.

  32. SamWhited

    I think we should push forward with an alternative and would like to volunteer to write a proposal and start a SIG to investigate how it could be done better.

  33. dwd

    Kev, I've half a snippets XEP, which might address some of the needs for XHTML.

  34. SamWhited

    A proposal for a SIG, I mean.

  35. dwd

    SamWhited, I don't really want to spin off a whole SIG if we can avoid it.

  36. SamWhited

    That also sounds fair, I thought that might be a good way forward but could go either way

  37. SamWhited

    I volunteer to email the list asking for interest and requirements gathering then :)

  38. daniel

    Fwiw I still have that im markdown xep on my todo list

  39. daniel

    I've been traveling for the last couple of weeks though and didn't get around to

  40. Tobias

    SamWhited, sounds great initating a mail asking for interest/requirements

  41. SamWhited

    My plan was to ask for formatting use cases, distill requirements and scope from that, and then see if any of the existing proposals fit or call for a new one.

  42. Tobias

    right, maybe markdown fills those requirements or not, we'll see

  43. SamWhited

    Sounds good, I'll prepare that email sometime over the next few days.

  44. Tobias

    SamWhited, so do we want to vote on obsoleting it now or do you withdraw your request to have it obsoleted. Just want to make sure your initial request isn't overlooked.

  45. SamWhited

    I would like to request that we obsolete XHTML-IM now. As always, this will not result in everyone not supporting it overnight, it just means we don't recommend new implementations. Given its history, I think it would be irresponsible to continue to recommend it.

  46. Tobias

    arlight..then let's vote on it

  47. Tobias

    4) Vote on Obsoleting XEP-0071: XHTML-IM

  48. SamWhited


  49. daniel


  50. dwd

    I think a greater match for the community would be to have a replacement for the IM case, so I'll vote -1 (noting that this is presumably a simple majority vote and therefore this is not a veto).

  51. Link Mauve

    Woops, sorry I didn’t see the time.

  52. Link Mauve

    I’m here now, let me backlog.

  53. Tobias

    i'm also -1 until there is an alternative experimental XEP for the IM case. XHTML-IM is currently the only way to exchange formatted messages between XMPP clients

  54. SamWhited

    I'd like to note that I think always requiring a replacement before we can stop recommending something is one of the faults with our process. It's always the same, and is why we have duplicate specs, old things no one implements that are just confusing, and specs with security issues still around.

  55. SamWhited

    Also that not recommending it does not mean no one can implement it if they just desperately want compatibility with something else that already has it.

  56. dwd

    SamWhited, I don't think it *is* part of our process. I just think it matches my sense of the standards list participant's preference better.

  57. SamWhited

    Yah, "process" might be the wrong word, "culture" maybe.

  58. Link Mauve

    I’m -1 on obsoleting, as the XEP fills a very much needed feature and there is no alternative currently.

  59. Tobias

    SamWhited, what do you recommend people wanting formatted messages in their XMPP client and also want to interop with other clients out there right now?

  60. SamWhited

    And there probably won't be as long as people can use "but we already have a thing" as an excuse. Obsoleting also provides pressure to come up with a replacement.

  61. SamWhited

    I recommend they don't, but if they really need to then nothing stops them from implementing XHTML-IM anyways.

  62. Tobias

    SamWhited, that's true.

  63. SamWhited

    Or I recommend they join the discussion about a replacement; obsoleting also provides pressure towards coming up with a good replacement.

  64. Link Mauve

    SamWhited, pressure isn’t anything we need imo.

  65. Link Mauve

    If someone wants to take part into that SIG (even informal), they would do so without any kind of pressure from us.

  66. SamWhited

    And I will as I mentioned earlier, but that's not the only place where a bit of pressure is helpful.

  67. dwd

    Actually, I think SamWhited has convinced me to change my vote.

  68. SamWhited

    Convincing people to contribute is also useful, taking away "but we already have a spec that's draft" as an argument is also helpful.

  69. dwd

    On balance, deprecating it will at the very least break the stalemate, so I'll change my vote ot +1 to deprecate.

  70. dwd

    Sorry for the confusion.

  71. SamWhited

    Thanks Dave, I appreciate it. Obviously I feel strongly about it

  72. Tobias

    XEP-0001 doesn't mention whether disapproving XEPs requires a majority vote or all council members being in agreement. But I'd assume it's majority as it's the same for the approval case

  73. SamWhited

    > A majority of Council members must vote +1 in order for a XEP to advance.

  74. SamWhited

    I assume that's advancing to any state, including obsolete

  75. Tobias


  76. SamWhited

    But I'm not sure. Board question?

  77. Tobias

    SamWhited, according to the flow chart it would be an advancement

  78. dwd

    Tobias, I believe that if Council folk were allowed to veto it would be mentioned.

  79. Tobias

    So with 3 (+1) votes and 2 (-1) votes, we decide to change the state of XEP-0071: XHTML-IM to Obsolete

  80. Tobias

    5) Date of next

  81. Tobias

    Same time next week

  82. Tobias


  83. SamWhited


  84. Tobias

    I can't do that but happily read the mails

  85. dwd

    Tobias, Erm, Deprecated, surely, not Obsolete?

  86. Tobias

    so someone else would need to run it

  87. Tobias

    dwd, didn't we have the discussion once, whether to vote twice to Deprecate and then again to Obsolete it or to vote on directly Obsoleting it

  88. Tobias

    or am I misremembering things?

  89. daniel


  90. SamWhited

    I probably screwed up the terminology, I always mix them up. I could see it being either deprecated or obsolete.

  91. Link Mauve

    Tobias, we did, but dwd said deprecating in this discussion, not obsoleting.

  92. Link Mauve

    But we are totally ok with advancing twice in a same vote.

  93. Link Mauve

    I’m still -1 even to deprecating, it’s very much not a sensible direction imo.

  94. SamWhited

    Shall we just say deprecated since it should technically happen first and then we can discuss if obsoleting makes more sense next time?

  95. Tobias

    alright..then let's make it Deprecated

  96. Tobias

    i honestly don't care much as I can't see the difference between the two states

  97. Tobias

    6) AOB

  98. SamWhited

    yah, I doubt anyone makes much of a distinction

  99. daniel

    I think the people who voted +1 are happy with obsolete as well

  100. daniel

    And it wouldn't change the minds of the -1

  101. Tobias

    daniel, yeah...as there's no difference between the two states

  102. Link Mauve

    Ah right, an AOB, about the pending votes.

  103. Link Mauve

    Just a reminder.

  104. SamWhited

    I could go either way also, so we could just say that dwd gets to decide since he's the only unvoiced opinion?

  105. Tobias

    right, people please vote. Sam and I did today. Someone should takes those votes into trello and move things to editor column if all votes are in

  106. Tobias

    dwd, do you care much whether it's Deprecated or Obsolete?

  107. dwd

    I think I'd be more comfortable with Deprecated ("new implementations are no longer encouraged") as compared with Obsolete ("should no longer be [...] deployed").

  108. Tobias


  109. Tobias

    So with 3 (+1) votes and 2 (-1) votes, we decide to change the state of XEP-0071: XHTML-IM to Deprecated

  110. Tobias

    no other AOB? great

  111. SamWhited

    Sorry for the terminology confusion

  112. Tobias bangs the gavel

  113. Tobias

    thanks everybody

  114. Tobias

    jcbrand, thanks for writing the minutes

  115. SamWhited

    Thanks all; sorry for the big contentious topic, I knew that would divisive when I first sent a mail to the list about it.

  116. Kev

    FWIW, Final XEPs have to have a replacement before they can be Deprecated. I don't believe that's true of Draft.

  117. jcbrand

    You're welcome

  118. Kev

    And any -1 prevents a XEP from advancing.

  119. Kev


  120. SamWhited

    Kev: no, 0001 says that advancement requires a simple majority

  121. Tobias

    > A majority of Council members must vote +1 in order for a XEP to advance.

  122. Kev

    I think you're wrong.

  123. Kev

    Let me check.

  124. Kev

    Yes, the sentence before the one you quote "A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1"

  125. Link Mauve

    SamWhited, it also says it requires “rough consensus” on standards@, which it is far from imo.

  126. Kev

    It requires a majority to be +1, with no -1s.

  127. dwd

    Kev, I don't think Final has to be replaced to be Deprecated. It just says that if it is replaced, it'll become Deprecated.

  128. Kev

    dwd: I guess you could reasonably read it that way, yes.

  129. Tobias

    Kev, true

  130. SamWhited

    I am now even more confused about the process. In that case, what are the reasons for -1s? Just that there is no other formatting XEP? What would make those concerns "addressed"? Discussion started? A SIG started? An experimental XEP submitted? Or does something have to get all the way to Final?

  131. SamWhited


  132. Tobias

    SamWhited, no.for me it would be enough to have an alternative experimental XEP

  133. Tobias

    then we can say to people do that instead

  134. Link Mauve

    Yes, same for me.

  135. Link Mauve

    Something which could provide roughly as much interoperability as what we have currently.

  136. SamWhited

    So saying "don't do formatting in new implementations until something new is on the table" is not an acceptable recommendation for either of you?

  137. Link Mauve

    (So not BMH, for which it’s explicitly a non-goal.)

  138. Tobias

    i'll reply to the minutes that it's not actually deprecated

  139. Link Mauve

    SamWhited, implementations do want formatting, and saying there is no way to do any kind of formatting atm is misleading at best, and harmful in general.

  140. SamWhited

    I disagree

  141. Link Mauve

    I know. :)

  142. SamWhited

    But anyways, I'll start gathering use cases like I said in the beginning and we can keep this on the table. Although it sounds like it will be for the next council to finish again

  143. SamWhited

    Given that we're so close to the end of term

  144. Link Mauve

    Thanks SamWhited.

  145. Tobias

    jcbrand, will you cc standards too?

  146. Tobias

    jcbrand, ta

  147. jcbrand

    Tobias: I always do, however I need to send from different mail accounts since I'm subscribed with different accounts. Who could I ask to change the email address with which I'm subscribed to council@xmpp.org?

  148. Tobias

    Phew. Mailman admin?

  149. Tobias

    don't know who that is though

  150. Link Mauve

    I just reported my votes and Tobias’s on the trello.

  151. Tobias