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 <[email protected]> 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 <[email protected]> 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 `<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 >> _______________________________________________ >> Standards mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
