&xep0030; is ubiquitous tools used by nearly every XMPP implementation. It's handy to declare that an entity implements a specific feature, but it can be confusing when a feature may be part of several functionalities. For instance, if a server advertise support &xep0059; and supports both &xep0163; and &xep0313;, we don't know if RSM is implemented only for PEP, only for MAM, or for both (it could be also implemented for other functionalities such as disco items).

In &xep0060; there is a workaround which proposes to use http://jabber.org/protocol/pubsub#rsm, but this solution doesn't tell if RSM is implemented for MAM or any other protocol, it is Pubsub specific and not extensible.

To fix this situation, this XEP proposes a simple way to advertise that a feature is implemented for a specific functionality.

It should be easy to implement Disco Feature Attachment both for the advertising entity and the requesting one, thus, the main requirement is to be based on &xep0030; without any other extensions.

• Attached Feature — feature being attached to a specific functionality (e.g.: &xep0059;).
• Root Namespace — the main namespace of attached feature, the one normally advertised with &xep0030; (e.g.: http://jabber.org/protocol/rsm)
• Target Feature — feature on which the attached feature is implemented (e.g.: &xep0060;).
• Target Namespace — namespace of the feature on which attached feature is implemented (e.g. http://jabber.org/protocol/pubsub)
• Attachment Namespace — namespace indicating that a feature is attached to an other one. (e.g. http://jabber.org/protocol/rsm@http://jabber.org/protocol/pubsub)

An XMPP server example.com wants to advertise support for &xep0059;, it is implemented for:

• &xep0030; (for discovering items)
• &xep0163;
• &xep0313;

To do that, the server MUST advertise the root namespace as usual (here http://jabber.org/protocol/rsm), and it MUST advertise the attachment namespace for every supported target feature:

An attachment namespace is build by concatenating those 3 strings

• the root namespace of the attached feature (e.g.: urn:xmpp:order-by:1)
• the character @
• the target namespace (e.g.: http://jabber.org/protocol/pubsub)

Here the resulting attachment namespace is urn:xmpp:order-by:1@http://jabber.org/protocol/pubsub and it means "the &xep0413; feature is implemented for &xep0060;".

If a functionality has several namespaces linked to it (e.g. &xep0060; has http://jabber.org/protocol/pubsub, http://jabber.org/protocol/pubsub#owner, http://jabber.org/protocol/pubsub#event, etc.), the one to be chosen it the one used for advertising with &xep0030; (here it's http://jabber.org/protocol/pubsub).

If attached feature is only implemented for part of a functionality, only the corresponding namespace must be used in attachment namespace (e.g. if RSM is implemented only for discovering items but not features, the attachment namespace to advertise is only http://jabber.org/protocol/rsm@http://jabber.org/protocol/disco#items).

If a XEP has special requirements regarding disco feature attachments, then they MAY be specified there, in which case they take precedence over the rules defined here.

If an entity supports the "Disco Feature Attachment" protocol, it MUST advertise it by including the "urn:xmpp:dfa:0" discovery feature &NSNOTE; in response to a &xep0030; information request:

This document introduces no security considerations or concerns above and beyond those discussed in RFC 6120 and RFC 6125.

This document requires no interaction with &IANA;.

TODO

TODO