XMPP Council - 2018-10-03

  1. Ge0rG

    It looks like this day of the week again, and I'm more gone than here.

  2. SamWhited

    I'm more gone than here, but I just started a cup of coffee so I should be here in the next 9 minutes

  3. Ge0rG

    SamWhited: your timing is awesome. I don't have coffee, so nothing is going to change with my situation.

  4. SamWhited

    For once, it's spot on

  5. Kev


  6. Kev


  7. daniel

    Here as well

  8. SamWhited


  9. Kev

    That's quorum, but not a Chair, maybe.

  10. Kev

    Let me dig out the agenda.

  11. Kev

    1) Roll call

  12. Kev

    Me, Daniel, Sam. Ge0rG more not here than here.

  13. Kev

    2) Agenda bashing.

  14. Kev


  15. Kev

    3) https://xmpp.org/extensions/inbox/bookmarks-conversion.html

  16. Kev

    I'm not sure about the implication in the intro that BM2 isn't widely adopted, but that PEP BMs are.

  17. Kev

    (But that's not a blocking comment, naturally)

  18. Ge0rG

    On list

  19. Zash

    I think there are 3 client implementations actually.

  20. daniel


  21. Kev

    I'll be inclined to go straight to BM2, rather than ever implementing BM/PEP in Swift.

  22. daniel

    Kev: I have so many issues with BM2...

  23. Kev

    But I'm not blocking the protoXEP.

  24. Kev


  25. daniel

    But that's probably a discussion for another day

  26. Kev

    daniel: I don't necessarily mean BM2 as-written, so that might be fair.

  27. SamWhited


  28. Kev

    4) LC on 359 (stanza IDs)

  29. Kev

    I see no harm in issuing LCs in general, so +1.

  30. SamWhited

    +1 for LC

  31. daniel


  32. Kev

    5) LC on 357 (push).

  33. Kev

    Again, I see no harm in an LC (even if I don't think it's ready for advancement)

  34. Kev


  35. daniel

    I don't think it will make it

  36. daniel

    But yeah we can issue it

  37. Ge0rG

    +1 for both LCs

  38. Kev

    The main reason not to is if we're convinced Council is going to -1 advancement, and we can save the Editor some work, I think.

  39. Kev

    I suspect, rather than am convinced, that that's the case.

  40. Kev


  41. Dave

    Hiya, sorry - things a little hectic. :-(

  42. SamWhited

    err, sorry +1 on LC for 357 too

  43. daniel

    I'm fairly convinced that push will be -1 after the lc

  44. daniel

    But still +1 for the lc

  45. Kev


  46. SamWhited

    If nothing else it will help flush out feedback from the community, which isn't necessarily bad

  47. Kev

    6) Date of next.

  48. Kev

    (Sam: Indeed)

  49. Kev


  50. SamWhited


  51. Kev

    7) AOB?

  52. Link Mauve

    AOB from the floor: what is still missing for the MUC avatars conversion ProtoXEP?

  53. Link Mauve

    AOB from the floor: what is still missing for the MUC avatars ProtoXEP?

  54. Kev

    I fear I missed that one while I was on my nearly-a-month holiday of bliss :)

  55. Kev

    (So I don't know)

  56. Kev

    Anyone else?

  57. Kev

    AFAICs, that had three +1s, and two on-lists a month ago.

  58. Kev

    So unless someone vetod on-list, it's ready to publish.

  59. Kev

    Let's see...

  60. Kev

    Ah, Sam vetod.

  61. SamWhited

    Do you have a link to that email? I'm struggling to find it

  62. Kev

    "Re: [Standards] XMPP Council Meeting 2018-09-05" if that helps.

  63. Kev

    It's the one in which you start by saying it's a great protoxep, and that you're vetoing it :)

  64. SamWhited

    Found it, thanks

  65. SamWhited

    ah yah, that's why, yup, I agree with myself still.

  66. Kev

    FWIW, I think delaying things that make life a little bit better with avatars, in the hope that some day everything gets sorted out, is probably not the best way here.

  67. Kev

    If people are doing this stuff anyway, interop is better than not, and provides a clear spec to deprecate later.

  68. Link Mauve

    That was my reason for not going full on PEP and postpone this even more.

  69. SamWhited

    I think it's as simple as mentioning that it can be done in one of the other avatar specs instead of completely re-hashing all of vcard-temp

  70. Kev

    I'd rather, I think, we could say at some point in the future "Here are all the ways people do it already. We're now deprecating them all in favour of the One True Ring" than "Here are some of the ways, we're deprecating those, but lots of people did other things and we can't say anything about those".

  71. Link Mauve

    SamWhited, so basically I should remove the examples, and only leave the disco and notification parts?

  72. SamWhited

    Link Mauve: I don't think it should be a separate XEP at all

  73. Dave

    I rather liked edhelas's suggestions for expanding this in such a way that it can do pubsub nodes and all sorts, personally.

  74. SamWhited

    Having 4 or 5 different avatar specs already, I don't think adding another reduces that confusion.

  75. Link Mauve

    You’d be in favour of adding discovery and MUC-specific notifications to e.g. XEP-0153?

  76. Link Mauve

    Dave, so moving discovery to another XEP-0128 dataform?

  77. Kev

    I think we've moved beyond Council discussion here and I'm inclined to close the meeting. Any objections?

  78. Link Mauve

    None from me.

  79. SamWhited

    Link Mauve: I'm not sure where the best place is; 0153 might be it. Or MUC itself.

  80. SamWhited

    Kev: oops, one more AOB

  81. SamWhited

    Is this a matter for council? https://github.com/xsf/xeps/pull/706

  82. SamWhited

    There was some confusion about this a few weeks ago, updating to the new language would have fixed it and we've been doing it this way anyways

  83. Kev

    I think that should be an agenda item, yes. For the next meeting.

  84. SamWhited

    WFM, thanks.

  85. Kev


  86. Kev

    Right, we're done then. Thanks all!