This document makes several assumptions:

• The type of client I am using is of interest to the people in my roster.
• Clients for the people on my roster might want to make user interface decisions based on my capabilities.
• Different clients may support the same capabilities.
• 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 rosters.
• 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 XEP-0030.
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 &xep0060; 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 &xep0045; 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.

Entity capabilities are encapsulated in a <c/> element qualified by the 'http://jabber.org/protocol/caps' namespace. The attributes of the <c/> element are as follows:

In order to help prevent poisoning of entity capabilities information, the value of the 'ver' attribute MUST be generated according to the following method.

Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.

1. Initialize an empty string S.
2. Sort the service discovery identities by category and then by type, formatted as "category" "/" "type".
3. For each identity, append the category/type (if it exists) to S, followed by the '<' character.
4. Sort the supported features.
5. For each feature, append the feature to S, followed by the '<' character.
6. Compute ver by hashing S using the SHA-1 algorithm as specified in &rfc3174; (with binary output) and encoding the hash using Base64 as specified in Section 4 of &rfc4648;.

For example, consider an entity whose service discovery category is "client", whose service discovery type is "pc", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". The value of the 'ver' attribute would be generated as follows:

1. E = ''
2. Only one identity: client/pc
3. E = 'client/pc<'
4. Sort the features: "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".
5. E = 'client/pc<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'
6. ver = 8RovUdtOmiAjzj+xI7SK5BCw3A8=

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 send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.

If two entities exchanges messages but they do not normally exchange presence (i.e., via presence subscription), the entities MAY choose to send directed presence to each other, where the presence information SHOULD be annotated with the same capabilities information as each entity sends in broadcasted presence. 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 XEP-0030: Service Discovery for a list of potential service discovery error codes.

Use of the protocol specified in this document 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 &xep0016; 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").

Adherence to the algorithm defined in the Generation of ver Attribute sectio of this document helps to guard against poisoning of entity capabilities information by malicious or improperly implemented entities.

This document requires no interaction with &IANA;.

Before Version 1.4 of this specification, the 'node' attribute was required, the 'ver' attribute was generated differently, and the 'ext' attribute was used more extensively. For historical purposes, Version 1.3 of this specification is archived at <http://www.xmpp.org/extensions/attic/xep-0115-1.3.html>. For backward-compatibility with the legacy format, the 'node' attribute is REQUIRED and the 'ext' attribute MAY be included.

Thanks to Rachel Blackman, Dave Cridland, Richard Dobson, Sergei Golovan, Justin Karneges, Jacek Konieczny, Ian Paterson, Kevin Smith, Tomasz Sterna, and Michal Vaner for comments and suggestions.