XMPP Council - 2022-08-03


  1. moparisthebest

    o/

  2. Zash is typing a reply to Flows question

  3. jonas’

    o/

  4. daniel

    Hi

  5. daniel

    It's time

  6. daniel

    1) roll call

  7. moparisthebest

    hello

  8. daniel

    do we have Ge0rG?

  9. daniel

    and larma?

  10. jonas’

    yes, next door

  11. jonas’

    (Ge0rG anyway)

  12. Ge0rG is there

  13. daniel

    2) Agenda bashing

  14. daniel

    nothing to bash I assume

  15. daniel

    3) Editors update

  16. daniel

    no updates this week

  17. daniel

    4) Items for voting

  18. daniel

    a) Move XEP-0215: External Service Discovery to stable

  19. jonas’

    I agree with Daniels/Zashes feedback

  20. moparisthebest

    if no one has once implemented push then maybe that bit should be removed first?

  21. Ge0rG

    I'd do a very long essay on why the format of the <service/> elements would be much better with a URI and how the registry is broken and there is no way for "service" vs "service-over-tls" etc, but generally +1

  22. daniel

    is my feedback only relevant for the next step though? meaning can it be removed later?

  23. daniel

    or do we need to remove it now before it becomes stable

  24. jonas’

    daniel, technically, removing non-STUN/TURN cases in Draft would likely require a namespace bump

  25. jonas’

    which we likely don't want

  26. Zash

    quoting myself from the future: > However, I don't believe strongly enough to argue for a namespace bump.

  27. daniel

    getting around the NS bump is a good argument

  28. daniel

    to fix it before stable

  29. moparisthebest

    if no one has ever implemented it I wouldn't bother with the namespace bump, but that might be skirting rules

  30. jonas’

    moparisthebest, that's ok for Experimental, not for Draft. In my book anyway.

  31. daniel

    > moparisthebest, that's ok for Experimental, not for Draft. In my book anyway. I agree

  32. Ge0rG

    I'm sorry but what exactly do you want to remove?

  33. daniel

    and yes somewhat related; I’m a bit on the fance wrt removing push to

  34. jonas’

    I propose that whoever shepherds this drops push and non-STUN/TURN cases, renames this to "external media relay discovery" or something and be done with it.

  35. daniel

    Ge0rG, the ability to do non turn services

  36. Zash

    I've implemented the push thing IIRC. Idea was to push STUN/TURN immediately on connect to Jitsi Meet, which needs that fast.

  37. Ge0rG

    daniel: so you want to remove the `type` attribute?

  38. jonas’

    Ge0rG, no, we need to keep that for stun vs turn

  39. Ge0rG

    so you want to remove the non-normative examples then?

  40. daniel

    the 'Extended information' will probably go away

  41. daniel

    and the examples

  42. daniel

    and maybe some wording changes and a title change

  43. daniel

    Zash fair enough on the push. I can see how that can be useful

  44. Ge0rG

    I suppose removing the 'Extended information' section would require a bump indeed.

  45. jonas’

    (in Draft)

  46. Ge0rG

    in Stable?

  47. jonas’

    Ge0rG, yes, that.

  48. jonas’

    ok, I don't have strong opinions on push, but I certainly can see the benefit of ripping out anything unrelated to STUN or TURN

  49. daniel

    ok. sounds good

  50. jonas’

    but I think we should run that by the list and poke the social media folks

  51. daniel

    -1 then

  52. jonas’

    I'm not sure if edhelas or so has used this to announce jingle components or such things

  53. moparisthebest

    so if we have X implementations, and none of them implement that, we can remove it and do no bump and not one has to change *or* we can remove it and do a bump and then *all* of them have to change? one seems obviously better to me...

  54. jonas’

    moparisthebest, your first line misses a "that we know of"

  55. jonas’

    we're a standards org, not a secret cabal

  56. moparisthebest

    if they don't monitor the mailing list and it isn't open source I literally don't care

  57. Ge0rG

    and there are many deployments of standard xmpp in closed setups

  58. jonas’

    daniel, I can write a mail to the list which summarizes the idea of dropping that and asking for anyone actively using anything except STUN/TURN

  59. daniel

    jonas’, sounds good. thank you

  60. daniel

    let's move on then

  61. daniel

    5) Pending votes

  62. daniel

    - Georg on Proposed XMPP Extension: Pubsub Attachments

  63. Ge0rG

    I'm still pending, sorry.

  64. daniel

    ok. no worries

  65. daniel

    6) Date of Next

  66. daniel

    +1w wfm

  67. Ge0rG

    +1W looks good so far

  68. moparisthebest

    +1w wfm

  69. daniel

    7) AOB

  70. moparisthebest

    none here

  71. jonas’

    here

  72. daniel

    jonas’, go ahead

  73. jonas’

    I have two weeks of vacation in the beginning of September and I intend to make this also a vacation from XMPP

  74. jonas’

    I'll likely hard drop out of all explicitly XMPP-related rooms/communication channels.

  75. jonas’

    (including my shell server)

  76. jonas’

    just as a heads up

  77. moparisthebest

    same for me, but end of september

  78. Ge0rG

    jonas’: have a great time! I'm also going to be on vacation, but in the middle of september, and I'll probably still check my xmpps

  79. jonas’

    (Sept 1 -- Sept 14, incl.)

  80. moparisthebest

    mine is sept 16-27, sounds like sept is a wash :P

  81. jonas’

    thanks, Ge0rG :-)

  82. jonas’

    End of my AOB

  83. larma

    I also have something

  84. daniel

    ok. noted. I guess that'll be a slow month then. I'll probably be gone for a week in september as well. haven’t really decided on when yet

  85. daniel

    larma, go ahead

  86. larma

    I was wondering how we want to continue the alterntive content / partial fallback discussion.

  87. jonas’

    I lack context, could you -v?

  88. larma

    As you might remember, I proposed a XEP for fallback bodies a while ago which we decided was not fit because there was another XEP with the same name (although mostly different functionality)

  89. jonas’

    oh, it's the time of the year again

  90. larma

    But also we had a large discussion about whether we want to allow partial fallback bodies (which effectively means having alternative content depending on the XEPs supported by the recipient device) and there was not outcome of that discussion really

  91. jonas’

    I get the impression that there are only terrible solutions available

  92. Ge0rG

    I agree with jonas’

  93. larma

    I created a PR to add the partial fallback body functionality of the proto xep into the existing XEP (https://github.com/xsf/xeps/pull/1188), but that obviously doesn't answer the question if that functionality is desired

  94. larma

    I can't say I'm a fan of alternative contents either, but to me it seems to be the only sensible way forward IF we want to support a heterogenous client landscape.

  95. jonas’

    larma, whether the functionality is desired is not somethign the council can answer, really

  96. jonas’

    that's for implementations to figure out

  97. jonas’

    that's for implementations, their project owners and users to figure out

  98. Ge0rG

    I think that ugly fallback bodies are the best way to motivate client developers to add support for new XEPs

  99. jonas’

    I don't disagree

  100. jonas’

    I also think that fallback bodies are the only sensible way to add features which otherwise may lose subtleties in communication

  101. larma

    Anyway, I don't want council to decide on this, I'd rather like to get an idea of how to proceed here. Because the decision if the aforementioned PR should be merged needs to be done somehow.

  102. daniel

    sorry i had to look up the voting history 'Compatibility fallbacks' and 428

  103. daniel

    sorry i had to look up the voting history of 'Compatibility fallbacks' and 428

  104. jonas’

    larma, that's under dwds control, really

  105. jonas’

    did you shoot him an email?

  106. daniel

    Ge0rG, voted compat fallbacks because he wanted that in 428.

  107. daniel

    i personally don’t care if it goes into 428 or a new xep; I’m also fine with the PR you created

  108. daniel

    but that's not really a council decision if it is merged. we could only do this by taking it away from dwd

  109. larma

    jonas’, I pinged him on GitHub, but I can also write another mail.

  110. jonas’

    larma, yeah, I suggest to try an email. I don't read many github notifications either, just too much noise.

  111. larma

    I also must say it's a bit weird for council to say "we're not going to accept the protoxep, because it needs to go into 428. And it's on dwd to decide if that happens" - because this puts a major ecosystem decision on dwd.

  112. jonas’

    ... yes

  113. daniel

    personally i'm a fan of new xep rather than 'taking it away'

  114. larma

    I guess I'll just have to write a mail to dwd and we'll follow up on this in one of the next council meetings.

  115. daniel

    we are running up on the time limit here

  116. jonas’

    larma, yes, that sounds like a good plan

  117. daniel

    ok. let's see if dwd actively blocks this or has become inactive first. and if either of those is the case we might want to ask Ge0rG to reconsider the decision to block the 'compat fallback' proto xep

  118. daniel

    no further AOB?

  119. jonas’

    none from me

  120. larma

    no

  121. daniel

    8) Close

  122. daniel

    thank you all

  123. jonas’

    thanks daniel

  124. larma

    Thanks daniel

  125. Ge0rG

    thanks!

  126. Zash

    Re xep-0215 push, the use case I mentioned would probably be better served by having it integrated with bind2 somehow, if that wasn't far in the future yet.

  127. daniel

    Thanks for the email Zash. That's much better reasoning than I used

  128. Zash

    Thanks

  129. Zash

    Can't remember anyone caring about ftp either :) Only thing I can think of is the idea to provide a proxy to help anonymise requests to HTTP upload-ed files, which could be communicated via '215.