- Standards

by Philipp Hörist

Hi, Some feedback while trying to implement these XEPs XEP-0424 1) The schema mentions <xs:attribute name='by' type='xs:string' use='optional'/> But the XEP does not mention the attribute, what is the purpose? 2) > When replacing the original message with a tombstone, the original contents (i.e. the <body/> and any related elements which might leak information about the original message) get replaced with a <retracted/> element which MUST include an 'id' attribute referring to the original message Why does the element MUST have an id attribute? its a element inside the <message> which already has the id, or in case of groupchat its inside a mam wrapper which has a stanza id, in all cases its perfectly clear that the retracted element belongs to the actual message wrapping it, maybe im missing something obvious here but i dont see a need for this id attribute at all. Example 7 > For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs (XEP-0359) <https://xmpp.org/extensions/xep-0359.html> [4 <https://xmpp.org/extensions/xep-0424.html#nt-idm41385450875712>] 'origin ID' MUST NOT be used for retractions Example mentions origin-id in groupchat context <message type="groupchat" from="romeo(a)montague.example" to="lord(a)capulet.example" id="wrong-recipient-1"> <retracted stamp='2019-09-20T23:09:32Z' xmlns='urn:xmpp:message-retract:1' id='origin-id-1'/> </message> XEP-0425 1) > A Message Archive Management (XEP-0313) <https://xmpp.org/extensions/xep-0313.html> [6 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750431632>] service MAY replace the contents of a message, that was retracted due to moderation, with a 'tombstone' similar to the one described in Message Retraction (XEP-0424) <https://xmpp.org/extensions/xep-0424.html> [5 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750445088>]. How similiar? The tombstone text does not mention seemingly important MUST rules from XEP 0424 For example > Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone. the above mentioned MUST rule about the id attribute in the <retracted> element, seems to be not important anymore in moderation, at least the id attribute is not found anymore in the tombstone. Im not saying we need to copy text 1:1 between the XEPs, but should the XEP not go into more detail what exactly the differences are, and what exactly from 0424 applies? Thanks Regards Philipp

1 year, 10 months

2
1
0 0

UPDATED: XEP-0045 (Multi-User Chat)

by Daniel Gultsch

Version 1.34.6 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. Changelog: Remove contradicting keyword on sending subject in §7.2.2. (pep) URL: https://xmpp.org/extensions/xep-0045.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.

1 year, 10 months

1
0
0 0

UPDATED: XEP-0030 (Service Discovery)

by Daniel Gultsch

Version 2.5.0 of XEP-0030 (Service Discovery) has been released. Abstract: This specification defines an XMPP protocol extension for discovering information about other XMPP entities. Two kinds of information can be discovered: (1) the identity and capabilities of an entity, including the protocols and features it supports; and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service. Changelog: Add note about some entities not advertising the feature. (pep) URL: https://xmpp.org/extensions/xep-0030.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.

1 year, 10 months

1
0
0 0

XMPP Council Agenda 2024-05-07

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, May 7 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update 4) Items for voting a) PR: XEP-0030: Note known wart https://github.com/xsf/xeps/pull/1341 b) PR: XEP-0045: Remove conflicting keyword in §7.2.2 https://github.com/xsf/xeps/pull/1342 5) Pending votes Marvin on * Issue Last Call on 'XEP-0421: Anonymous unique occupant identifiers for MUCs' (expires today) See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 10 months

1
0
0 0

STABLE: XEP-0398 (User Avatar to vCard-Based Avatars Conversion)

by Daniel Gultsch

Version 1.0.0 of XEP-0398 (User Avatar to vCard-Based Avatars Conversion) has been released. Abstract: This specification describes a method for using PEP based avatars and vCard based avatars in parallel by having the user’s server do a conversion between the two. Changelog: Accept as Stable as per Council Vote from 2024-04-30. (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0398.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.

1 year, 10 months

1
0
0 0

Fwd: [kitten] SCRAM-SHA512 and SCRAM-SHA3

by Matthew Wild

Hi folks, I'm forwarding this email that was posted to the IETF working group responsible for SASL improvements, because I think it is quite relevant to people here, yet many are probably not following the kitten mailing list. I'm aware that by now most XMPP projects have received feature requests to implement what are essentially obscure flavours of SCRAM, without much rationale beyond what can be paraphrased as "the numbers are bigger, and therefore better". If we decide to move the protocol and ecosystem beyond SCRAM-SHA-1 (which is required by the current RFC) and possibly SCRAM-SHA-256, it should be with the necessary attention paid to interoperability and security. All current feature requests I've seen lack this. ---------- Forwarded message --------- From: Simon Josefsson <simon=40josefsson.org(a)dmarc.ietf.org> Date: Thu, 2 May 2024, 09:20 Subject: [kitten] SCRAM-SHA512 and SCRAM-SHA3 To: <kitten(a)ietf.org> Hi I'm seeing push on implementers to add support for these variants, and I noticed new drafts were published recently. I want to repeat some earlier concerns. I believe the cost of having these two mechanisms as standard mechanisms in the ecosystem costs more than any advantages we would get out of them. There is still no cryptographic attack on HMAC-MD5, yet alone the HMAC-SHA1 or HMAC-SHA256 that are used in SCRAM-SHA1 and SCRAM-SHA256 that we are still seeing deployment of. Adding SCRAM-SHA512/SHA3 variants create additional requirements on hashed password database formats and APIs, since they are not compatible with SCRAM-SHA1 and SCRAM-SHA256. Parametrization of security protocols and algorithms are generally a bad idea as it adds complexity which reduce security. There is the negotiation interop problem if a server has one credential but not the other for a subset of users. If some people are using these variants, I would agree that having them documented is useful. Then I believe the category should be Informational rather than standards track, and warnings about the problems should be added. /Simon _______________________________________________ Kitten mailing list Kitten(a)ietf.org https://www.ietf.org/mailman/listinfo/kitten

1 year, 11 months

1
0
0 0

UPDATED: XEP-0388 (Extensible SASL Profile)

by Daniel Gultsch

Version 1.0.1 of XEP-0388 (Extensible SASL Profile) has been released. Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. Changelog: Fixed typos (md) URL: https://xmpp.org/extensions/xep-0388.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.

1 year, 11 months

1
0
0 0

XMPP Council Agenda 2024-04-23

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, April 23 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * STABLE: XEP-0334 (Message Processing Hints) * STABLE: XEP-0333 (Displayed Markers) 4) Items for voting a) Issue Last Call on 'XEP-0421: Anonymous unique occupant identifiers for MUCs' 5) Pending votes Marvin on * XEP-0388: Fix typo (PR) (Expires today) * Move 'XEP-0398 (User Avatar to vCard-Based Avatars Conversion)' to stable * Issue Last Call on 'XEP-0440: SASL Channel-Binding Type Capability' See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 11 months

1
0
0 0

STABLE: XEP-0334 (Message Processing Hints)

by Daniel Gultsch

Version 1.0.0 of XEP-0334 (Message Processing Hints) has been released. Abstract: This document defines a way to include hints to entities routing or receiving a message. Changelog: Accept as Stable as per Council Vote from 2024-04-17 (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0334.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.

1 year, 11 months

1
0
0 0

STABLE: XEP-0333 (Displayed Markers)

by Daniel Gultsch

Version 1.0.0 of XEP-0333 (Displayed Markers) has been released. Abstract: This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point. Changelog: Accept as Stable as per Council Vote from 2024-04-17. (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0333.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.

1 year, 11 months

1
0
0 0

2026

2025

2024

2023

Standards