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 <kevin.sm...@isode.com> 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" <d...@cridland.net> > To "XMPP Standards" <standards@xmpp.org> > 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 <jo...@wielicki.name> > >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 -- 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
