It is often desirable for a Jabber/XMPP application (commonly but not necessarily a client) to take different actions depending on the capabilities of another application from which it receives presence information. Examples include:

• Showing a different set of icons depending on the capabilities of other clients.
• Not sending &jep0071; content to plaintext clients such as cell phones.
• Allowing the initiation of Voice over IP (VoIP) sessions only to clients that support VoIP.
• Not showing a "Send a File" button if another user's client does not support &jep0096;.

Recently, some existing Jabber clients have begun sending &jep0092; requests to each entity from which they receive presence. That solution is impractical on a larger scale, particularly for users or applications with large rosters. This JEP proposes a more robust and scalable solution: namely, a presence-based mechanism for exchanging information about entity capabilities. This proposal is not limited to clients, and could be used by any entity that exchanges presence with another entity, e.g., a gateway. However, this JEP uses the example of clients throughout.

This JEP makes several assumptions:

• The type of client I am using is of interest to the people on my roster.
• Clients for the people on my roster might want to make user interface decisions based on my capabilities.
• Different instances of the same client (including version) have the same base capabilities.
• Some clients will have bundles of functionality that can be enabled and disabled.
• One instance of a given client may not know about all of the possible bundles of functionality that can be enabled and disabled (for example, plugins written to a client SDK).
• Members of a community tend to cluster around a small set of clients. More specifically, multiple people in my roster use the same client, and they upgrade versions relatively slowly (commonly a few times a year, perhaps once a week at most, certainly not once a minute).
• Some clients are running against servers without server-to-server connectivity enabled, and without access to the Internet via HTTP.
• Conversations are possible between users who are not on each other's roster.
• Client capabilities may change over the course of a session, due to features being enabled and disabled.

The protocol defined herein addresses the following requirements:

1. Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and &jep0030;.
2. Clients MUST be able to participate even if they are on networks without connectivity to other XMPP servers, services offering specialized XMPP extensions, or HTTP servers.These first two requirements effectively eliminated &jep0060; as a possible implementation of entity capabilities.
3. Clients MUST be able to retrieve information without querying each user.
4. Since presence is normally broadcasted to many users, the byte size of the proposed extension MUST be as small as possible.
5. It MUST be possible to write a &jep0045; implementation that passes the given information along.
6. It MUST be possible to publish a change in capabilities within a single session.
7. Server infrastructure above and beyond that defined in XMPP Core and XMPP IM MUST NOT be required for this approach to work, although additional server infrastructure MAY be used for optimization purposes.

A server that is managing an entity's session MAY choose to optimize traffic through the server. In this case, the server MAY strip off redundant capabilities annotations. Because of this, receivers of annotations MUST NOT expect an annotation on every presence packet they receive. If the server wants to perform this traffic optimization, it MUST ensure that the first presence each subscriber receives contains the annotation. The server MUST also ensure that any changes in the annotation (typically in the 'ext' attribute) are sent to all subscribers.

A client MAY query the server using disco#info to determine if the server supports the 'http://jabber.org/protocol/caps' feature. If so, the server MUST perform the optimization delineated above, and the client MAY choose to only send the capabilities annotation on the first presence packet, as well as whenever its capabilities change.

If capabilities information has not been received from another entity, an application MUST assume that the other entity does not support capabilities.

No application-specific error codes are defined by this document. See JEP-0030: Service Discovery for a list of potential service discovery error codes.

Use of the protocol specified in this JEP might make some client-specific forms of attack slightly easier, since the attacker could more easily determine the type of client being used. However, since most clients respond to jabber:iq:version requests without performing access control checks, there is no new vulnerability. Entities that wish to restrict access to capabilities information SHOULD use the privacy lists protocol defined in XMPP IM to define appropriate communications blocking (e.g., an entity MAY choose to allow IQ requests only from "trusted" entities, such as those with whom it has a subscription of "both").

It is possible (though unlikely) for a bad actor or rogue application to poison other entities by providing incorrect information in response to disco#info requests. To guard against such poisoning, a requesting entity MAY send disco#info requests to multiple entities that match the same node/ver or node/ext combination and then compare the results to ensure consistency. The requesting entity SHOULD NOT send the same request to more than five entities and MUST ensure that the entities are truly different by not sending the same request to multiple entities for which the <user@host> portion matches.

This JEP requires no interaction with &IANA;.

Upon advancement of this JEP to a status of Draft, the ®ISTRAR; shall add 'http://jabber.org/protocol/caps' to its registries of protocol namespaces and service discovery features.

If it is useful or interesting, the Registrar may also provide registration of the URIs to be used in the 'node' attribute, but since these URIs can be scoped according to well-defined existing rules, this is not necessary.