[Standards] Proposed XMPP Extension: Disco Feature Attachment

Jonas Schäfer jonas at wielicki.name
Wed Aug 11 15:35:44 UTC 2021

Hi goffi,

Thanks for proposing this. The council has today vetoed the advancement for 
this ProtoXEP to Experimental, but I'd like to give you some feedback because 
I think the problem you're trying to address is real. The bottom of this email 
contains two recommendations from me which may allow us to solve the 
underlying issue.

I think this is a symptom of a problem with a certain subset of specifications 
of which RSM [XEP-0059] is the most well-known. They define a generic feature 
which can be applied to many other specifications. However, the interaction of 
that feature (e.g. RSM) with other specs (e.g. disco#items) is underspecified.

However, the proposed solution (including the variation proposed by singpolyma 
/ Stephen) is in my opinion not quite as useful as it might seem on the first 
glance, and might actually be harmful.

Here is why.

Even though it may seem obvious how to combine feature X (e.g. RSM) and 
feature Y (e.g. disco#info), it may not be obvious to everyone, so it should 
still be written down somewhere.

If the specification of the interaction is written down somewhere. If it is 
written down somewhere, that somewhere is an excellent place to put a 
disco#info feature string which can be used to identify that an entity 
supports this specific combination.

That means that there is no "need" for a generic way to combine two (or more) 
feature strings: there will always be a specification document to accompany 

Now what next?

We have the situation that RSM has a feature, but it may or may not be used in 
non-obvious ways with different endpoints and protocols. Most prominently, 
some MUC services require that you use RSM with disco#items if you want to 
list all MUCs, but you have no way to find out just from looking at 

This needs to be addressed. In this case, this should be written down in RSM 
itself or in a new document which specifies RSM + disco#info interaction. This 
is necessary, because XEP-0030 cannot be made to depend on RSM anymore, as it 
is final. So it needs to be an extension.

Another note of importance is that these extra feature strings only make sense 
for *optional* dependencies. They do not make sense for required dependencies. 
For instance, MAM has a hard dependency on RSM. It is thus not required that 
MAM services advertise support for MAM+RSM explicitly; there is simply no 
compliant implementation of MAM without RSM support.

>From this, one can infer that RSM should not ever have had a feature string. 
It is not useful: RSM only makes sense in combination with another protocol. 
That interaction with another protocol needs to be specified somewhere, either 
as required dependency (such as in the case of MAM) or as an optional 
dependency (such as in the case of XEP-0030 / disco#items, where a new feature 
needs to be defined and specified).

Under this premise (removing the RSM feature string), it makes no sense to 
have a way to combine it with anything explicitly.

However. It is useful for humans to understand feature strings from looking at 
them, at least crudely, for debugging and developing XMPP services. Thus, it 
would make sense for RSM to say something like:

> If a protocol uses RSM as an *optional* dependency, it SHOULD use the suffix 
> `#rsm-someversionmaybe?` composed with its own namespace URI as feature 
> string for XEP-0030 feature discovery.

And recommending this kind of wording for "generic" XEPs could go into an 
informational XEP. Either in a separate one, or it could be incorporated into 


- Either extend RSM or write a new document which specifies the interaction of 
- Extend XEP-0060 to add specific RSM features for the places where PubSub may 
support RSM.


- Add text to XEP-0143 like the above.
- Update XEP-0059 to include a notice like the one above.


- Do *not* include any specific feature for MAM+RSM, as MAM has a hard 
dependency on RSM and thus no extra feature is needed.

I think these recommendations are more sustainable, because they do not give 
the false impression

- that features can be combined arbitrarily and that it will be immediately 
obvious how they interact
- that all combinations of features need to be announced

Thank you for reading this long email.

kind regards,

   [XEP-0030]: https://xmpp.org/extensions/xep-0030.html
               Service Discovery
   [XEP-0059]: https://xmpp.org/extensions/xep-0059.html
               Result Set Management
   [XEP-0143]: https://xmpp.org/extensions/xep-0143.html
               Guidelines for Authors of XMPP Extension Protocols
-------------- 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/20210811/eee2a9e9/attachment.sig>

More information about the Standards mailing list