XMPP Council - 2020-04-22

  1. jonas’

    1) Roll Call

  2. daniel


  3. Zash


  4. jonas’


  5. Ge0rG


  6. jonas’

    also, no TCP in multicast

  7. jonas’

    2) Agenda Bashing

  8. Ge0rG


  9. jonas’

    this one’s a long one, anything to modify?

  10. Ge0rG

    TL;DR, sorry :(

  11. jonas’

    3) Editor’s Update - Expired calls: None - Calls in progress: None - New ProtoXEP: Quick Response - New ProtoXEP: Best practices for password hashing and storage

  12. jonas’

    4) Items for voting

  13. Ge0rG

    looks good, but I haven't even catched up with previous on-lists

  14. jonas’

    s/catched/caught/ scnr

  15. jonas’

    4a) Proposed XMPP Extension: Best practices for password hashing and storage URL: https://xmpp.org/extensions/inbox/password-storage.html Abstract: This document outlines best practices for handling user passwords on the public Jabber network for both clients and servers.

  16. jonas’

    do you folks think this is a matter the XSF should handle?

  17. jonas’

    that’s my primary question with this one

  18. Zash

    As Dave says, it would fit with IETF / Kitten

  19. daniel

    someone said on list (was it the author?) that we can start this of with the xsf and if it gets replaced by something else that's fine

  20. daniel

    and i agree

  21. jonas’

    it doesn’t concern wire protocol, it concerns interop to some extent (but not beyond things applying to all things SASL)

  22. daniel

    so +1

  23. jonas’

    daniel, very good point, I like it

  24. Ge0rG

    I think that the XSF is not the right place for recommendations for "the public Jabber network", but other than that it's probably a good place for public-server recommendations

  25. jonas’

    I follow daniel with the +1

  26. Zash


  27. Ge0rG


  28. jonas’


  29. jonas’

    4b) Proposed XMPP Extension: Quick Response URL: https://xmpp.org/extensions/inbox/quick-response.html Abstract: Quickly respond to automated messages.

  30. jonas’

    let’s make this a quick response: +1

  31. jonas’

    let’s make this a quick response: I’m +1 on that

  32. Ge0rG

    That looks vaguely familiar.

  33. jonas’

    it does

  34. daniel


  35. Zash


  36. jonas’

    though I’d like to note (cc @ MattJ ) that I agree that actions and responses should maybe be merged on the wire layer, and a flag should indicate a switch between the "virtual keyboard" or "persistent actions" mode

  37. Zash

    Can it be fixed in Experimental?

  38. Syndace

    (spoiler: I don't think so, but I'd like to discuss details if/when it is accepted)

  39. jonas’

    anything is possible in Experimental

  40. jonas’

    Syndace, I’m not hard-sold on either way, if there’s a good rationale in the document which explains why a split is sensible, I’m fine with that

  41. MattJ

    FWIW I got hooked by Daniel's mention of spinners for actions, so... we'll see

  42. Syndace

    Yeah, I think the reasons will be a little clearer after I've incorporated the feedback I got in the past days.

  43. MattJ

    (this could be another optional flag for response type)

  44. jonas’

    Ge0rG, are you staying with your intent to vote on-list on this one?

  45. Kev

    Is there any merit in considering 'forms2' here?

  46. Ge0rG

    a quick +1 in the hope to catch up with the thread before it expires or bad things happen

  47. Ge0rG

    hi Kev

  48. jonas’

    Kev, I don’t think so

  49. Kev

    If people don't want to use forms because they're terrible, rather than solving a subproblem, using to to start work on a thing that isn't terrible?

  50. pep.

    Kev: after the protoxep has been accepted then :)

  51. pep.

    not blocking this one to reproduce what happened with reactions

  52. jonas’

    I think we need to stop over-engineering the simple things

  53. MattJ

    Kev, I've no objection to people working on forms2, but I have objection to delaying otherwise fine protocols because there is a dream of something better that might be finished in a couple of years

  54. Syndace

    The XEP might just end up specifying how to conveniently use forms to achieve what is done with different elements now.

  55. MattJ

    The use case doesn't call for forms at all

  56. jonas’

    the discussion about a potential '4 replacement should be taken to xsf@ please, we have a tight agenda today

  57. pep.

    (note that I'm not particularly in favour of quick response, I don't mind, I'm just bitter re reactions)

  58. jonas’

    4c) PR#935: XEP-0004: clarify that the submitting entity may omit optional fields URL: https://github.com/xsf/xeps/pull/935 Description: It is not really spelled out that the submitting entity may omit fields not mark as required by the processing entity. Even though the existence of the flag on form fields is a strong hint towards this, it is worth to explicitly state that.

  59. Ge0rG


  60. jonas’

    I don’t see how this could do harm. +1

  61. Zash


  62. MattJ

    Observation: nobody really knows what omitting a field does in different contexts

  63. daniel

    wait. what will be the value of those fields if you leave them out?

  64. Zash

    daniel, up to the processing thing?

  65. daniel

    and thats good?

  66. jonas’

    daniel, the "default"?

  67. MattJ

    MUC doesn't define this, for example

  68. Ge0rG

    the same as if you don't have the clarification in the XEP, I suppose

  69. daniel

    the default or the previous value?

  70. Zash

    defaults or previosu values depneding on if you're creating somethin new, or editing

  71. jonas’

    daniel, it doesn’t change the logic of the document.

  72. jonas’

    it was implicitly there already that fields which aren’t marked as <required/> can be omitted

  73. daniel

    mhh ok. +1

  74. Zash

    Tho I believe at least one implementation will reject forms if they're missing <fields>

  75. jonas’

    <required/> This element, which MUST be empty, flags the field as required in order for the form to be considered valid.

  76. jonas’

    taking the reverse of that, a field without <required/> does not need to be present

  77. Kev

    I don't think you can fix 4 without a certain amount of discomfort. It's underspecified in both the core and its uses, and trying to deal with it is a mess. This seems like low hanging fruit with relatively little pain, to me.

  78. jonas’

    Kev, is this about 4c, or still about Quick Responses / forms2?

  79. Kev

    jonas’: The PR.

  80. jonas’

    if the latter, please save it for after the meeting in xsf@. if the former, I don’t quite see how it’s connected.

  81. Kev

    MattJ observed that no-one knows what optional fields mean.

  82. jonas’

    the PR is just a clarification of something which is defined elsewhere, but not spelt out clearly; I don’t see how your comment is relevant, but I’m tired, so maybe that’s that.

  83. Kev

    I said that any improvement to '4 is going to have uncomfortable questions, but this one seems to be fairly painless, and helps.

  84. jonas’

    ah, yeah, that

  85. jonas’

    I agree

  86. jonas’

    thanks for clarifying

  87. MattJ

    I'm not council, but I'm in favour of the change under discussion. I just don't think it resolves anything in practice.

  88. jonas’

    MattJ, I agree with that, too.

  89. jonas’

    but I’m not going to stand in the way of making our documents more accessible by spelling things out in clear statements instead of having to reverse-logic something

  90. jonas’

    and with that, moving on

  91. jonas’

    4d) PR#926: XEP-0045: Clarify that the 307 status code should not be used alongside 333 for user disconnects URL: https://github.com/xsf/xeps/pull/926 Description: Per discussion in xsf@ about the UX implications of showing user disconnects as kicks.

  92. jonas’


  93. Zash


  94. daniel


  95. Ge0rG


  96. jonas’

    4e) Start Last Call on XEP-0320: Use of DTLS-SRTP in Jingle Sessions URL: https://xmpp.org/extensions/xep-0320.html Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key agreement for secure RTP in one-to-one media sessions.

  97. Kev

    4d) is 'recommended' the right word here, given confusion with SHOULD?

  98. daniel


  99. jonas’

    re 4e: +1, due to the recent influx of jingle things, I expect some feedback there actually

  100. jonas’

    Kev, thanks, I’ll let the editors know

  101. Ge0rG


  102. Zash


  103. jonas’

    4f) Start Last Call on XEP-0339: Source-Specific Media Attributes in Jingle URL: https://xmpp.org/extensions/xep-0339.html Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle

  104. jonas’

    again, +1

  105. Ge0rG


  106. Zash


  107. daniel


  108. jonas’

    Secret hidden agendum: 4g) PR#934: XEP-0167: add rtcp-mux element URL: https://github.com/xsf/xeps/pull/934 Description: RTCP-muxing is used in WebRTC. This element is actually used in the wild by clients like Siskin and Movim (and soon Conversations)

  109. jonas’


  110. daniel


  111. Zash


  112. jonas’

    nevermind, +1

  113. Ge0rG

    doesn't that affect backward compat?

  114. daniel

    it's an optional element

  115. daniel

    so probably not?

  116. jonas’

    in the same namespace though

  117. jonas’

    some ~people~ parsers are picky about that

  118. Zash

    MAY and addition should be mostly fine?

  119. Zash

    Unless you're doing ultra strict schema validation

  120. daniel

    well we can introduce the feature for it

  121. daniel

    see the comment

  122. daniel

    if that makes people feel better

  123. daniel

    but in practice i wouldn’t be worried about it

  124. daniel

    most implementations i saw send this

  125. daniel

    that's how i even learned about that field

  126. jonas’

    hm, writing down that a feature is to be announced -- even if in practice noone cares -- would be good for clarifty

  127. Ge0rG

    by sending it you tell the other party that you support it?

  128. jonas’

    hm, writing down that a feature is to be announced -- even if in practice noone cares -- would be good for clarity

  129. daniel

    apparently down to the original google jingle

  130. Zash

    Seems fine then

  131. jonas’

    but yeah, not going to insist on this

  132. Ge0rG

    +1 with the PR as-is

  133. Zash

    I wonder if we have a Jingle SIG we could solicit reviews from

  134. jonas’

    we have a few people involved with jingle, but I think at least one of them already commented on the PR

  135. Zash


  136. Ge0rG

    daniel: does the responder need to somehow acknowledge use of <rtcp-mux/> or is it implied by how the connection is established?

  137. daniel

    Ge0rG, they can or can’t put that into their counter offer

  138. jonas’

    that’ll negotiate nicely without any additional feature flags then

  139. jonas’

    if they don’t know it, they can simply ignore it

  140. Ge0rG


  141. jonas’

    5) Pending Votes

  142. jonas’

    everyone is pending on Room Activity Indicators according to my notes (but I haven’t checked the ML yet)

  143. jonas’

    anyone want to cast votes now?

  144. daniel

    not me

  145. jonas’

    we’re over time anyways

  146. jonas’

    and nothing expires

  147. jonas’

    so moving on

  148. jonas’

    6) Date of Next

  149. jonas’

    +1w wfm

  150. daniel

    +1w wfm

  151. Zash

    +1w wfm

  152. jonas’

    7) AOB Unless someone speaks up with an urgent AOB in the next 30s, I’m going to cut this.

  153. Ge0rG

    +1W WFM

  154. jonas’

    8) Ite Meeting Est

  155. daniel

    Thanks all

  156. jonas’

    Thanks everyone for managing this long agenda without any on-list vote.

  157. jonas’

    Thanks Tedd :)