* Jonas Schäfer <[email protected]> [2019-01-08 17:55]: > This message constitutes notice of a Last Call for comments on > XEP-0280. > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Yes, it is a very important piece for modern multi-client deployments. > 2. Does the specification solve the problem stated in the introduction > and requirements? Mostly. It appears to be a 70% solution, with gaps in handling of conversation metadata (acks, errors, chat states). Please see below for a detailed list of issues. > 3. Do you plan to implement this specification in your code? If not, > why not? I have implemented it in 2013 and consider it an important part of modern IM. > 4. Do you have any security concerns related to this specification? The Security Considerations section is clear, but often ignored by implementing entities. > 5. Is the specification accurate and clearly written? No. The rules in the XEP are vague and insufficient. I have proposed a better, but still imperfect, wording in PR#434: https://github.com/xsf/xeps/pull/434 That PR handles most chat use cases and the MUC-related ones, but it is still missing: - chat markers and receipts (some implementations will send them as type=normal, and as they don't have a body, they will vanish): https://mail.jabber.org/pipermail/standards/2018-November/035432.html - errors (feedback from server authors implies that error-tracking would be too expensive; my gut feeling is that just carbon-copying all message errors would be an improvement already) - Consolidation with IM-NG: I think we should rework our CC rules based on the discussion from last year's Summit and the IM-NG proposal, especially to allow CCing of *all* messages sent to the bare JID, not depending on type or content any more. There are also two high-level issues I see, which might demand for dedicated XEPs however: 1. Bridge Carbons 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. 2. No control over what kind of messages gets CCed Carbons are an all-or-nothing endeavour. You opt in, you get CCs of everything. However, a mobile client might not be interested in Chat State Notifications or some other XMPP feature, so it would be useful to define what will and what will not be CCed to that client. One way to accomplish that is to have an explicit list of namespaces / features / properties in the <enable/> element. Another one would be to make the server parse the client Entity Capabilities and to only forward stanzas / payloads according to the caps. 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: [email protected] _______________________________________________
