XMPP Council - 2024-05-21


  1. dan.caseley

    Apologies in advance for today's meeting. I'm stuck in a work thing that I'm not able to escape, and won't make it.

  2. daniel

    Hi

  3. daniel

    It’s time

  4. daniel

    1) Roll call

  5. larma

    👋️

  6. moparisthebest

    Hello!

  7. daniel

    singpolyma, are you around?

  8. moparisthebest

    (every week I type "hello" on my phone keyboard and it autocorrects it to "help" ... So one week when I send that don't worry 🤣)

  9. daniel

    2) Agenda bashing

  10. daniel

    sorry for the late agenda. I assume there is nothing to bash?

  11. daniel

    3) Editors update

  12. daniel

    * Proposed XMPP Extension: Jingle Remote Control

  13. daniel

    4) Items for voting

  14. daniel

    a) Move 'XEP-0440: SASL Channel-Binding Type Capability' to stable https://xmpp.org/extensions/xep-0440.html if that one fails we need additional votes on what else to do with that

  15. moparisthebest

    -1 for move to stable, I still need to consolidate my comments from this MUC last week into an email...

  16. daniel

    personally I‘m +1. It fills a gap (a way to announce channel binding types)

  17. daniel

    that doesn’t mean that some channel bindings are not better then others

  18. moparisthebest

    I'm not convinced we need a way to announce them at all, there's only 1 that should be used

  19. moparisthebest

    But if we do, then I'm not convinced this is the place to do it And if it is, it's missing a ton of absolutely vital Security considerations

  20. larma

    I don't think we'll be able to move forward if we say there's only one thing that should be done, but then status quo is barely anyone is even doing that.

  21. moparisthebest

    I'm not ready to say this needs moved to deprecated, but it at minimum needs work before moving to stable, imho

  22. daniel

    i agree that the security considerations need improving. not sure if "by a ton". but changes in the security considerations won’t change the protocol

  23. singpolyma

    Hu

  24. larma

    I am wondering if we actually need to vote right now? As fas as I can tell, there has been changes suggested and the author agreed to incorporate them, so before voting we should wait for this to happen, no?

  25. singpolyma

    I'm +1 but also what larma said

  26. daniel

    larma, I think we do yes

  27. daniel

    but we can vote on moving it back to experimental

  28. larma

    > Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author or Document Shepherd, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote.

  29. daniel

    because it is in Last Call and one way or another it needs to be moved out of that

  30. larma

    The addressing didn't happen yet, so Editor is not supposed to propose a specific revision to Council

  31. larma

    also 14 days of last call is the minimum, it *can* last forever

  32. larma

    but it defeats the purpose to have it last forever 😉

  33. moparisthebest

    I thought we moved it back to experimental and then back to last call after the changes?

  34. moparisthebest

    I have no strong opinions on that though

  35. daniel

    I think 14 day is the minimum but once it's decided last call ends and we need to make a decision

  36. daniel

    anyway it has been rejected

  37. daniel

    and we can just vote on moving it back

  38. larma

    I would at least give author the chance to incorporate feedback from last call

  39. daniel

    Move XEP-0440 back to experimental

  40. daniel

    +1

  41. larma

    as last call only ended yesterday, they had no chance to incorporate all feedback

  42. moparisthebest

    +1 move back to experimental (Unless we want to just extend last call and then I can retract my -1 or we pretend no vote happened or whatever)

  43. larma

    Fine either way, but want to express that it makes no sense to move back to experimental if author does not intent to incorporate changes that are considered required by council

  44. Kev

    FWIW, I don't *think* that the vote has to happen when the LC ends.

  45. Kev

    FWIW, I don't *think* that the vote has to happen at the same moment as the LC ends.

  46. singpolyma

    > +1 move back to experimental > > (Unless we want to just extend last call and then I can retract my -1 or we pretend no vote happened or whatever) Same

  47. singpolyma

    > +1 move back to experimental > > (Unless we want to just extend last call and then I can retract my -1 or we pretend no vote happened or whatever) Same

  48. daniel

    ok. so you just want to leave it in Last Call?

  49. larma

    I read XEP-0001 clearly that we should wait for all issues raised during LC addressed before voting, which didn't happen yet.

  50. larma

    In Proposed, LC is over

  51. larma

    > If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

  52. larma

    So if Editor feels like extending LC, that's also an option

  53. larma

    So maybe we just agree on extending LC by 2 weeks to give flow the opportunity to address feedback?

  54. moparisthebest

    Luckily we have the editor right here

  55. larma

    So maybe we just agree on extending LC by 2 weeks to give moparisthebest the chance to write a new email and flow the opportunity to address the feedback?

  56. daniel

    personally I would rather have it back in experimental as it feels like there is more substantial work needed to satisfy council especially moparisthebest then can reasonably achieved in 2 weeks

  57. larma

    OK, then let's go with this

  58. daniel

    but i don’t know. I guess I can extend it by 2 weeks and we see what happens then

  59. larma

    so -1 on advancing and +1 on moving back to Experimental from my end

  60. larma

    so I'm -1 on advancing and +1 on moving back to Experimental from my end

  61. larma

    so I'm -1 on advancing and +1 on moving back to Experimental

  62. singpolyma

    I am +1 on any of advancing, extending lc, or back to experimental

  63. daniel

    fwiw since dan.caseley isn’t here it will more or less automatically stay in last call until we get that vote

  64. daniel

    ok. moving on

  65. daniel

    b) Proposed XMPP Extension: Jingle Remote Control https://xmpp.org/extensions/inbox/remote-control.html

  66. singpolyma

    -1

  67. singpolyma

    It does have an implementation which is nice, but it feels essentially off topic for xsf

  68. moparisthebest

    on-list, I have questions

  69. larma

    I love to see the feature, but I also agree I very much dislike the way it was realized. As I wrote on list, I would prefer either using any existing well-specified protocol or if that's not an option (and well-reasoned) and it needs to be defined inside a XEP at least use XMPP tech, which would be more like some <message> via Jingle XML streams instead of a stream of CBOR

  70. MattJ

    From the floor, I think the bar should be high for "off topic for the XSF"

  71. MattJ

    I see the XSF as a place where people who want to use XMPP to do X, Y or Z can find a standard way to do it

  72. MattJ

    Even if X, Y or Z is something niche

  73. singpolyma

    MattJ: sure, but this is essentially a spec for a binary remote control protocol disguised as a xep

  74. MattJ

    If there are issues with the protocol, then fair enough (I haven't read the spec), but that sounds like an objection more than just "off topic"

  75. daniel

    I’m +1

  76. daniel

    do you want to vote larma ?

  77. singpolyma

    I primarily object to defining such a protocol in a xep at all. A xep like this referencing some existing protocol (even this one specified elsewhere) would be more palatable

  78. singpolyma

    Or as larma said if it was defieining an xmpp way to do it (eg usieg message)

  79. singpolyma

    Or as larma said if it was defieining an xmpp way to do it (eg using message)

  80. larma

    MattJ, the protocol is generally fine, it just doesn't feel like it has anything to do with XMPP (only talking about the payload content protocol, not the signalling)

  81. moparisthebest

    I think the last messages from singpolyma & larma say the same thing and I agree

  82. larma

    MattJ, the protocol is generally fine, it just doesn't feel like it has anything to do with XMPP (the payload content protocol, sections 8 and 9, not the signalling)

  83. MattJ

    👍

  84. Link Mauve

    From the floor as well, this protocol doesn’t seem to map well to current protocols like Wayland or XInput2.

  85. larma

    Link Mauve, thanks for this input. It's exactly one of those things why I feel we should, if possible, not specify this within the XSF, because I wouldn't know this, but I'm supposed to vote on it

  86. Link Mauve

    (I had a look at this ProtoXEP when it got published, in order to implement it in Inkscape to improve my collaborative editing plugin.)

  87. singpolyma

    I love the feature as an idea and I love that an implementation exists. But i don't think those are enough in this case

  88. daniel

    larma, can I take that as a -1 (just for the record)

  89. larma

    I would vote -1 for the current version, but want to encourage goffi to continue working on this (and seek input from people knowledgable in the field)

  90. larma

    Link Mauve, do you happen to know if there is a popular remote input protocol already?

  91. daniel

    ok. moving on

  92. daniel

    5) Pending votes

  93. daniel

    none

  94. daniel

    6) Date of Next

  95. daniel

    +1w wfm

  96. larma

    +1w wfm

  97. singpolyma

    +1w wfk

  98. singpolyma

    +1w wfm

  99. moparisthebest

    +1w wfm

  100. daniel

    7) AOB

  101. Link Mauve

    larma, X11 has multiple of those, RDP and VNC are popular cross-platform ones in that field but I don’t know anything about the protocols themselves (only as a user of both), there is also waypipe which is a network-serialized Wayland.

  102. moparisthebest

    No aob here

  103. singpolyma

    Link Mauve: those are both full remote desktop. But probably if you run them without video they are basically remote input?

  104. moparisthebest

    Am I crazy or didn't someone add remote control screen share to Conversations after it first added video in a few lines of code? Which leads me to believe this is already in webrtc ?

  105. Link Mauve

    singpolyma, input is very often correlated with video, both need to use the same coordinate system(s) for instance.

  106. daniel

    8) Close

  107. daniel

    thank you all. see you next week

  108. singpolyma

    AIUI one of the goals here is headless remote input such as using a tablet as a mouse for the computer right in front of you

  109. moparisthebest

    Thanks daniel !

  110. Link Mauve

    singpolyma, graphic tablets are a thing this protocol doesn’t support at all currently.

  111. Link Mauve

    (The kind artistic people use.)

  112. larma

    moparisthebest, this might be for screen share, but without remote control

  113. singpolyma

    moparisthebest: webrtc doesn't "have" anything, it's just another name for jingle aka a dumb pipe with some metadata

  114. Link Mauve

    In Wayland for instance we use this protocol for such devices, and it needs to expose all of that complexity to describe the features supported by the hardware: https://wayland.app/protocols/tablet-v2

  115. moparisthebest

    > moparisthebest, this might be for screen share, but without remote control Aaaahhhhh probably correct

  116. moparisthebest

    > moparisthebest: webrtc doesn't "have" anything, it's just another name for jingle aka a dumb pipe with some metadata singpolyma: right but isn't there an existing problem you've ran to in XMPP that RTC or whatever has an existing standard way to do DTMF but we also have an XML/XMPP way for some reason?

  117. larma

    That's RTP

  118. larma

    which predates WebRTC by approximately 2 decades

  119. larma

    Just like XMPP 😉

  120. MattJ

    https://xmpp.org/extensions/xep-0181.html

  121. MattJ

    <dtmf xmlns='urn:xmpp:jingle:dtmf:0' code='7' duration='400' volume='42'/>

  122. larma

    The XMPP way of encoding DTMF is way better than the RTP way though

  123. daniel

    personally I see 'Experimental' as a base for people to work on stuff with a very low barrier to entry. I've voted +1 on XEPs in the past were I had very strong "I would have done that differently" vibes. but I also believe in good idea will prevail. maybe i'm wrong. maybe the xep author is wrong. but it doesn’t hurt to give it a number. when I read that XEP I obviously also thought "why don’t you just use VNC or spice or whatever". on the other hand if you already have screen share (which webrtc browser implementations give you for free) I also understand the idea of just wanting to do the incremental change of just adding key events instead of migrating to a dedicated protocol

  124. MattJ

    I haven't seen the RTP encoding, but I guess that having it in the same stream as the audio has some benefit

  125. larma

    It's not the same stream, but it has the advantage of being able to sync to it via RTP

  126. daniel

    (obviously much higher barriers should and do apply to moving something to stable)

  127. daniel

    on the other hand I sometimes wish XEP authors would ask other community members for early feedback before going through the troubles of writing down a full xep (not sure if this has or hasn’t happened in this case)

  128. larma

    daniel, I generally agree and I want to allow most things in XMPP as well, but I feel the XSF is just not the venue for this protocol (or specific parts of it)

  129. larma

    daniel, I generally agree and I want to allow most things in a XEP as well, but I feel the XSF is just not the venue for this protocol (or specific parts of it)

  130. larma

    MattJ, the RTP dtmf can't encode pressing a button for more than 8 seconds (it's a 16 bit number of clocks with a clockrate of 8000 Hz)

  131. flow

    "daniel> personally I see 'Experimental' as a base for people to work on stuff with a very low barrier to entry", that's how it was done most of the time since I am involved. that said, the drawback is that it gives the impression of significance and endorsement to XEPs that shouldn't have it. For example, "*the* XMPP IoT" XEPs, are, by no means the official way to do IoT with XMPP, but a person unfamiliar with the process may get this impression

  132. flow

    hence I am in favor of a numberless pre-experimental state

  133. daniel

    i mean the obvious alternative is that protocols live in gists on github. for example https://gist.github.com/iNPUTmice/aa4fc0aeea6ce5fb0e0fe04baca842cd

  134. flow

    then we could also probably raise the bar for experimental a bit (if we want)

  135. daniel

    not sure if that's better or worse

  136. flow

    daniel, that is only one possible alternative. I would like the XSF to host those pre-experimental XEPs so that they are not distributed around different places and easily visible

  137. flow

    daniel, that is only one possible alternative. I would like the XSF to host those pre-experimental XEPs so that they are not distributed around different places and easily discoverable

  138. daniel

    to me the solution is being better with moving things to stable (and letting Experimental be experimental)

  139. Zash

    Yeah, pre-experimental is what Experimental should be

  140. daniel

    instead of introducing a new state (and then possibly doing a bad job at advancing stuff from numberless to number)

  141. flow

    unfortunately, this doesn't solve the issue I described :/

  142. flow

    and, if experimental should be experimental, then the entry bar should be pretty low IMHO

  143. flow

    I think the IETF nailed it when they created a now-barrier entry process with I-Ds

  144. daniel

    there is a lot of tooling behind that that we don’t have

  145. daniel

    and the process to actually get a rfc number is much more complicated then I would like it to be for the xsf

  146. flow

    while we may have something similar with ProtoXEPs, we do not actively promote it. a submission to the xeps repo is usually always also asking council for adoption to experimental. Or did we accept a ProtoXEP into the xeps repo without submitting it to concil in the last decade?

  147. daniel

    yeah plus there is no proper namespacing and versioning in protoxep

  148. flow

    well namespacing is possible, you can request a reservation from the xsf registrar

  149. flow

    or maybe I don't get what you mean by "proper namespacing"?

  150. larma

    you mean, we need the tooling

  151. daniel

    i mean in the file namenames

  152. flow

    well that is simply a matter of policy

  153. flow

    I also don't think that we need much tooling to reflect the process

  154. flow

    in fact, for ProtoXEPs that aren't send to council right away we simply have to ensure that once the protoxep is in the xeps.repo, it also appears rendered on xmpp.org

  155. flow

    and I think this is already the case

  156. flow

    (or when not, could be easily done)

  157. larma

    it already is, it's in the inbox

  158. flow

    sure, but inbox allready suggests that it's the council's inbox :)

  159. flow

    anyhow, we could keep that place the inbox/ or create a new directory protoxeps/. that's mostly a matter of taste

  160. flow

    I do would propose that those protoxeps are versioned and immutable, but that is also probably a matter of taste

  161. flow

    I would propose that those protoxeps are versioned and immutable, but that is also probably a matter of taste

  162. singpolyma

    >> moparisthebest: webrtc doesn't "have" anything, it's just another name for jingle aka a dumb pipe with some metadata > singpolyma: right but isn't there an existing problem you've ran to in XMPP that RTC or whatever has an existing standard way to do DTMF but we also have an XML/XMPP way for some reason? Yeah the dtmf xep is a great example of one we need to actually get rid of

  163. singpolyma

    > I haven't seen the RTP encoding, but I guess that having it in the same stream as the audio has some benefit Indeed. The dtmf xep even tells you to use rtp dtmf if you're using rtp for anything esle. It's quite unclear if there is *any* case where the xep is useful

  164. Link Mauve

    singpolyma, your client’s use of <b/> for emphasis isn’t allowed in XEP-0071 fyi, I think you meant <strong/>.

  165. singpolyma

    Link Mauve: where?

  166. Link Mauve

    In the previous message you sent in this room.

  167. singpolyma

    oh, did it send html on that? I didn't think I had enabled that yet

  168. Link Mauve

    “Indeed. The dtmf xep even tells you to use rtp dtmf if you&apos;re using rtp for anything esle. It&apos;s quite unclear if there is <span style="color:#483600;">*</span><b>any</b><span style="color:#483600;">*</span> case where the xep is useful </body></html>”

  169. Link Mauve

    You did yes.

  170. singpolyma

    cool. I should check into that code a bit heh

  171. singpolyma

    I'm nor worried about XEP-0071's opinion of what tags to use though

  172. Link Mauve

    poezio at least doesn’t do anything with that tag.

  173. Link Mauve

    It does with <strong/>, or with <span style='font-weight: bold'/> though.