XMPP Council - 2017-09-20


  1. Dave Cridland

    Are we meeting in a few minutes?

  2. Tobias

    i think so

  3. jonasw

    oh it’s wednesday

  4. daniel

    👍

  5. Tobias

    1) Roll call

  6. daniel

    here

  7. Tobias

    SamWhited, daniel, Dave Cridland, Link Mauve, ping

  8. SamWhited

    I am partially here and will be fully here in a few minutes

  9. Dave Cridland

    Tobias: ?

  10. Tobias

    Dave Cridland, wanted to know whether you are there, for the roll call

  11. Tobias

    appears so

  12. Tobias

    2) Minute Taker

  13. Tobias

    any volunteers?

  14. Link Mauve

    Hi, I’m here too.

  15. daniel

    i can do it

  16. Tobias

    jcbrand, or are you available for it?

  17. jcbrand

    Yes, I'm available

  18. jcbrand

    Tobias, daniel ^

  19. Tobias

    thanks

  20. Tobias

    3) Vote on accepting "Consistent Color Generation" as Experimental XEP

  21. Tobias

    I'll vote on list

  22. daniel

    +1

  23. SamWhited

    +1

  24. Tobias

    4) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP

  25. Tobias

    I'll vote on list

  26. SamWhited

    I wonder if that TODO at the bottom means it's going to be split into separate XEPs, or just separate sections in this XEP? If new XEPs are coming anyways do we want to bother accepting it?

  27. Link Mauve

    3) +1

  28. jonasw

    SamWhited, from my understanding on the mailing list, vanitasvitae said he’d add more XEPs specifying how to use the JET framework with OMEMO etc.

  29. Link Mauve

    4) I’ll vote on list.

  30. Link Mauve

    (I haven’t read it yet.)

  31. Link Mauve

    (The new version.)

  32. jonasw

    (but don’t take only my word for it)

  33. SamWhited

    I'll just be on list then and ask first

  34. daniel

    on list

  35. SamWhited

    or double check the discussion

  36. Tobias

    5) Discuss removal of Groupchat 1.0 protocol from XEP-0045 ( request by jonasw )

  37. jonasw

    I was only proxying that request

  38. jonasw

    the original request is from a discussion in the xsf@ MUC, I think dwd was present

  39. jonasw

    and maybe SAm

  40. jonasw

    but I can give some details if needed ( Ge0rG can too if he’s around)

  41. daniel

    jonasw: please do. I don't know what this is about

  42. jonasw

    okay, will do

  43. jonasw

    the origin of the discussion was that currently there’s no way for a client to know whether it’s still joined (think s2s errors and other state desync)

  44. jonasw

    (no reasonable way that is)

  45. jonasw

    then there was the suggestion to simply send presence to ensure that one is still joined

  46. jonasw

    the issue with that is that it could be interpreted as a Groupchat 1.0 join, which would not be desired

  47. jonasw

    from this originated the suggestion to remove that Groupchat 1.0 protocol entirely

  48. jonasw

    which would have the advantage that clients are safe against accidental Groupchat 1.0 joins when they desync

  49. Tobias

    ähm...but just removing it from the XEP without incrementing namespace or so won't allow clients and rooms to apply that logic, will it?

  50. jonasw

    that’s mostly it I think

  51. peter

    Are there still clients that support "groupchat 1.0"?

  52. jonasw

    the argument was that Groupchat 1.0 does *most likely* not exist anymore anyways

  53. SamWhited

    Personally, I'm fine breaking compatibility with any clients that still support groupchat 1.0.

  54. Tobias

    ahh

  55. Kev

    peter: Yes, implicitly.

  56. peter nods to Kev

  57. Kev

    Because the fact that a presence chengae will cause a rejoin after an S2S blip is remarkably useful

  58. daniel

    groupchat 1.0 join is a presence without the <x/>?

  59. jonasw

    daniel, exactly

  60. Kev

    If you removed that, suddenly lots of people wouldn't be in MUCs when they thought they were.

  61. jonasw

    Kev, is it? I think it’s not useful

  62. jonasw

    you’d want to specify the needed history instead

  63. Kev

    Anyway, this is a hack.

  64. Kev

    If you want to change xep45 to allow you to know if you're in the room, add an iq to that effect.

  65. jonasw

    getting a proper error back and then making a proper join with history etc. sounds more reasonable

  66. jonasw

    Kev, that was also discussed, but is a separate topic

  67. Kev

    Removing legacy joins is very much the wrong option here, I think.

  68. Tobias

    alright..do we want to continue that discussion on standard ML?

  69. SamWhited

    That sounds sensible.

  70. Kev

    That'd be the appropriate place, I think.

  71. Tobias

    alright

  72. jonasw

    good idea

  73. peter

    FWIW I agree with Kev.

  74. Tobias

    6) Consider advancing XEP-0387: XMPP Compliance Suites 2017 to Draft (added by SamWhited )

  75. Tobias

    Sounds sensible to me, i think we should issue a LC if other draft requirements are met

  76. daniel

    not sure if this is a blocker but the xmpp compliance suite requires the bookmark xep which can't be implemented right now

  77. SamWhited

    I would like to start having compliance suites created and advanced by the beginning of the year (eg. 2018 suites would be created and a recommendation by January 1, 2018). I think a sensible place to start trying to do that would be to make sure the 2017 ones are advanced

  78. SamWhited

    daniel: bookmark can't be implemented?

  79. daniel

    because it depends on pep functionality that doesn't exist

  80. daniel

    and which people don't want to have in pep

  81. daniel

    but it's fine with me if we start a last call on xep387

  82. daniel

    i can bring this up in the last call

  83. Link Mauve

    daniel, it could depend on the previous version, which was using 0049.

  84. Link Mauve

    Which is AFAIK how every client implements it.

  85. SamWhited

    Sounds good; thanks. I think using pubsub at all for bookmarks is RECOMMENDED, so I'm not sure if it's a problem. We can discuss on list.

  86. Ge0rG

    Can we get MIX out of 387, then?

  87. Tobias

    sound sensible then

  88. Tobias

    so we're all in favour of issuing a LC?

  89. SamWhited

    MIX has been out of it for a long time (and I still think that was a bad decision, but I did it)

  90. Link Mauve

    SamWhited, also, why are the compliance suites standards tracks, instead of informational?

  91. Ge0rG

    SamWhited: ah, thanks. Didn't get that update.

  92. SamWhited

    Link Mauve: I'm not sure, they include 2119 language?

  93. Link Mauve

    Hmm…

  94. SamWhited

    Anyways, +0 for LC (seeing as I'm the author) and we can discuss other things on list unless anyone sees a reason to block that really needs to be discussed now

  95. Tobias

    alright

  96. Tobias

    7) Issue a new LC for XEP-0352: Client State Indication , based on https://github.com/xsf/xeps/pull/427

  97. Tobias

    any objections to this?

  98. SamWhited

    +1 for LC

  99. Link Mauve

    +1

  100. Tobias

    i'm also +1

  101. daniel

    +1

  102. Tobias

    alright. Let's come to an end as we're already exceeding half an hour.

  103. Tobias

    8) Date of next

  104. Tobias

    Same time next week?

  105. daniel

    wfm

  106. Link Mauve

    I won’t be here next week, I’m on vacations.

  107. Tobias

    wfm

  108. SamWhited

    wfm

  109. Tobias

    Link Mauve, happy to vote on list?

  110. Link Mauve

    Sure. :)

  111. Tobias

    alright

  112. Tobias

    9) AOB

  113. SamWhited

    None from me

  114. Tobias

    great

  115. Tobias bangs the gavel

  116. Tobias

    thanks everybody

  117. SamWhited

    Good stuff; thanks all!

  118. Ge0rG

    Thanks council, I'll prepare a longer message regarding GC1 removal and self-pinging.

  119. jcbrand

    Tobias: Concerning the compliance suite, is it now going directly into Draft or first a LC?

  120. Tobias

    first LC

  121. SamWhited

    jcbrand: LC

  122. jcbrand

    thanks