- Standards

Re: LAST CALL: XEP-0334 (Message Processing Hints)
by Daniel Gultsch 20 Mar '24

20 Mar '24

Hi Matthew, On Thu, Feb 23, 2017 at 1:53 PM Matthew Wild <mwild1(a)gmail.com> wrote: > > On 8 February 2017 at 23:47, Christian Schudt <christian.schudt(a)gmx.de> wrote: > > > >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? > > > > Partly. > > XEP-0079: Advanced Message Processing already solves the same problem. > > > > drop forward => no-copy > > drop stored => no-store > > > > Maybe the document should go into more detail regarding differences > with AMP. Some notes: > > - You can implement both specifications if desired > - Over 10 years after publication, XEP-0079 is not widely > implemented, I believe this is largely due to its complexity > - XEP-0079 requires multiple discovery steps before you can actually > send a message > - XEP-0079 is relatively difficult to re-use in other XEPs > - Lots of edge cases, e.g. interaction with MUC rooms. With hints the > server is still free to choose the most sensible option given the info > it has. Council has Issued another Last Call on 0334¹ and I've been going over the feedback from the last Last Call. The Editor will start the Last Call next Monday. I think it received mostly positive feedback back then and I have no reason to believe it won’t pass Last Call this time. However I think you were right that the document should go into more detail regarding differences with AMP. Furthermore a little down the thread Dave had feedback wrt hints in Error messages: "I noted that messages of type error are explicitly called out in §4.4, however I think there needs to be a general rule that hints SHOULD be ignored in messages of type='error'. Possibly MUST. Errors are sometimes generated by bouncing the entire stanza, including original contents, back to the sender, and these original contents might include a hint; it seems sensible to always ignore these." that also sounds like a sensible addition to me. Maybe you have the time to make those changes before Last Call even starts (next Monday) Thank You cheers Daniel ¹: On February 8th 2023

1 0

XMPP Council Agenda 2024-03-19
by Daniel Gultsch 18 Mar '24

18 Mar '24

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, March 19 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 * LAST CALL: XEP-0388 (Extensible SASL Profile) * LAST CALL: XEP-0386 (Bind 2) 4) Items for voting a) Issue Last Call on XEP-0333: Displayed Markers (was: Chat Markers) https://xmpp.org/extensions/xep-0333.html 5) Pending votes * Dan on Proposed XMPP Extension: Message Displayed Synchronization See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 0

Re: Proposed XMPP Extension: Communicate & Ask to AI
by Abdurrahman Eker 17 Mar '24

17 Mar '24

Hey list, I am attaching the update on the issues discussed in the thread. kind regards, Abdurrahman Jonas Schäfer <jonas(a)wielicki.name>, 15 Kas 2023 Çar, 19:25 tarihinde şunu yazdı: > Hi list, hi Abdurrahman, > > On Montag, 30. Oktober 2023 17:15:52 CET kevin.smith(a)isode.com wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Communicate & Ask to AI > > Abstract: > > This document defines a protocol for asking questions to an artificial > > intelligence or requesting it to make predictions. > > > > URL: https://xmpp.org/extensions/inbox/xep-ai.html > > Thank you for your submission, Abdurrahman. > > We discussed this in the Council and I want to share a few suggestions for > improvement with you. > > The mandatory <ai> element, as Nicolas already pointed out, seems like an > odd > requirement: there are already LLM-based entities out there which would > immediately be non-compliant. In adddition, the model selection is > underspecified: How would I know which models are even available at that > particular agent? > > I think it would be better to: > - Specify a new XEP-0030 identity based on the already existing > bot-identity > which identifies an account as a bot. > > This builds on already existing mechanisms, which is always good. > > - Define a XEP-0030 feature or XEP-0128 service discovery extension which > describes the model used by the "AI" account > > This allows clients/users to discover information about the specific > type > of model used, which is useful. > > - Then use separate accounts for different models. > > This is probably debatable; if there is a compelling usecase for > hosting > multiple models on the same account, the model selection could be made > part of > the XEP-0004 form you already suggest in the document. The available > models > could be made part of a XEP-0128 extension, so that clients can basically > just > copy the form over and select a model. > > Other than that, I think this is an acceptable submission. The idea of > passing > along parameters using an embedded form to the model is novel and a good > one > in my opinion. > > kind regards, > Jonas_______________________________________________ > Standards mailing list -- standards(a)xmpp.org > Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s > _______________________________________________ >

1 0

