[Standards] NEW: XEP-0423 (XMPP Compliance Suites 2020)

Georg Lukas georg at op-co.de
Mon Oct 14 12:28:46 UTC 2019

* Florian Schmaus <flo at geekplace.eu> [2019-10-11 12:35]:
> I am going to give feedback based on
> https://op-co.de/tmp/xep-0423.html
> which is, if I understood Georg correctly, the current state.

Yes, it is. Thank you very much for your feedback!

> There are two protocol extension evaluations that are currently missing:
> XEP-0114: Jabber Component Protocol → XEP-0225: Component Connections
> XEP-0115: Entity Capabilities → XEP-0390: Entity Capabilities 2.0
> The right hand side of the arrows should probably be mentioned in "3.
> Future Development" or probably even in § 2.

Both RHS XEPs are Deferred, and I'm not sure what their actual state and
practical relevance is. I can add them to §3, if there are voices from
the floor about following up with their implementation.

> I would add a note that Jingle IBB is the most reliable transport, and
> (I assume) hence the only Jingle transport explicitly mentioned, because
> this is the first transport you probably want to implement, while noting
> that it is the most inefficient transport.

I'd rather have such a note in XEP-0234, if it isn't there already (it
mandates IBB already, BTW, so technically 0261 does not need to be
mentioned in the CS).

> And, of course, I miss XEP-0374: "OpenPGP for XMPP Instant Messaging"
> from being mentioned in "3. Future Development".

I see your intent, but in the long term, I'm not sure how many E2EE XEPs
we can put into the CS. OMEMO so far is the one with the widest adoption
(despite having some serious shortcomings in the spec), and I'm not keen
on adding every possible E2EE approach (if I were, there would be
another one I'm working on high up on the list ;-) )

> - Remove "and related specifications" from the MIX reference, as it
>   is just unnecessary noise.

That was mainly a reminder for me to put into place all the MIX XEPs, as
there is a bunch, and I wrote that in a hurry.

> - OMEMO, EME and JFT are mentioned in the same bullet point in § 3.
>   This is probably an indication that we should create an "Encryption"
>   subsection in § 3, which gives an overview on what is going on in this
>   regard. This could even give a hint towards MLS.

Eventually, there should be an encryption subsection in §2. I'll try to
make a better structured subsection in §3 as soon as I find the time.

> - Not sure why the \me command XEP (XEP-0245) is a core client
>   requirement. If anything, I would consider it an advanced feature.

I was actually surprised to see it not mentioned at all in previous
versions of the CS. As a person coming from IRC, this is one of the
most-used commands for me, so I felt it would be natural to have it.
This is mainly about consistency between clients. Furthermore, it's
very straight-forward to implement, so not a high burden on the
developers, which is why I consider it Core.

|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191014/920aaae6/attachment.sig>

More information about the Standards mailing list