The XMPP Extensions Editor has received a proposal for a new XEP.
Title: OAuth Client Login
Abstract:
This specification details how a third-party can be securely granted
access to an XMPP account without exposing the account credentials,
using OAuth.
URL: https://xmpp.org/extensions/inbox/xep-oauth-client-login.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 1.0.2 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:
* Fix various invalid examples.
* Fix the XML Schema to match examples. (egp)
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.
Version 1.35.0 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 references to using resourceparts when banning users.
* Explicitly disallow Ban List modifications that clash with 'Banning
a User' conditions.
* Status code purpose no longer hints that recipient is the affected
user
* Improved 'Service Removes Non-Member' example.
* Clarify usage of presence stanzas when removing a non-member from a
members-only room.
* Replace inappropriate RFC 2119 key word usage in §9.7.
* Presence sent to occupants of a destroyed room includes a <destroy/>
element.
* Explicitly use bare JIDs when operating on affiliations.
* Allow non-owners to retrieve owner and admin lists in non-anonymous
rooms.
* Members should be allowed to retrieve the member list only in non-
anonymous rooms. (gk)
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.
Good morning Council Members,
the next XMPP Council Meeting will take place on, Tuesday, August 20
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
none
4) Items for voting
a) XEP-0045: Presence sent to occupants of a destroyed room includes a
<destroy/>
https://github.com/xsf/xeps/pull/1365
Let’s come to an agreement here that includes the wording for the note.
b) XEP-0388: Fix the XML Schema and examples
https://github.com/xsf/xeps/pull/1369
c) XEP-0045: Explicitly use bare JIDs when operating on affiliations
https://github.com/xsf/xeps/pull/1371
d) XEP-0045: Allow non-owners to retrieve owner and admin lists in
non-anonymous rooms
https://github.com/xsf/xeps/pull/1372
e) XEP-0402: Specify what clients should do if autojoin='0' in
bookmark notifications
https://github.com/xsf/xeps/pull/1373
5) Pending votes
Technically some people on 'XEP-0045: Presence sent to occupants of a
destroyed room includes a <destroy/>' but there is a new items for
voting for that after the PR was modified.
See the spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa…
6) Date of Next
7) AOB
8) Close
Version 0.2.0 of XEP-0478 (Stream Limits Advertisement) has been
released.
Abstract:
This specification defines a way for an XMPP entity to announce the
limits it will enforce for data received on a stream.
Changelog:
* Add the XML Schema.
* Clarify that both children can be optional.
* Fix indentation and one typo. (egp)
URL: https://xmpp.org/extensions/xep-0478.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.
Version 1.0.1 of XEP-0386 (Bind 2) has been released.
Abstract:
This specification provides a single-request replacement for several
activities an XMPP client needs to do at startup.
Changelog:
Add an XML Schema. (egp)
URL: https://xmpp.org/extensions/xep-0386.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.
Version 1.3.0 of XEP-0054 (vcard-temp) has been released.
Abstract:
This specification provides canonical documentation of the vCard-XML
format currently in use within the Jabber community.
Changelog:
Updated error cases to be compatible with . (gk)
URL: https://xmpp.org/extensions/xep-0054.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.
Greetings!
Years ago, someone here has posted to one of the Jabber mailing list a
suggestion to use "software purpose signs" (this is a phrase I use),
similarly to traffic signs and "creative commons" signs to which he has
made a reference.
Considering software such as LeechCraft, Libervia, Movim, and now
Rivista which are extensively or solely related to publishing; and
Considering a download manager software* which allows to be remotely
controlled via XMPP; and
Considering gateways, such as Slidge; and
Considering devices (aka IoT) that incorporate XMPP; and
Considering chat bots.
I think it is definitely a good idea to make use of signs as an optional
practice to categorize thhe type of software, and to make new people to
be aware that XMPP is not only for IM as too many of them, including
developers, might think.
* I do not recall the name of that software. I recall that it was
published on launchpad.net and it was written in Python.
Kind regards,
Schimon
Hi,
I looked through the XEP and i find a few things not great.
Im not getting the difference between <response> and <action>.
And the XEP makes no attempt to describe it.
A question that i answer with "Yes" or "No" should be a response, but a Question that i answer with "Merge" is an action?
Seems completely random. The XEP mentions no use case that can only be done with <response>, i see no reason at all as a client developer to implement this.
Now for <actions>, the id attribute is under specified, it seems essential to the whole thing working at all.
Should this be a globally unique ID? Or at least unique per remote JID?
In my opinion <action> should have another id attribute (of course differently named) referencing the message it belongs to.
We have this pattern with message errors, iq responses, reactions, message replies, moderation, etc., we should not break this pattern here for no gain, just because its theoretically possible to still match this if the id is globally unique.
I think this is a really nice idea and feature, but it should fit in with current XEP patterns, and better describe what <response> even should accomplish.
Is the original Author still around?
I also looking forward to other peoples opinions.