UPDATED: XEP-0313 (Message Archive Management)
by Daniel Gultsch 12 Mar '24

12 Mar '24

Version 1.1.1 of XEP-0313 (Message Archive Management) has been released. Abstract: This document defines a protocol to query and control an archive of messages stored on a server. Changelog: Add XEP-0136 to superseded specifications (gdk) URL: https://xmpp.org/extensions/xep-0313.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 0

Remove requirement to send disco#info feature in XEP-0030
by Jonas Schäfer 12 Mar '24

12 Mar '24

Dear community, it's been a while I spoke up here. I would like to discuss the removal of the following part-sentence from XEP-0030 (in Final status!): > every entity MUST support at least the > 'http://jabber.org/protocol/disco#info' feature Announcing that feature is redundant: An entity which replies with a properly constructed `<query xmlns="http://jabber.org/protocol/disco#info"/>` element is bound to (and has always been bound to) have implemented XEP-0030 to the best of its knowledge. As this is a Final(!) status XEP, here is my estimate of the impact this change has: - Implementations which required the presence of this feature on the receiving side would now become non-compliant: They might assume that the remote entity did not really support XEP-0030 and fail with an error. Such implementations would need to be adapted in order to be able to interoperate with implementations which follow a revised version of XEP-0030. I don't see any other impact. I also strongly suspect that the set of implementations which follow XEP-0030 to the letter is rather slim (I only know of a single one, which would be the Rust XMPP library xmpp-rs [1]). The reason why this came up: There have in the past been cases ([2] and another, not-yet-filed issue against Prosody IM where the disco#info feature is missing from MUCs) where implementations didn't emit this feature. The seeming pointlessness and lack of information conveyed by this feature var make it easy to overlook and low-priority to fix. The fact that this has gone undiscovered for at least one Prosody IM release cycle further supports the assumption that the number of implementations which rely on that part of the spec is rather small. Your input is welcome. kind regards, Jonas Schäfer (these days without "special" role in the standards process) [1]: And there exists at least one fork which removed that check: https://gitlab.com/nesium/xmpp-rs/-/commit/1ddb050 [2]: https://issues.prosody.im/1664

9 11

UPDATED: XEP-0425: Moderated Message Retraction
by Daniel Gultsch 12 Mar '24

12 Mar '24

Hi, It’s the editor with a manual update here. Our tooling couldn’t process PRPOSED->EXPERIMENTAL and an update in the same step.¹ XEP-0425 was updated. Here is the change log. * Remove the dependency on XEP-0422 Message Fastening * Rename to 'Moderated Message Retraction' and focus only on the retraction use-case * Ensure compatibility with clients that only implement XEP-0424 * Clarify the purpose of the <reason/> element https://xmpp.org/extensions/xep-0425.html P.S.: 0424 was moved back to Experimental too. ¹: I’m aware of this now and will simply avoid this in the future

1 0

Proposed XMPP Extension: Message Displayed Synchronization
by daniel＠gultsch.de 11 Mar '24

11 Mar '24

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Displayed Synchronization Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats. URL: https://xmpp.org/extensions/inbox/xep-mds.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

4 4

XMPP Council Agenda 2024-03-12
by Daniel Gultsch 11 Mar '24

11 Mar '24

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, March 12 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 * Proposed XMPP Extension: Message Displayed Synchronization * LAST CALL: XEP-0392 (Consistent Color Generation) * LAST CALL: XEP-0360 (Nonzas (are not Stanzas)) and a bunch more updates. check your email 4) Items for voting a) Proposed XMPP Extension: Message Displayed Synchronization (https://xmpp.org/extensions/inbox/xep-mds.html) 5) Pending votes * Travis on XEP-0313: Add XEP-0136 to superseded specifications See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 0

UPDATED: XEP-0001 (XMPP Extension Protocols)
by Daniel Gultsch 11 Mar '24

11 Mar '24

Version 1.25.0 of XEP-0001 (XMPP Extension Protocols) has been released. Abstract: This document defines the standards process followed by the XMPP Standards Foundation. Changelog: Add note that editorial changes do not affect Deferred state (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0001.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 0

NEW: XEP-0489 (Reporting Account Affiliations)
by Daniel Gultsch 11 Mar '24

11 Mar '24

Version 0.1.0 of XEP-0489 (Reporting Account Affiliations) has been released. Abstract: This specification documents a way for an XMPP server to report to other entities the relationship it has with a user on its domain. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0489.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 0