[Standards] UPDATED: XEP-0313 (Message Archive Management)
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. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
I think advice and a recommended course of action promotes interoperability, and is backwards compatible. XEP-0001 also says such modifications must be optional; obviously a SHOULD is not a MAY here, but I think it's fairly clear that a decision to assume that an entity not including disco#info within its disco#info response has ramifications which should properly be understood prior to doing so. IOW, I think this remains within the spirit, albeit not the letter, of the Final requirements. On Tue, 12 Mar 2024 at 10:33, Kevin Smith wrote: > I agree that a note would be helpful, but we're only noting that bugged > implementations exist, I don't think that even adding a SHOULD here > falls within the spirit of the Final requirements. So I think the right > thing to do is to add a note saying such bugs exist, but not change > normative language. > > /K > > > -- Original Message -- > From "Dave Cridland" > To "XMPP Standards" > Date 12/03/2024 09:59:33 > Subject [Standards] Re: Remove requirement to send disco#info feature in > XEP-0030 > > >As others have said, it's a wart. Any protocol has lots of them; XMPP > >has always had its fair share. (You mention XEP-0045 briefly, and we're > >all familiar that it's essentially a collection of warts at this > >stage). This one is not, as far as I can see, harmful in any meaningful > >way. > > > >As Tedd Sterr notes, removing the reporting of disco#info support via > >disco#info might leave no features at all, which might - small chance - > >mean that implementations hit bugs. > > > >I see no benefit to interoperability to remove it at this time. > > > >However, I could see the benefit of adding a note to the effect of: > > > >"Some entities are known not to advertise the > >"http://jabber.org/protocol/disco#info; feature within their responses, > >contrary to this specification. Entities receiving otherwise valid > >responses which do not include this feature SHOULD infer the support." > > > >Dave. > > > >On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer > >wrote: > >>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 `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___ > >>Standards mailing list -- standards@xmpp.org > >>To unsubscribe send an email to standards-le...@xmpp.org > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
I agree that a note would be helpful, but we're only noting that bugged implementations exist, I don't think that even adding a SHOULD here falls within the spirit of the Final requirements. So I think the right thing to do is to add a note saying such bugs exist, but not change normative language. /K -- Original Message -- From "Dave Cridland" To "XMPP Standards" Date 12/03/2024 09:59:33 Subject [Standards] Re: Remove requirement to send disco#info feature in XEP-0030 As others have said, it's a wart. Any protocol has lots of them; XMPP has always had its fair share. (You mention XEP-0045 briefly, and we're all familiar that it's essentially a collection of warts at this stage). This one is not, as far as I can see, harmful in any meaningful way. As Tedd Sterr notes, removing the reporting of disco#info support via disco#info might leave no features at all, which might - small chance - mean that implementations hit bugs. I see no benefit to interoperability to remove it at this time. However, I could see the benefit of adding a note to the effect of: "Some entities are known not to advertise the "http://jabber.org/protocol/disco#info; feature within their responses, contrary to this specification. Entities receiving otherwise valid responses which do not include this feature SHOULD infer the support." Dave. On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer wrote: 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 `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___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
On Tue, 12 Mar 2024 at 09:59, Dave Cridland wrote: > However, I could see the benefit of adding a note to the effect of: > > "Some entities are known not to advertise the > "http://jabber.org/protocol/disco#info; feature within their responses, > contrary to this specification. Entities receiving otherwise valid responses > which do not include this feature SHOULD infer the support." Agreed, I think this is the way to go. Regards, Matthew ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
If I understand the suggested change correctly, it's mostly a cosmetic one. That, to me, is not worth risking relaxing a definition/restriction that we made in 0001 (which is quite the core of what we're basing things on). I'm in camp "let's live with the wart". - Guus On Tue, Mar 12, 2024 at 10:59 AM Dave Cridland wrote: > As others have said, it's a wart. Any protocol has lots of them; XMPP has > always had its fair share. (You mention XEP-0045 briefly, and we're all > familiar that it's essentially a collection of warts at this stage). This > one is not, as far as I can see, harmful in any meaningful way. > > As Tedd Sterr notes, removing the reporting of disco#info support via > disco#info might leave no features at all, which might - small chance - > mean that implementations hit bugs. > > I see no benefit to interoperability to remove it at this time. > > However, I could see the benefit of adding a note to the effect of: > > "Some entities are known not to advertise the " > http://jabber.org/protocol/disco#info; feature within their responses, > contrary to this specification. Entities receiving otherwise valid > responses which do not include this feature SHOULD infer the support." > > Dave. > > On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer wrote: > >> 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 `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 >> ___ >> Standards mailing list -- standards@xmpp.org >> To unsubscribe send an email to standards-le...@xmpp.org >> > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
As others have said, it's a wart. Any protocol has lots of them; XMPP has always had its fair share. (You mention XEP-0045 briefly, and we're all familiar that it's essentially a collection of warts at this stage). This one is not, as far as I can see, harmful in any meaningful way. As Tedd Sterr notes, removing the reporting of disco#info support via disco#info might leave no features at all, which might - small chance - mean that implementations hit bugs. I see no benefit to interoperability to remove it at this time. However, I could see the benefit of adding a note to the effect of: "Some entities are known not to advertise the " http://jabber.org/protocol/disco#info; feature within their responses, contrary to this specification. Entities receiving otherwise valid responses which do not include this feature SHOULD infer the support." Dave. On Sun, 10 Mar 2024 at 16:27, Jonas Schäfer wrote: > 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 `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 > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] UPDATED: XEP-0425: Moderated Message Retraction
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 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 ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
