* Florian Schmaus <f...@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. Georg -- || 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 ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
