[Standards] XMPP Council Agenda 2021-06-30
Hi everyone, The next XMPP Council Meeting will take place on 2021-06-30 at 15:00Z in xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the discussions. This agenda is composed from: - Editor notifications to standards@ - xsf/xeps GitHub PRs marked as Needs Council - xsf/xeps GitLab MRs marked as Needs Council - Suggestions directly sent to me (see below) Agenda as follows: 1) Roll Call 2) Agenda Bashing * Feel free to pre-bash on-list or directly to me if you think something is missing. 3) Editor’s Update * Proposed XMPP Extension: Moved 2 4) Items for voting 4a) PR#1064: XEP-0227: New revision 1.1 URL: https://github.com/xsf/xeps/pull/1064 Re-vote as it was modified during voting. 4b) Proposed XMPP Extension: Moved 2 URL: https://xmpp.org/extensions/inbox/moved2.html Abstract: This specification details a way for a user to notify their contacts about an account move. NB: The author noted that they are perfectly happy merging this with and taking over XEP-0283 (Moved) if the authorship can be sorted out. 5) Pending Votes None. 6) Date of Next 7) AOB 8) Close End of Agenda. Note that I am aiming for 30 minutes, but meetings may be extended as necessary if all council members agree. Meetings are normally held every Wednesday at 15:00 UTC in the xmpp:coun...@muc.xmpp.org?join chatroom. Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP Council members may vote. Relevant comments from the floor are welcomed. Using your web browser, you can join anonymously via https://xmpp.org/chat?council Note that conversations in the room are logged publicly at https://logs.xmpp.org/council/ If you have suggestions for an agenda item, you can message me via XMPP or email at this address or at jo...@zombofant.net. I aim to publish the Agenda on the day before the Council meeting before 19:00Z. Stay safe, smart & healthy, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0458 (Community Code of Conduct)
Version 0.2.0 of XEP-0458 (Community Code of Conduct) has been released. Abstract: This document describes the XMPP Standard Foundation's Code of Conduct Changelog: Integrate various comments from various sources (dwd) URL: https://xmpp.org/extensions/xep-0458.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OBSOLETED: XEP-0423 (XMPP Compliance Suites 2020)
Version 1.0.0 of XEP-0423 (XMPP Compliance Suites 2020) has been released. Abstract: This document defines XMPP application categories for different use cases (Core, Web, IM, and Mobile), and specifies the required XEPs that client and server software needs to implement for compliance with the use cases. Changelog: Update to Draft as per council vote on 2019/11/07. (mb) URL: https://xmpp.org/extensions/xep-0423.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Moved 2.0
On Samstag, 26. Juni 2021 14:31:02 CEST Sam Whited wrote: > Another thought: > > Any spec that triggers traffic to a third party JID based on other > incoming traffic can be used for DOS amplification attacks. This one > seems only somewhat vulnerable (max payload size of the pubsub element + > max JID size bytes) but any of them can also become worse if > implementations have flaws (such as naively copying the payload which > could also result in any unknown garbage elements on the end being > copied, making the attack much worse if vulnerable clients existed). Yikes. The concerns are valid, but as you say, in this case it is probably OK. Adding the "do not copy random payloads over" to the Security Considerations is probably sane, though the <-> protocol break probably takes care of that anyway. (Or am I looking at the wrong place?) > It may be worth mentioning this in the security considerations section, > or providing a way to verify by a push from the old account instead of > querying it. I think this has more issues. Off the top of my head: - PEP notifications are only delivered to online resources (via '115 caps "subscription") -- if no resources are online, the contact’s server will not hear about it - Explicit subscription to the moved PEP node on presence subscription would be possible, but requires even more server support - Delivery of s is unreliable -- if the s2s link breaks at the wrong time, verification would fail - Servers would have to cache verification information (either the pending verification from an inbound until the PEP push arrives or the verification information which was pushed via PEP until the presence arrives); this requires persistent storage, which may be more expensive (especially at scale) than the CPU/Bandwidth cost of the above DoS vector, especially if rate limiting is applied. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0227 update
Hi, On Wed, Jun 02, 2021 at 04:59:40PM +0100, Matthew Wild wrote: I've prepared an update that adds some of the missing features: - PEP nodes (configuration and items) What about explicit subscriptions and affiliations relevant? While not strictly required for basic PEP, there are implementations that support more optional (for PEP) PubSub features including support for subscriptions and affiliations that aren't attached to presence subscriptions. And with that covered by XEP-0227 then it might not be far from being usable for PubSub (components etc) exports as well. -- Kim "Zash" Alvefur ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
