* Jonas Schäfer <[email protected]> [2021-03-24 17:03]: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Yes. > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, > why not? Implemented in yaxim since ~2013. > 4. Do you have any security concerns related to this specification? Given the number of CVEs this specification has accumulated, I think we need a Huge Red Blinking Marquee tag in our stylesheet to introduce the security section. > 5. Is the specification accurate and clearly written? Mostly yes. I have some minor things that I'd like to address after the LC though, for which I'm interested in public feedback. 0. Mandatory Rules Support The result of the last Last Call was the introduction of the Recommended Rules (§6.1) and a feature flag for their mandatory support (§6.2) roughly two years ago. It looks like only ejabberd so far has started advertising the "urn:xmpp:carbons:rules:0" feature. I'd really like to see more feedback from server developers on this new part of the specification. 1. Bridge Carbons: this is a verbatim copy from my 2019 Last Call response: When you have a bridge to a legacy network, you want to see the messages sent from your legacy client in your XMPP client, so you need some way to whitelist the bridge to send you 'sent' (and 'received'?) carbons with user JIDs behind that bridge. This is in violation of XEP-0280 Security Rules, but would be still very useful. "XEP-0356: Privileged Entity" or "XEP-0321: Remote Roster Management" might be a solution to that. Related thread: https://mail.jabber.org/pipermail/standards/2018-January/034224.html 2. Message Hints XEP-0334 ended up in Abandoned state and there is no clear way forward with it. Carbons is still using Hints as one of two signalling mechanisms, which is not very pretty, but also not harmful. With the long-term future of Hints being unclear, I'm not sure if it is good to keep it in Carbons, or to make some wasel-wording that the server must accept either as a signal to not carbon-copy. Reltated thread: https://mail.jabber.org/pipermail/standards/2017-June/032847.html 3. Stripping of the <private/> element I agree with Kev that the receiving server should not remove the private element, and it would be good to have a Council discussion of the implications of removing the removal requirement. 4. Mobile Considerations I think the mobile considerations have it all backward; Carbons are especially important for mobile clients and we should strongly encourage them to implement it. 5. Messages to Self When you send a message to your own JID, you'll end up with multiple copies, see https://mail.jabber.org/pipermail/standards/2017-March/032421.html Does it make sense to have a special treatment of these messages in 0280? Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
