Thanks Dave, I really appreciate you kicking off this discussion.
On 27/05/2024 15.07, Dave Cridland wrote: > I've rejected protoXEPs as arbitrarily as anyone else when in Council, > but loosely a few things crop up repeatedly: > * Unwarranted duplication of effort: The problem being solved is already > at least partially addressed by an existing solution, and it seems > better to fix that than wholesale replace it. I am very skeptical to have any kind of "duplication" criteria.First, in some cases there is no one-size-fits-all. Very possible that we we will not end up with the one-and-only XMPP IoT protocol extensions. But maybe multiple with different goals and tradeoffs.
Secondly, the XSF should not encumber competition. At least not in early stages. And quite frankly, the XSF is also not in any position to do so. Just because a XEP is rejected, does not automatically mean that it will not get implemented. The developers and users of XMPP software also weight in and have an impact on the resulting ecosystem.
Therefore, I suggest that the XSF embraces competition in the early stages and, in case of duplicated efforts, limits itself to advocating certain extensions.
Equally, I've seen other proposals suggesting much higher bars for accepting a protoXEP, with in effect a pre-Experimental stage tacked on beforehand. I think this would be bad, too, and risks just accreting stages for no real benefit - but it's also essentially inevitable if the bar for accepting a protoXEP is raised too high.
Such a pre-experimental stage already exists, whether we like it or not. People work on XMPP extensions, and if the bar is too high, they will just work on those extensions outside of the XSF [1].
And that is really a pity and something we should fix.What I'd like to see is that the XSF creates a place to cater for those ProtoXEPs (as how I will refer to pre-experimental XEPs in the following). Could be as simple as creating a directory protoxeps/ in xsf.git and ensuring that the contents of this directory rendered and available under xmpp.org/extensions/protoxeps. I hope that this will get us a long way towards fighting the fragmentation that we have [2].
We should make it crystal clear to readers of those ProtoXEPs that they did not undergo any expert review yet. As consequence, this means that the authors of those ProtoXEPs must be aware that it is not impossible that their specification may need a major overhaul before it can enter the 'experimental' stage [3]. In exchange, ProtoXEP may break their wire protocol without a namespace bump (which must also clearly documented).
Consequently, this means that Council should focus on the technical side when presented with a ProtoXEP for adoption. With a particular focus on how idiomatic the XEP, when it comes to XMPP. For example, is there an attribute when it should be an element?
And once a XEP has been honored with an number. Strict namespace versioning rules should apply. Interoperability is a valuable asset in XMPP land, that we must protect.
Last but not least and not directly related to strict namespace versioning rules, but related to namespacing: I started to wonder if it were not better if we requiring a new XEP number in case of a namespace bump.
This would help when referencing XEPs. For example, if I would task some random stranger to implement xep384, I would probably not end up with the implementation that I wanted.
- Flow1: This happened plenty of times, for example the various MUC alternatives (MUCLight, MucSub, etc.)
2. XMPP extensions residing on personal homepages and/or personal gits3: A recent example for this was Guus' "PubSub Server Information" (xep485): At first reluctant, since there was already an implementation, Guus could be convinced that the wire protocol and XML design should be improved for the greater benefit.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
