XMPP Council - 2021-02-10

  1. Ge0rG

    It looks like I'll be late and/or distracted

  2. jonas’


  3. jonas’


  4. dwd

    "I know this because there's a thread on a mailing list complaining about this." - catch-all for any subject (and more or less any mailing list, but certainly IETF Discuss)

  5. jonas’

    1) Roll Call

  6. daniel


  7. Zash


  8. jonas’

    I am, too

  9. jonas’

    I heard dwds textvoice just now and Ge0rG sent apologies, so I assume we can go on

  10. jonas’

    2) Agenda Bashing

  11. jonas’


  12. Zash


  13. jonas’

    3) Editor’s Update

  14. dwd

    (I am here, just finishing a call about an entertaining security issue we uncovered)

  15. jonas’

    - New XEPs: - XEP-0455: Service Outage Status

  16. jonas’

    dwd, that sounds very entertaining

  17. jonas’

    4) Items for voting None.

  18. jonas’

    5) Pending Votes

  19. jonas’

    The data forms PR is lacking discussion / voting.

  20. jonas’

    I apologize, the weekend was… interesting to say the least. I didn’t get around to start a thread. I might tonight or reply to the minutes.

  21. Zash


  22. jonas’

    Does anyone want to cast votes on that or the Web Socket Endpoints protoxep in the meantime?

  23. dwd

    I hope interesting in a good sense, but i'm sensing that's wishful thinking.

  24. jonas’

    it is indeed

  25. dwd

    Yeah, I'm going to veto the websockets endpoint one as noted on the mailing list.

  26. dwd

    And also on the assumption that a different proposal around this will emerge.

  27. daniel

    I’m glad dwd is doing the vetoing so i don’t have to

  28. dwd

    (So a veto without prejudice, as it were).

  29. daniel

    but i agree that a new xep is the better aproach

  30. jonas’

    dwd, can you state your rationale here for the record please?

  31. dwd

    daniel, You still should, in case I withdraw or you have other interesting reasons to veto.

  32. dwd

    jonas’, I stated them on list for the record, but loosely it implies a server default of listening on unencrypted sessions, and devalues XEP-0156.

  33. dwd

    jonas’, I am expecting something closer to a "suggested defaults" with both test and production recommendations.

  34. jonas’

    dwd, yep, I assumed it was on-list, but me (or Tedd) digging into the thread to find it is suboptimal :)

  35. jonas’

    sounds good to me

  36. jonas’

    there is this proposal: https://github.com/xsf/xeps/pull/1035/files

  37. daniel

    -1: Having a XEP that defines recommendation for default ports and paths is interesting but the proto xep goes well beyond that and tries to influence client behaviour which might lead to the degradation of doing things properly ake 156

  38. daniel

    essentially everything we discussed last week

  39. jonas’

    -1: Let’s not repeat the mistake of the A/AAAA fallback here when there’s no evidence that it’s needed for practical interoperability concerns.

  40. daniel

    plus a agree with dwd in that haevily editing the current proto xep over starting fresh is not the best path

  41. Kev

    (FWIW, I’m not convinced the A/AAAA fallback was a mistake at the time)

  42. daniel

    especially once it's out there it's out there. and any edits might take time

  43. dwd

    I can see defaults are really interesting from an ease-of-test and ease-of-deplyment case, and recommendations for production deployment are great too. But that seems a rather fundamentally different XEP than the one we have now.

  44. jonas’

    .well-known requires some IANA interaction, right?

  45. Zash

    Sorry, I'm inexplicably tired all day and having trouble following. What are we voting on?

  46. Kev

    dwd: Why are recommendations for a production deployment great? If a client is doing lookups, isn’t it entirely deployment’s choice, and so one recommendation can’t be better than another?

  47. daniel

    which doesn’t have to be a bad thing, re iana

  48. dwd

    Zash, Websocket ProtoXEP missing votes.

  49. jonas’

    Zash, we’re currently discussing the websockets protoxep

  50. dwd

    Kev, For example, suggesting that websockets run on port 443 over TLS is useful advice.

  51. dwd

    Kev, And materially better than port 5280 without TLS.

  52. jonas’

    (that would be Informational, and not Standards Track, though)

  53. dwd

    jonas’, Indeed.

  54. Zash

    Informational thing that suggests defaults sounds fine

  55. jonas’


  56. daniel


  57. Kev

    dwd: TLS is absolutely good advice. I’m not sure if 443 is, but I can at least see an argument for it. Any other port would be a bad thing to recommend though, I think.

  58. jonas’

    is anyone from the present people interested in taking on the work to do it?

  59. dwd

    Oh, gosh, no. I was assuming either of flow or Sonny would take that on.

  60. Kev

    But yes, a XEP saying “Look, always do TLS. And 443 might be a good choice” seems much less likely to be harmful than some other things might be.

  61. Zash

    Aren't there RFCs saying that (always TLS!!!) already?

  62. jonas’

    sonny looked interested in moving this towards a default recommendation

  63. Zash

    So. I can vote -1, fallbacks bad, tls good, what everyone else said, try again to the previous proposal.

  64. jonas’

    then we’ve got all votes collected

  65. jonas’

    I assume we’re going to discuss the data forms thing on-list then?

  66. daniel

    i don’t see how this would not require a namespace bump

  67. Zash

    Bumping dataforms? Oh glob

  68. dwd

    The data forms thing? Seemed OK to me, mind.

  69. jonas’

    yes, and kill <reported/> while we’re at it

  70. jonas’

    win-win :D

  71. daniel

    i mean we've been pretty liberal with the word clarifying in the past…

  72. jonas’

    to the point that I’d like to ban that word from xeps PRs

  73. Zash


  74. dwd

    Well, either people *do* care about the order or they don't. A way to "fix" the issue would be to say SHOULD send in order, MUST accept in any order.

  75. jonas’

    I could live with that

  76. daniel


  77. dwd

    But yeah, this needs a list discussion.

  78. jonas’

    ok, let’s move it there then

  79. jonas’

    6) Date of Next

  80. jonas’

    +1w wfm

  81. daniel

    but if you must accept it in any order why send it in one?

  82. daniel

    +1w wfm

  83. Zash

    +1w wfm

  84. jonas’

    dwd still checking his schedule I presume?

  85. jonas’

    … anyway, three’s a quorum

  86. jonas’

    7) AOB

  87. jonas’

    has anyone got any?

  88. jonas’ talking to his echo

  89. jonas’

    assuming none

  90. Zash

    I've got nothing.

  91. jonas’

    8) Ite Meeting Est

  92. jonas’

    Thanks Tedd for the Minutes :)

  93. jonas’

    (they arrived just now and I’ll reply re data forms)

  94. daniel

    thanks all

  95. Zash

    Thanks Tedd, jonas’, all.

  96. jonas’

    FTR, replied to the minutes thread re data forms