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" <dave@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 <jonas@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-leave@xmpp.org
_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org