XSF Discussion - 2020-07-15

  1. emus

    Hello everyone, it's not just mid-week but also mid-month! If you have news of your projects or projects of interest please don't forget to bring it over to the XMPP Newsletter we draft here: https://github.com/xsf/xmpp.org/pull/730 Questions & help welcome!

  2. eta . o O ( maybe we should copy the Matrix folks and have TWIX: This Week In XMPP )

  3. Daniel


  4. !XSF_Martin


  5. Daniel

    oh riot is now element

  6. Daniel

    that's easier to google…

  7. goffi

    they've also got a huge contract with German education apparently, I don't know if XMPP was on the table, but if it was not there is something going wrong.

  8. Daniel

    well there is nobody who could have put it on their table

  9. goffi

    I have no idea how this kind of things are negociated and who brings project proposition. Is it not supposed to be a call for bids or something like that?

  10. Daniel

    i guess. but 'XMPP' is not an entity that could put in a bid for something like that

  11. Daniel

    and as an individual freelancer you pratically (and probably rightfully) have no chance at winning that

  12. eta

    yeah, what they're selling is their hosting service

  13. eta

    apart from isode maybe nobody in the XMPPverse is really doing that

  14. goffi


  15. Daniel

    they don’t have clients

  16. Daniel

    if you are buying this for the use in schools you want a solution and not building blocks

  17. goffi

    alright, makes sense.

  18. eta

    evil plan, write a matrix c2s to XMPP translation layer, then undercut element because server hosting won't be as resource intensive

  19. emus

    > eta . o O ( maybe we should copy the Matrix folks and have TWIX: This Week In XMPP ) I dont unterstand what you wanna say?

  20. eta

    emus: don't worry, I'm just joking

  21. eta

    emus: (by the way, I should probably submit my WhatsApp bridge to your newsletter!)

  22. emus

    Are you still making jokes? 😦

  23. eta

    nope, this actually exists

  24. emus

    Okay, yes then feel free

  25. eevvoor

    We have one strong supporter for XMPP in the German jouth authorities.

  26. eevvoor

    But where have you heard that German schools start to use Matrix? This is new to me.

  27. pep.


  28. eevvoor

    I know only of one district starting to use mailbox.org as mailserver which means additionally an XMPP-account.

  29. eevvoor

    > The deal announced on Wednesday will see the German states of Schleswig-Holstein and Hamburg deploy a Matrix-based solution for 500,000 users across public offices and education as part of its wider adoption of open source cloud strategy Project Phoenix being carried out by IT provider Dataport. Hm this is weird.

  30. eevvoor

    thx for the link pep.

  31. pep.

    Is there anything at the IETF saying the XSF has a specific role when it comes to XMPP?

  32. pep.

    6120 has multiple mentions of "XSF" but it all seems very informal and not exclusive

  33. Zash

    Does it need to?

  34. pep.

    I'm just curious to know the current state

  35. eevvoor

    would be better ...

  36. eevvoor

    ... my guess

  37. pep.

    eevvoor, I'm not entirely sure, but that's not what I'm asking here anyway

  38. eevvoor

    do other protocols do that? pep.

  39. pep.

    do what exactly? Define a separate entity to take care of them?

  40. eevvoor


  41. Zash

    Other than the delegation of the `urn:xmpp` namespace, I don't think there's any need for anything special from anyhere.

  42. pep.

    eevvoor, don't know

  43. pep.

    Zash, again, not asking about needs

  44. eevvoor

    That would be interesting to check.

  45. Zash

    pep.: What are you asking?

  46. pep.

    The current state

  47. pep.

    "IS there anything at the IETF saying the XSF has a specific role when it comes to XMPP"

  48. pep.

    "Is there anything at the IETF saying the XSF has a specific role when it comes to XMPP"

  49. Zash

    I don't think there is.

  50. Zash

    Anything special comes from actually publishing XEPs.

  51. Holger

    So I can just publish Holger's Extension Protocols and the IETF Police can do ... *nothing*.

  52. Zash

    Anyone could publish XMPP extensions, there is no requirement that it goes through the XSF.

  53. Daniel

    I don't think we are sanctioned be the ietf or anything if that's what you mean

  54. moparisthebest

    one could even publish XMPP extensions as google docs in russian, if one were so inclined

  55. pep.

    Daniel: Yeah that's what I was asking, and I didn't think either but I thought it might be good to confirm

  56. Daniel

    I also don't know of a lot of other extensible protocols that don't remain with the ietf

  57. Daniel

    For example IMAP extensions are still ietf

  58. pep.

    moparisthebest, imagine somebody publishing that on a random website (xmpp.org) in english :p

  59. Zash

    Google published a bunch of docs on their custom extensions.

  60. Daniel

    Or ietf working groups

  61. Daniel

    Which makes you wonder what lead to that decision

  62. pep.

    I'm curious why the XSF "had to" be a separate entity, I'd be interested to know the story behind this

  63. pep.


  64. Zash

    Probably because it already existed before the inital RFCs were created.

  65. Zash

    You could ask the same about the IETF

  66. pep.

    I also wonder what made the XSF (or JSF at the time) decide to go through the IETF process for some but not all their specs

  67. Zash

    The IETF isn't even an organization AIUI, it's like an activity organized by some other organizations.

  68. Holger

    Kinda obvious that anyone is free to publish custom extensions. I guess the fun situation would be if someone forked the XSF and claimed to be THE XMPP standardization organization.

  69. Zash

    pep.: Roughly the same reasons you'd go to the XSF with XEPs.

  70. pep.

    (my question being somewhat similar to the one above, why is there a need for the XSF at all)

  71. pep.

    Zash, "legitimacy"? But then are other specs not legitimate? :p

  72. Zash

    No, review by other people.

  73. pep.

    And other specs don't need review? :P

  74. pep.

    Just thinking out loud, there is not specific point I'm trying to make

  75. Zash

    You know that someone (at least Council in our case) looked at a XEP and said "this isn't terrible"

  76. pep.

    I wonder if merging as an IETF working group has ever been considered during the less active years

  77. pep.

    (or at all)

  78. Zash

    That would probably have worked too.

  79. Daniel

    I don't think there are significant upsides or down sides of being a working group

  80. eevvoor

    can the XSF be both? Itsself and an IETF working group?

  81. pep.

    I'm not sure it would be "The XSF" being an IETF working group but the same members

  82. Daniel

    Meaning I don't think that would benefit anyone in 'less active years'

  83. Daniel

    Work either gets done or it doesn't

  84. pep.

    Daniel, maybe it's slightly more visible to IETF people? dunno. I'm not really familiar with IETF

  85. eevvoor

    so it would be a mirror pep. ;)

  86. pep.

    But also we could share stuff like the infra etc. (using their ML and maybe some more if there is?)

  87. eevvoor

    every xep to an rfc :D (disclaimer: really just a joke)

  88. eevvoor

    ML is what pep.?

  89. Zash


  90. pep.

    eevvoor, Mailing List

  91. eevvoor

    ah :D

  92. pep.

    8800 RFCs.. I'm sure they can adopt another 400s :p

  93. Zash

    As always, some things are easier to do if you're independent. Other things are harder.

  94. pep.

    June 2020: JSON Canonicalization Scheme (RFC8785). Finally they get to it?

  95. moparisthebest

    then the XSF would simply exist to managed the Jabber trademark? (assuming it's still legally able to do so, still haven't seen proof of this)

  96. Zash

    A support group for XMPP developers?

  97. moparisthebest

    before someone links all the PDFs from xmpp.org they have all expired

  98. flow

    pep.> But also we could share stuff like the infra etc. (using their ML and maybe some more if there is?) there is already an XMPP ML for the concluded XMPP WG

  99. pep.

    flow, yeah I do remember that

  100. flow

    i think one could also try to get an xmpp extension published as rfc

  101. flow

    but without an working group adopting the I-D, I'd assume that will require some contacts within the ietf to actually happen (cf. xmpp grid)

  102. pep.

    Sure, just like IoT stuff is being/has been published at the IEEE

  103. stpeter

    Just catching up on the discussion. A few points: (1) the JSF predated our involvement with the IETF by a few years (2) the JSF was created to publish open documentation of the Jabber protocols and to add extensions in an open way too (3) we decided to formalize the core protocols at the IETF because we thought it would improve the quality/security of the core and also increase awareness / lead to more adoption especially by organizations that care about a more formal stamp of approval such as corporations and governments (4) there is no formal agreement in place between the IETF and the XSF about the division of responsibilities because we have a good working relationship with IETF folks and they prefer not to create formal agreements unless the working relationship isn't so healthy (5) yes, anyone can create and publish XMPP extensions but it's helpful to have a community of practice where we can review each other's work and therefore (we hope) produce better protocols for the sake of interoperability (6) I have sometimes considered the option of a separate RFC "stream" for XSF specs (there are already streams for IETF, IAB, IRTF, and "independent" documents) but I see no great reason to do that

  104. pep.

    Thanks for the clarifications

  105. eevvoor

    stpeter, sounds good

  106. pep.

    What's the "stream" thing exactly?

  107. pep.

    Also "lead to more adoption especially by organizations that care about a more formal stamp of approval" -> so yeah legitimacy

  108. stpeter

    Streams are input methods to the RFC publication process. They are described at https://www.rfc-editor.org/rfc/rfc4844

  109. Zash

    The IETF process is a bit more nuanced than one might think at first. Not just I-D → RFC

  110. stpeter

    Having published 45 RFCs, I can concur with that statement. :-)

  111. stpeter

    I think I'm in the top 1%: https://www.arkko.com/tools/rfcstats/authactdistr.html

  112. stpeter

    Not that it really matters.

  113. stpeter wanders off to his next $dayjob meeting