XMPP Council - 2018-09-05


  1. peter set the topic to

    XMPP Council Room | https://xmpp.org/about/xmpp-standards-foundation#council | Room logs: http://logs.xmpp.org/council/ | https://trello.com/b/ww7zWMlI/xmpp-council-agenda

  2. Dave

    Afternoon. I'm less rubbish than last week (in as much as I'm here), but more rubbish than I should be because I havem't had a chance to do the agenda.

  3. Dave

    This is definitely on it though: https://xmpp.org/extensions/inbox/muc-avatars.html

  4. Dave

    So this would be the agenda, if I read correctly: https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0/edit#gid=0&range=B93

  5. Dave

    No, some (many) of these have been voted on.

  6. Dave

    Right, corrected, though I'll fill the votes in later for the ones that have been done.

  7. SamWhited crams before the meeting

  8. Dave

    Righty, 'tis time.

  9. Dave

    1) Roll Call

  10. Dave

    Who be here?

  11. Kev

    Here. Entirely unprepared, but here.

  12. Dave

    I'm pretty unprepared as well.

  13. SamWhited

    I am here, and have read at least one of the protoxeps

  14. SamWhited

    But also pretty unprepared

  15. Dave

    SamWhited, There's only one protoXEP, plus one PR.

  16. SamWhited

    Oh, I thought a second one came in. I have read the protoxep!

  17. Dave

    No Daniel or Georg?

  18. Dave

    2) Voting On Stuff

  19. Dave

    a) MUC Avatars https://xmpp.org/extensions/inbox/muc-avatars.html

  20. daniel

    Here

  21. daniel

    +1

  22. Kev

    I'll try to get this one on-list, but realistically I'm flat out until holiday and it might expire.

  23. Zash

    I heard Georg is on vacation

  24. Dave

    I'm +1 on this, though i would like to understand how it differs from the de-facto that it suggests exists.

  25. SamWhited

    I'd be curious to hear what others (especially client authors) think about this one. I tend to think it's unnecessary, because you can just do it all already as far as I can see and having a second XEP that says more or less the same as vcard-temp feels awkward to me.

  26. daniel

    Minus presence plus in Disco info

  27. Link Mauve

    Dave, I tried to explain that in both the introduction and section 5.2.

  28. Kev

    I'm +1, have just scanned it.

  29. daniel

    But I'm not entirely sure about the motivation

  30. Link Mauve

    SamWhited, I hesitated about making it just informational, still not too sure.

  31. Dave

    Link Mauve, Ah, I thought that was just about presence.

  32. Dave

    SamWhited, It's mostly usage and semantics rather than protocol, but it seems useful to document.

  33. SamWhited

    That might make a bit more sense, having a standards track XEP that rehashes a historical one and adds discovery just feels odd

  34. Link Mauve

    Dave, presence vs. disco#info is the only part where my proposal differs from the status quo.

  35. Dave

    Link Mauve, Gotcha.

  36. SamWhited

    "That" == "Informational"

  37. daniel

    But since servers will do that anyway now I don't think that this xep will retroactively fix that

  38. daniel

    I mean sorry that clients broke and all

  39. SamWhited

    Documenting things sounds find, but it feels poor to have multiple XEPs in various states documenting the same thing. Couldn't we equally just add a note to vcard-temp saying "remember, MUCs are JIDs too"

  40. Link Mauve

    At least Prosody will probably skip on the presence way.

  41. daniel

    But the demage is done

  42. daniel

    But we don't have to discuss this on council

  43. SamWhited

    Or a nod to vcard temp in 0045 even

  44. Dave

    SamWhited, Are you voting on this or thinking? (Georg is presumed to be on list anyway)

  45. daniel

    I'm +1 and then we can discuss on list once the xep is out

  46. SamWhited

    I'm thinking out loud, just curious to get others opinions. I guess I'm on list. I'm hesitant to publish this, but it seems fine protocol-wise.

  47. Dave

    Cool.

  48. Dave

    b) XEP-0060: Add an example on returning fewer items than requested https://github.com/xsf/xeps/pull/695

  49. daniel

    Also really if your client breaks if you get a presence from a bare jid. Wtf. Just fix your client

  50. daniel

    The neat thing about doing the presence hash thing is that it worked instantly w/o any changes

  51. Dave

    daniel, Feel free to argue this position on list. :-)

  52. Dave

    Anyone any votes for this PR?

  53. Dave

    I personally think it's straightforward, so +1.

  54. SamWhited

    +1 on the PR, though I'll leave an editorial note for the author, but it won't change the substance of it

  55. Kev

    I'm not sure why this is a thing. What's the backstory here?

  56. Dave

    Link Mauve, ?

  57. Dave

    Kev, FWIW, the XEP doesn't say what happens if a clientrequests N most recent when there are only M (M < N) items present. This is the obvious thing to do.

  58. Kev

    It being the obvious thing made me wonder why it needed to be a thing.

  59. Link Mauve

    Hmm, it was during the XMPP Sprint with MattJ, we IIRC encountered a case where Prosody was sending back an error instead of zero items.

  60. Link Mauve

    This makes sure servers behave correctly in this case.

  61. Kev

    Fair enough. No objections here.

  62. Dave

    Kev, Is that a 0 or a +1?

  63. daniel

    +1

  64. SamWhited

    Added some minor nits on wording; only the first one really needs to be fixed. The other is just me being picky and I don't think it actually matters, feel free to disregard.

  65. SamWhited

    (I'm +1 either way with my council hat on, nits are with my editor hat on)

  66. Kev

    0 because I don't have time to do the full review involved in +1ing it. The patch looks fine, but I don't think it's sufficiently diligent to approve just based on the diff - we know how that has worked in the past with complex XEPs like 50.

  67. Dave

    OK

  68. Dave

    3) AOB

  69. Kev

    Nowt.

  70. Dave

    4) Next Meeting

  71. Dave

    I saw you were saying you'll be away for a bit, Kev?

  72. Kev

    I'm out of action until October.

  73. Dave

    Anyone else going to be MIA?

  74. Kev

    (That'll be fully out of action, not on-list, unfortunately)

  75. Dave

    I have no idea how you'll survive.

  76. Dave

    I'll assume the rest of us will meet same time, same channel.

  77. SamWhited

    WFM

  78. Dave

    So absent anything else, thanks all, see you next week.

  79. Dave

    5) Ite, Meeting Est.

  80. Link Mauve

    Btw, there are still quite a few outstanding PRs at https://github.com/xsf/xeps/pulls which are tagged as Needs Council, could you add them all to next week’s agenda?

  81. Dave

    Link Mauve, I believe that those have had votes and expired. I'll see about tidying these up and ensuring they're documented etc.

  82. Link Mauve

    Ta.

  83. guus.der.kinderen

    Dave: #579 was voted on?

  84. guus.der.kinderen

    The h thingy on SM

  85. guus.der.kinderen

    It was in February, but was modified since.

  86. flow

    guus.der.kinderen, #579 appears to be conflicting with master (at least gh tells me so)

  87. flow

    guus.der.kinderen, I would suggest squashing into a single commit and rebaseing on the current master