XSF Discussion - 2020-07-15

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!

😂

🤤

oh riot is now element

that's easier to google…

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.

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

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?

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

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

yeah, what they're selling is their hosting service

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

processone?

they don’t have clients

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

alright, makes sense.

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

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

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

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

Are you still making jokes? 😦

nope, this actually exists

Okay, yes then feel free

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

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

https://sifted.eu/articles/element-germany-deal/

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

> 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.

thx for the link pep.

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

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

Does it need to?

I'm just curious to know the current state

would be better ...

... my guess

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

do other protocols do that? pep.

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

yes

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

eevvoor, don't know

Zash, again, not asking about needs

That would be interesting to check.

pep.: What are you asking?

The current state

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

I don't think there is.

Anything special comes from actually publishing XEPs.

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

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

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

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

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

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

For example IMAP extensions are still ietf

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

Google published a bunch of docs on their custom extensions.

Or ietf working groups

Which makes you wonder what lead to that decision

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

that

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

You could ask the same about the IETF

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

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

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.

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

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

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

No, review by other people.

And other specs don't need review? :P

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

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

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

(or at all)

That would probably have worked too.

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

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

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

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

Work either gets done or it doesn't

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

so it would be a mirror pep. ;)

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

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

ML is what pep.?

Tradeoffs

eevvoor, Mailing List

ah :D

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

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

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

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)

A support group for XMPP developers?

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

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

flow, yeah I do remember that

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

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)

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

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

Thanks for the clarifications

stpeter, sounds good

What's the "stream" thing exactly?

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

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

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

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

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

Not that it really matters.