10 Mar
2024
10 Mar
'24
10:27 a.m.
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
10 Mar
10 Mar
6:18 p.m.
Somebody signing messages as Jonas Schäfer wrote:
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
I would support this change
11 Mar
11 Mar
3:51 a.m.
New subject: Remove requirement to send disco#info feature in XEP-0030
------ Original Message ------
From "Jonas Schäfer" <jonas(a)wielicki.name>
To standards(a)xmpp.org
Date 10/03/2024 16:27:07
Subject [Standards] Remove requirement to send disco#info feature in
XEP-0030
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!):
It seems to me that, although this has always seemed like a strange
wart, the fact that it might cause implementations to need to be updated
(whether such implementations are known of by The Internet or not),
making the change is inconsistent with the requirements of Final
(XEP-0001) so shouldn't be made.
/K
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.
4:50 a.m.
New subject: Remove requirement to send disco#info feature in XEP-0030
On 11 March 2024 10:51:39 CET, Kevin Smith <kevin.smith(a)isode.com> wrote:
[..]
It seems to me that, although this has always seemed like a strange wart, the fact that it
might cause implementations to need to be updated (whether such implementations are known
of by The Internet or not), making the change is inconsistent with the requirements of
Final (XEP-0001) so shouldn't be made.
/K
Agreed. This is a wart that we'll have to keep for hysterical raisins. 😉
--
ralphm
5:41 a.m.
On 10/03/2024 17.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
I agree that this is a wart of the specification, but personally, I am
not sure if the its worth fixing it. That said, I do not have a strong
opinion on that. However, I want to point out that…
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.
...there is another impact regarding the caps cache: the footprint of
the caps cache would increase, at least during the period where old
versions announce the feature, while the updated implementation may not.
Furthermore, implementations that persist the caps cache would end up
with more-or-less useless entries (which will eventually be pushed out
of the cache).
That itself is probably not a big deal, but it nicely demonstrates that
it is often hard to understand the full impact of a change.
Again, I do not favor removing it, nor do I want to keep it. But
personally, I feel like there is not much to gained by fixing this.
- Florian
9:30 a.m.
On Montag, 11. März 2024 12:41:17 CET Florian Schmaus wrote:
On 10/03/2024 17.27, Jonas Schäfer wrote:
I did actually consider that, but found it negligible; I wouldn't expect
implementations which already emit it to drop the disco#info feature
deliberately, or if they do, it's unlikely that it happens without other
changes which may in turn add/remove other feature vars anyway.
kind regards,
Jonas
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
I agree that this is a wart of the specification, but personally, I am
not sure if the its worth fixing it. That said, I do not have a strong
opinion on that. However, I want to point out that…
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.
...there is another impact regarding the caps cache: the footprint of
the caps cache would increase, at least during the period where old
versions announce the feature, while the updated implementation may not.
Furthermore, implementations that persist the caps cache would end up
with more-or-less useless entries (which will eventually be pushed out
of the cache).
That itself is probably not a big deal, but it nicely demonstrates that
it is often hard to understand the full impact of a change. 
9:48 a.m.
From XEP-0001, regarding Final XEPs, "limited modifications may be made as long as
they are optional, backwards-compatible extensions rather than modifications to the core
protocol itself."
XEP-0030 requires that entities return "one or more <identity/> elements and
one or more <feature/> elements", so the otherwise redundant
'disco#info' feature ensures this will always be the case, even in the (seemingly
unlikely) situation where an entity somehow supports disco#info without supporting any
additional features. So, is removing the requirement for this feature an optional,
backwards-compatible extension?
An obvious, and maybe more realistic, retort is "but will it break anything?"
So, would it cause problems for implementations if they were to receive a reply containing
zero features (since they were originally implemented expecting there will always be at
least one)? Equally, would implementations have problems calculating the caps hash
(XEP-0115) with zero features (the algorithm doesn't explicitly account for this)?
It's also worth considering whether leaving it as-is causes harm. It's nice
(desirable, even) to clean things and remove 'warts' like this, and there are
likely many more scattered throughout the protocol, so it's worth noting for XMPP 2.0,
but this has been the status quo for 22 years without being an issue.
As for benefits: many implementations would now be 'correct' for not complaining
when the feature isn't present (if implementations don't follow the specification,
just change the specification); and there is a minor reduction in data transferred from
having one less feature, though that's less notable where XEP-0115 is used (and there
may be an initial increase caused by most hashes now being unknown, until that settles.)
(Semi-relevant: https://github.com/xsf/xeps/pull/961 )
12 Mar
12 Mar
3:59 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
4:28 a.m.
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 <dave(a)cridland.net> 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 <jonas(a)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!):
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
4:28 a.m.
On Tue, 12 Mar 2024 at 09:59, Dave Cridland <dave(a)cridland.net> 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
4:32 a.m.
New subject: 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" <dave(a)cridland.net>
To "XMPP Standards" <standards(a)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(a)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(a)xmpp.org
>To unsubscribe send an email to standards-leave(a)xmpp.org
5:39 a.m.
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.smith(a)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" <dave(a)cridland.net>
To "XMPP Standards" <standards(a)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(a)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(a)xmpp.org
>To unsubscribe send an email to standards-leave(a)xmpp.org
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
68
days inactive
70
days old
11 comments
9 participants
participants (9)
-
Dave Cridland -
Florian Schmaus -
Guus der Kinderen -
Jonas Schäfer -
Kevin Smith -
Matthew Wild -
Ralph Meijer -
Stephen Paul Weber -
Tedd Sterr