- Standards

UPDATED: XEP-0455 (Service Outage Status)

by Daniel Gultsch

Version 0.3.1 of XEP-0455 (Service Outage Status) has been released. Abstract: This document defines an XMPP protocol extension that enables server administrators to communicate issues with the server to all users in a semantic manner. Changelog: Fix typo in JSON Schema. (ka) URL: https://xmpp.org/extensions/xep-0455.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.

11 months, 1 week

1
0
0 0

XEP-0433 Extended Channel Search feedback

by Guus der Kinderen

Hello! Here's my feedback on XEP-0433 Extended Channel Search: https://xmpp.org/extensions/xep-0433.html The feedback herein is based on two efforts: - Adding support for XEP-0433 to Openfire (which is now reaching a ready-ish state: https://github.com/igniterealtime/Openfire/pull/2756 ) - Adding interop tests to the Xmpp Interop Testing Framework ( https://github.com/XMPP-Interop-Testing/smack-sint-server-extensions/pull/77 ) Particularly the exercise of trying to write tests generated quite a bit of feedback. Without having explicit MUST conditions, it is not possible to write many assertions. This is why a lot of the feedback below suggests making things explicit. 1. I'd like to see a MUST in 4.2 / 4.2.1 that describes that the service to be searched MUST support the retrieval of a search form. That removes ambiguity, I think. I prefer the clarity of the wording in the comparable section 2.1 of XEP-0055: https://xmpp.org/extensions/xep-0055.html#usecases-search That section describes basically the same functionality requesting a form), but it's more explicit. 2. Explicitly define the form type (which is now mostly in an example. It's slightly different from Muclumbus, which can add to the confusion (maybe a 'differences with precursor' section would be handy). 3. The XEP defines two sort keys. It would be good to explicitly define if they are mandatory-to-implement? 4. If the sort keys are meant to be extensible, like the form fields, it would be good to make that more explicit (perhaps with references to a registry, like we do for other XEPs). The XEPs author mentioned in a chat that sort keys are meant to be extensible and neither are mandatory-to-implement. They also wrote that clients must discover support for individual sort keys by requesting the form. No matter what detection mechanism is used, I would like to see a MUST definition for the server to provide this mechanism. Without it, clients can only guess. 5. Section 4.2.2 reads: "it MAY omit all fields it does not know or where it does not change the value already supplied by the Search Service." This implies that the Search Service will use the default value of that field, if not supplied by the Searcher. If that's the intent, I'd also explicitly state that, to prevent confusion. I do wonder if that can cause weird issues. A searcher can submit the exact same search request (to different services) but it could represent a very different query. I wonder if that's going to cause problems at some point. The XEPs author replied via chat: "regarding the defaulting: you're right: absent fields should be interpreted as "client does not know them" as opposed to "use defaults"." Let's change the XEP to reflect this. 6. Section 4.2.2 reads: "The Searcher MAY include a Result Set Management (XEP-0059) [4] <set/>" Does this imply that the Service MUST support RSM? If that's not the case, then I would change 'MAY' for 'may' here. As XMPP is extensible, any entity should disregard extensions that it doesn't recognize anyway. With that in mind, the MAY usage seems to imply something. If that _is_ the case, then I'd prefer that to be explicitly stated (eg: "the Service MUST support RSM"). The XEPs author replied via chat: "yes, the service MUST support RSM. RSM is a hard dependency. (both sides MUST support RSM in fact, but the initial query does not necessarily need an RSM element, in which case page size etc. are defaulted by the service)." Again, I propose to make this explicit in the XEP. 7. Question on XEP-0433 / 4.2.2.6 (conflicting fields): Would usage of `all` combined with one of the vars that relate to `q` (like `sinname`) also be considered conflict to which a `<conflicting-fields/>` MUST be responded with? Is using `sinname` (and/or friends) _without_ `q` (or any equivalent, unspecified var) also considered a conflict? The XEPs author replied via chat: "yeah, I think `all` should conflict with all other fields which may restrict the resultset. `sinname` without a query or equivalent should also cause a conflict, yes." I answered: "even `all` combined with something like `sinname=false` ? Things get tricky there :) (and is that a MUST NOT or SHOULD NOT?) (which is increasingly annoying when the form is pre-populated by the server, as not supplying a field does not change the value already supplied by the Search Service. Doesn't this mean that the server can never pre-populate `sinname` and friends, as you can't un-populate those when you want to do a `all`?)" 8. example 10 https://xmpp.org/extensions/xep-0433.html#example-10 uses `not-allowed` while the text defines that `bad-request` should be used. 9. Table 1 defines `sinaddress` while example 3 uses `sinaddr` - muclumbus used `sinaddr` which makes this an easy one to get wrong, I think. Perhaps another item for a 'differences with precursor' section. 10. The XEP has "ignoring text search terms" in a couple of places that relate to `all`. I would remove that, as it implies that any value for `q` could be ignored (rather than that this is a MUST conflict scenario). 11. Section 6.2 describes the 'is-open' as boolean character data. "If set to true, it indicates that the channel can be joined without extra credentials." In examples, the element is used like this: `<is-open/>`. This to me seems to suggest that the element is present when the room is open, which suggests that the element is absent when the room is not. This does not track well with the definition, which seems to call for an explicit 'true' or 'false' value. 12. Somewhat of a nit, but table 2 doesn't define what the direction of the ordering is when using the address-based key. Consider making that more explicit. That's it, I think. Apologies for the haphazardous approach. This was compiled in many different sittings, which made the organisation go out of the window. - Guus

