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" <[email protected]>
To "XMPP Standards" <[email protected]>
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 <[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]
