[Standards] PR#716: XEP-0030: Clarify 'disco#info' feature in 'disco#info' responses

Jonas Schäfer jonas at wielicki.name
Thu Nov 8 16:54:46 UTC 2018

@flowdalic wrote:
> Strictly speaking, every disco#info IQ result must contain the
> disco#info feature. But looking at the existing examples in various
> XEPs and implementations, this feature is usually omitted. Hence we
> clarify in XEP-0030 that announcing the 'disco#info' feature is
> optional, as support for it is implicitly acknowledged by returning a
> result IQ to a 'disco#info' IQ request.
> After thinking about the situation a while, this is currently my preferred 
> solution. But I am not sure if it may causes issues regarding entity 
> capabilities 1.0 and 2.0 (Should 'disco#info' be part of the hash input or 
> not? Probably it should.) . Hence it possibly deserves some discussion by 
> the community and by council.
> For a motivation see
>     * #715
>     * [processone/ejabberd#2661](https://github.com/processone/ejabberd/

Bringing it to the list so that people can take a look.

Personally, I am firmly against this. From a process point of view, making 
this change in a Final XEP would not be ideal.

I don’t see a reason why we have to do this. Just because some implementations 
out there are broken is not enough.

The argument that "the feature is implicit in the fact that the entity 
replies" is more interesting, but I don't think that it's warranted to change 
a Final XEP for a rather cosmetic issue.

As @flowdalic pointed out, this also creates ambiguities with XEP-0115, 
XEP-0390 and possibly other specifications. I think adding ambiguities is 
*not* what we should be doing. XEP-0030 is clear and unambiguous regarding the 
presence of the disco#info feature. We should keep it that way.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20181108/87ba52fb/attachment.sig>

More information about the Standards mailing list