11 months, 2 weeks

1
0
0 0

Hosting the XEP index over XMPP

by Schimon Jehudah

Good day. The XEP index is currently hosted over HTTP, and I think that it would be a good idea to host it over an XMPP server as well. Actually, until some time ago, I have used an HTML browser just to access XEP pages, when I did use a browser. I have also wrote an article about hosting sites over XMPP. gemini://woodpeckersnest.space/~schapps/journal/2024-12-14-xmpp-as-the-internet.gmi A video from Goffi. https://fosdem.org/2025/schedule/event/fosdem-2025-5721-a-universal-and-sta… I am also eager to for the day when Libervia standardize an XEP for forum, so that also discussions of XEP be feasible over XMPP with Libervia and Movim. Regards, Schimon

11 months, 2 weeks

2
1
0 0

Superseded notes for XEP-0153 and XEP-0054

by Schimon Jehudah

Good day. Should XEP-0153 and XEP-0054 have "Superseded By" references? Regards, Schimon

11 months, 2 weeks

2
2
0 0

Transmit of contact photo per Jabber ID

by Schimon Jehudah

Good day! I want to create a weather bot which is not a component. However, I would not be able to make a dynamic use of contact photo, as I would with a component. Because, it is not possible to selectively transmit contact photo. I think, that this would have useful uses to different use-cases, so it would be good to create an XEP to it. Please advise, Schimon

11 months, 2 weeks

1
1
0 0

UPDATED: XEP-0455 (Service Outage Status)

by Daniel Gultsch

Version 0.3.0 of XEP-0455 (Service Outage Status) has been released. Abstract: This document defines an XMPP protocol extension that enables server administrators to communicate issues with the server to all users in a semantic manner. Changelog: Remove all in-band event signaling. (mp) URL: https://xmpp.org/extensions/xep-0455.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.

11 months, 2 weeks

1
0
0 0

UPDATED: XEP-0377 (Spam Reporting)

by Daniel Gultsch

Version 0.4.0 of XEP-0377 (Spam Reporting) has been released. Abstract: This document specifies a mechanism by which users can report spam and other abuse to a server operator or other spam service. Changelog: * Add spam report processing opt-in. * Add Guus der Kinderen as co-author. (gdk) URL: https://xmpp.org/extensions/xep-0377.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.

11 months, 2 weeks

1
0
0 0

Identifying username and password fields during Extensible IBR (XEP-0389)

by Badri

Hi everyone! I've been trying to design a "verify with one-time code during registration" flow using XEP-0389 (Extensible In-Band Registration). Specifically, this is for registration on the server itself (not on an external component) and I'm using the jabber:x:data challenge. However, I realised there's no standard way for the client to know what its username and password is once the registration is complete. The old IBR spec (XEP-0077) uses special <username/> and <password/> fields which the client can automatically save to avoid the user having to re-enter it. Since "username, password, and some additional verification step" sounds like a common use-case for IBR, should this be added to the spec in some way? Some options: 1. Extend the jabber:x:data challenge to say something like: servers MUST NOT use var='username' and var='password' for anything other than username and password, and clients MAY save those values locally if present to avoid forcing the user to re-enter them. 2. Alternatively, extend the jabber:x:data challenge to say it can optionally include <username/> and/or <password/> tags as siblings to the <x xmlns='jabber:x:data' type='form'> form itself. 3. Same as (2), but with a new challenge type to keep things simple for those who actually want just an ordinary Data Form. 4. Define a new challenge type something like jabber:iq:register consisting of only <username/> and <password/> fields from 0077 (not sure what to do about <email/>, but I don't see a need for it). This is different from just using 0077 directly because the server can issue this challenge as part of a flow *along with* other challenges like jabber:x:data or jabber:x:oob. The disadvantage is the server would have to issue an extra challenge (once for the username/password, and again for the email address or whatever other data it wants like phone number) rather than combining them in one form/challenge. However, this approach is arguably cleaner as it doesn't mix different kinds of things (data forms and specific standardised fields) together. Let me know what you think of the above. I hope I didn't miss something entirely! If there are existing implementations of XEP-0389, it would be helpful to see, although I don't find any on the XMPP software list. Best, Badri

11 months, 2 weeks

3
2
0 0

Synchronizing encryption keys accross different resources

by Schimon Jehudah

Greetings. Suppose that I want to access to data over PubSub which is encrypted with OpenPGP. I then would have the GPG key in order to access to that data. Should the key be also stored over a PubSub node and then be synchronized to resources that request it? What would be a good practice to do it? My use-case is of an annotation system which is based on Atom Over XMPP. Reference: https://forum.palemoon.org/viewtopic.php?f=5&t=31900 Regards, Schimon

11 months, 3 weeks

1
0
0 0

UPDATED: XEP-0421 (Occupant identifiers for semi-anonymous MUCs)

by Daniel Gultsch

Version 1.0.1 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs) has been released. Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of semi-anonymous users. Changelog: Fixed typo (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0421.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.

11 months, 3 weeks

1
0
0 0

2026

2025

2024

2023

Standards