XEP-0115: Entity Capabilities
XEP-0115: Entity Capabilities
Abstract
This document defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions, and the format has been kept as small as possible.
Authors
Joe Hildebrand
Peter Saint-Andre
Remko Tronçon
Jacek Konieczny
SEE LEGAL NOTICES
Status
Stable
NOTICE: The protocol defined herein is a
Stable Standard
of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.
Type
Standards Track
Version
1.6.0 (2022-03-08)
Document Lifecycle
Experimental
Proposed
Stable
Final
1.
Introduction
1.1 Motivation
It is often desirable for an 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 entities.
Not sending
XHTML-IM (XEP-0071)
] or other rich content to plaintext clients such as cell phones.
Allowing the initiation of a Voice over IP (VoIP) session only to clients that support
Jingle (XEP-0166)
] and
Jingle RTP Sessions (XEP-0167)
].
Not showing a "Send a File" button if another user's client does not support
SI File Transfer (XEP-0096)
].
Filtering
Publish-Subscribe (XEP-0060)
] notifications based on advertised subscriber interests.
In the past, after logging in some Jabber clients sent one
Service Discovery (XEP-0030)
] and one
Software Version (XEP-0092)
] request to each entity from which they received presence. That "disco/version flood" resulted in an excessive use of bandwidth and was impractical on a larger scale, particularly for users with large rosters. Therefore this document defines a more robust and scalable solution: namely, a presence-based mechanism [
] for exchanging information about entity capabilities. Clients should not engage in the older "disco/version flood" behavior and instead should use Entity Capabilities as specified herein.
1.2 How It Works
This section provides a friendly introduction to entity capabilities ("caps").
Imagine that you are a Shakespearean character named Juliet and one of your contacts, a handsome fellow named Romeo, becomes available. His client wants to publish its capabilities, and does this by adding to its presence packets a
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
The 'node' attribute represents the client software Romeo is using. The 'ver' attribute is a specially-constructed string (called a "verification string") that represents the entity's service discovery identity (category and type as registered at <
>, as well as, optionally, xml:lang and name) and supported features (as registered at <
> as well as, optionally, extended service discovery information data registered at <
>).
At this point, your client has no idea what the capabilities are of someone with a verification string 'QgayPKawpkPSDYmwT/WM94uAlu0='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.
to='romeo@montague.lit/orchard'
type='get'>
The response is:
to='juliet@capulet.lit/chamber'
type='result'>
At this point, your client knows that a contact who advertises a verification string of 'QgayPKawpkPSDYmwT/WM94uAlu0=' supports
Multi-User Chat (XEP-0045)
] and the other features returned by Romeo because the contact in fact uses the same version of the same client software as Romeo, with the same enabled features, plugins, presented client name(s), and the like (i.e., the same input to the verification string
generation method
). [
10
] Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same verification string. For example, your Nurse may use the same client that Romeo does:
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
Therefore you know that she also supports the same features that Romeo does.
On the other hand, for a person with the following presence ...
node='http://psi-im.org'
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
... or the following presence ...
node='http://www.chatopus.com'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
... you have no information about what this contact's client is capable of unless you have cached previous entity capabilities information; therefore you need to query for capabilities explicitly again via service discovery.
2.
Assumptions
This document makes several assumptions:
The identity of the 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.
Members of a community tend to cluster around a small set of clients with a small set of capabilities. 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 on networks 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 presence session, as features are enabled or disabled.
3.
Requirements
The protocol defined herein addresses the following requirements:
Clients must be able to participate even if they support only
XMPP Core
11
],
XMPP IM
12
], and
Service Discovery (XEP-0030)
].
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. [
13
Clients must be able to retrieve information without querying every entity with which they communicate.
Since presence is normally broadcast to many contacts, the byte size of the proposed extension must be as small as possible.
It must be possible to write a XEP-0045 server implementation that passes the given information along.
It must be possible to publish a change in capabilities within a single presence session.
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.
The defined mechanism must not be limited to clients but must be usable by servers, components, and other network entities.
4.
Protocol
Entity capabilities are encapsulated in a
Table 1:
Attributes
Name
Definition
Inclusion
ext
A set of nametokens specifying additional feature bundles; this attribute is deprecated (see the
Legacy Format
section of this document).
DEPRECATED
hash
The hashing algorithm used to generate the verification string; see
Mandatory-to-Implement Technologies
regarding supported hashing algorithms.
REQUIRED
node
A URI that uniquely identifies a software application, typically a URL at the website of the project or company that produces the software. *
REQUIRED
ver
A string that is used to verify the identity and supported features of the entity. **
REQUIRED
* Note: It is RECOMMENDED for the value of the 'node' attribute to be an HTTP URL at which a user could find further information about the software product, such as "http://psi-im.org" for the Psi client; this enables a processing application to also determine a unique string for the generating application, which it could maintain in a list of known software implementations (e.g., associating the name received via the disco#info reply with the URL found in the caps data).
** Note: Before version 1.4 of this specification, the 'ver' attribute was used to specify the released version of the software; while the values of the 'ver' attribute that result from use of the algorithm specified herein are backwards-compatible, applications SHOULD appropriately handle the
Legacy Format
5.
Verification String
5.1 Generation Method
In order to help prevent poisoning of entity capabilities information, the value of the verification string 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
RFC 4790
14
].
Initialize an empty string S.
Sort the service discovery identities [
15
] by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. [
16
] Note that each slash is included even if the LANG or NAME is not included (in accordance with
Service Discovery (XEP-0030)
], the category and type MUST be included).
For each identity, append the 'category/type/lang/name' to S, followed by the '<' character.
Sort the supported service discovery features. [
17
For each feature, append the feature to S, followed by the '<' character.
If the service discovery information response includes
Service Discovery Extensions (XEP-0128)
18
] data forms, sort the forms by the FORM_TYPE (i.e., by the XML character data of the
For each extended service discovery information form:
Append the XML character data of the FORM_TYPE field's
Sort the fields by the value of the "var" attribute.
For each field other than FORM_TYPE:
Append the value of the "var" attribute, followed by the '<' character.
Sort values by the XML character data of the
For each
Ensure that S is encoded according to the UTF-8 encoding (
RFC 3629
19
]).
Compute the verification string by hashing S using the algorithm specified in the 'hash' attribute (e.g., SHA-1 as defined in
RFC 3174
20
]). The hashed data MUST be generated with binary output and encoded using Base64 as specified in Section 4 of
RFC 4648
21
] (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). [
22
Note: If the four characters '&', 'l', 't', ';' appear consecutively in any of the factors of the verification string S (e.g., a service discovery identity of 'SomeClient<http://jabber.org/protocol/muc') then that string of characters MUST be treated as literally '<' and MUST NOT be converted to the character '<', because completing such a conversion would open the protocol to trivial attacks.
5.2 Simple Generation Example
Consider an entity whose category is "client", whose service discovery type is "pc", whose service discovery name is "Exodus 0.9.1", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):
S = ''
Only one identity: "client/pc"
S = 'client/pc//Exodus 0.9.1<'
Sort the features: "http://jabber.org/protocol/caps", "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".
S = 'client/pc//Exodus 0.9.1
5.3 Complex Generation Example
Consider a more complex example, where the entity includes several identities (with the service discovery name in different languages) as well as extended information formatted according to
Service Discovery Extensions (XEP-0128)
18
].
to='juliet@capulet.lit/chamber'
type='result'>
Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):
S = ''
Two identities: "client/pc/Psi" and "client/pc/Ψ"
S = 'client/pc/el/Ψ 0.11
S = 'client/pc/el/Ψ 0.11
S = 'client/pc/el/Ψ 0.11
5.4 Processing Method
When an entity receives a value of the 'ver' attribute that appears to be a verification string generated in accordance with the generation method defined in this specification, it MUST process the 'ver' according to the following method.
Verify that the
Legacy Format
(if supported).
If the value of the 'hash' attribute does not match one of the processing application's supported hash functions, do the following:
Send a service discovery information request to the generating entity.
Receive a service discovery information response from the generating entity.
Do not validate or globally cache the verification string as described below; instead, the processing application SHOULD associate the discovered identity+features
only
with the JabberID of the generating entity.
If the value of the 'hash' attribute matches one of the processing application's supported hash functions, validate the verification string by doing the following:
Send a service discovery information request to the generating entity.
Receive a service discovery information response from the generating entity.
If the response includes more than one service discovery identity with the same category/type/lang/name, consider the entire response to be ill-formed.
If the response includes more than one service discovery feature with the same XML character data, consider the entire response to be ill-formed.
If the response includes more than one extended service discovery information form with the same FORM_TYPE or the FORM_TYPE field contains more than one
If the response includes an extended service discovery information form where the FORM_TYPE field is not of type "hidden" or the form does not include a FORM_TYPE field, ignore the form but continue processing.
If the response is considered well-formed, reconstruct the hash by using the service discovery information response to generate a local hash in accordance with the
Generation Method
).
If the values of the received and reconstructed hashes match, the processing application MUST consider the result to be valid and SHOULD globally cache the result for all JabberIDs with which it communicates.
If the values of the received and reconstructed hashes do not match, the processing application MUST consider the result to be invalid and MUST NOT globally cache the verification string; however, it SHOULD check the service discovery identity and supported features of another generating entity who advertises that value.
Note: If the four characters '&', 'l', 't', ';' appear consecutively in any of the factors of the verification string S (e.g., a service discovery identity of 'SomeClient<http://jabber.org/protocol/muc') then that string of characters MUST be treated as literally '<' and MUST NOT be converted to the character '<', because completing such a conversion would open the protocol to trivial attacks.
6.
Use Cases
6.1 Advertising Capabilities
Each time a generating entity sends presence, it annotates that presence with an entity identifier ('node' attribute) and identity and feature identifier ('ver' attribute). So that servers can remember the last presence for use in responding to probes, a client SHOULD include entity capabilities with every presence notification it sends.
Example 1.
Presence with caps
node='http://code.google.com/p/exodus'
ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
If the supported features change during a generating entity's presence session (e.g., a user installs an updated version of a client plugin), the application MUST recompute the verification string and SHOULD send a new presence broadcast.
Example 2.
Presence with recomputed ver attribute
node='http://code.google.com/p/exodus'
ver='66/0NaeaBKkwk85efJTGmU47vXI='/>
6.2 Discovering Capabilities
An application (the "requesting entity") can learn what features another entity supports by sending a disco#info request (see
Service Discovery (XEP-0030)
]) to the entity that generated the caps information (the "generating entity").
Example 3.
Disco#info request
to='romeo@montague.lit/orchard'
type='get'>
The disco#info request is sent by the requesting entity to the generating entity. The value of the 'to' attribute MUST be the exact JID of the generating entity, which in the case of a client will be the full JID
Note: The generating entity SHOULD NOT include the "caps node" in the list of entities it returns in its disco#items responses; i.e., the caps node is a kind of virtual or phantom node, not a true items node that is associated with the generating entity for service discovery purposes.
The disco 'node' attribute MUST be included for backwards-compatibility. The value of the 'node' attribute SHOULD be generated by concatenating the value of the caps 'node' attribute (e.g., "http://code.google.com/p/exodus") as provided by the generating entity, the "#" character, and the value of the caps 'ver' attribute (e.g., "QgayPKawpkPSDYmwT/WM94uAlu0=") as provided by the generating entity.
The generating entity then returns all of the capabilities it supports.
Example 4.
Disco#info response
to='juliet@capulet.lit/balcony'
type='result'>
Note: If the generating entity incorporated multiple identities with different xml:lang values in its verification string, it MUST return all of the identities even if the request specified a particular xml:lang.
6.3 Stream Feature
A server MAY include its entity capabilities in a stream feature element so that connecting clients and peer servers do not need to send service discovery requests each time they connect.
Example 5.
Stream feature element including capabilities
node='http://jabberd.org'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
When a connected client or peer server sends a service discovery information request to determine the entity capabilities of a server that advertises capabilities via the stream feature, the requesting entity MUST send the disco#info request to the server's JID as provided in the 'from' attribute of the response stream header (the 'from' attribute was recommended by
RFC 3920
23
] and is required by
RFC 6120
11
]). To enable this functionality, a server that advertises support for entity capabilities MUST provide a 'from' address in its response stream headers, in accordance with
RFC 6120
11
].
7.
Determining Support
If an entity supports the entity capabilities protocol, it MUST advertise that fact by returning a feature of
'http://jabber.org/protocol/caps'
in response to a service discovery information request.
Example 6.
Service discovery information request
to='juliet@capulet.lit/balcony'
type='get'>
Example 7.
Service discovery information response
to='romeo@montague.lit/orchard'
type='result'>
...
...
If a server supports the
Caps Optimization
functionality, it MUST also return a feature of
'http://jabber.org/protocol/caps#optimize'
in response to service discovery information requests.
Example 8.
Service discovery information request
to='capulet.lit'
type='get'>
Example 9.
Service discovery information response
to='juliet@capulet.lit/balcony'
type='result'>
...
...
8.
Implementation Notes
8.1 Hashing Algorithm Support
An application SHOULD maintain a list of hashing algorithms it supports, which MUST include the algorithm or algorithms listed in the
Mandatory-to-Implement Technologies
section of this document.
8.2 Caching
It is RECOMMENDED for an application that processes entity capabilities information to cache associations between the verification string and discovered identity+features within the scope of one presence session. This obviates the need for extensive service discovery requests within a session.
It is RECOMMENDED for an application to cache associations across presence sessions, since this obviates the need for extensive service discovery requests at the beginning of a session (this is especially helpful in bandwidth-constrained environments).
8.3 Directed Presence
If two entities exchange 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 presence broadcasts. Until and unless capabilities information has been received from another entity, an application MUST assume that the other entity does not support capabilities.
8.4 Caps Optimization
A server that is managing an connected client's presence session MAY optimize presence notification traffic sent through the server by stripping off redundant capabilities annotations (i.e., the
If a connected client determines that its server supports caps optimization, it MAY choose to send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.
9.
Security Considerations
9.1 Mandatory-to-Implement Technologies
The SHA-1 hashing algorithm is mandatory to implement. All implementations MUST support SHA-1.
An implementation MAY support other algorithms. Any such algorithm SHOULD be registered in the
IANA Hash Function Textual Names Registry
24
].
In the future, the
XMPP Council
25
] may, at its discretion, modify the mandatory-to-implement hashing algorithm if it determines that SHA-1 has become practically vulnerable to
Preimage Attacks
9.2 Preimage Attacks
As described in
RFC 4270
26
], protocols that use the output of hash functions such as MD5 or SHA-1 can be vulnerable to collision attacks or preimage attacks or both. Because of how the hash output is used in entity capabilities, the protocol will not be subject to collision attacks even if the hash function used is found to be vulnerable to collision attacks. However, it is
possible
that the protocol might become subject to preimage attacks if the hash function used is found to be vulnerable to preimage attacks.
In theory, such a preimage attack would take one of the following forms:
Given knowledge of a particular value V of the 'ver' attribute, an attacker can find an input message X such that hash(X) yields V (this is known as a "first preimage attack").
Given knowledge of a particular value S used as the input message to the hash function, an attacker can find a value S' that yields V (this is known as a "second preimage attack").
In practice, a preimage attack would need to meet all of the following criteria in order to be effective against the entity capabilities protocol:
The hashing algorithm used would need to be found not only theoretically but practically vulnerable to first or second preimage attacks (e.g., this is not yet true of the MD5 or SHA-1 algorithms, but may become true in the future).
An attacker would need to find an input message X or S' that matches the hash V for a particular value of V or S, which may not be practical given that (a) the values of S used as input to the hash function in entity capabilities are relatively short and (b) cryptanalysis to date indicates that existing hash functions may not be vulnerable to preimage attacks except in the case of relatively long input messages (on the order of 2
55
blocks).
The input message X or S' would need to conform to the structure of S as specified under
Verification String
, including the order of service discovery identity or identities followed by service discovery features, delimited by the '<' character and sorted using "i;octet" collation.
The input messsage X or S' would need to make it seem as if a desirable feature (e.g., end-to-end encryption) is not supported by other entities that advertise the same hash V even though the feature is indeed supported (i.e., the attacker would need to return a set of service discovery identities and features that match X or S', and have that set be plausible for an entity that communicates via XMPP), or make it seem as if an undesirable feature is supported even though the feature is not supported.
The attacker would need to propagate the hash V before some other entity with the true input message S could broadcast presence with the relevant entity capabilities data and provide the true service discovery response (thus the attacker might need to subvert the development process of a particular software project or subvert the namespace issuance process of the
XMPP Registrar
27
], or both).
It currently seems extremely unlikely that an attacker could meet all of the foregoing conditions in the foreseeable future. However, the XMPP Council shall continue to monitor the state of cryptanalysis regarding the mandatory-to-implement hash function as well as the possibility that any vulnerabilities in that function might lead to practical threats against the entity capabilities protocol. If and when it becomes practical (or even possible) to launch effective preimage attacks against the entity capabilities protocol, the XMPP Council shall consider updating this specification to change the mandatory-to-implement hashing algorithm to a safer technology.
Note: If the four characters '&', 'l', 't', ';' appear consecutively in any of the factors of the verification string S (e.g., a service discovery identity of 'SomeClient<http://jabber.org/protocol/muc') then that string of characters MUST be treated as literally '<' and MUST NOT be converted to the character '<', because completing such a conversion would open the protocol to trivial attacks.
9.3 Caps Poisoning
Adherence to the method defined in the
Verification String
section of this document for processing of the 'ver' attribute is known to be vulnerable to certain cache poisoning attacks that can not be fixed in a backwards compatible manner [
28
].
If the value of the 'ver' attribute is a verification string as defined herein (i.e., if the 'ver' attribute is not generated according to the
Legacy Format
), inclusion of the 'hash' attribute is REQUIRED. Knowing explicitly that the value of the 'ver' attribute is a verification string enables the recipient to avoid spurious notification of invalid or poisoned hashes.
9.4 Information Exposure
Use of entity capabilities might make it easier for an attacker to launch certain application-specific attacks, since the attacker could more easily determine the type of client being used as well as its capabilities. However, since most clients respond to Service Discovery and Software Version requests without performing access control checks, there is no new vulnerability. Entities that wish to restrict access to capabilities information SHOULD use
Privacy Lists (XEP-0016)
29
] 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 presence subscription of "both"); note, however, that such restrictions may be incompatible with the recommendation regarding
Directed Presence
10.
IANA Considerations
This document requires no interaction with the
Internet Assigned Numbers Authority (IANA)
30
].
11.
XMPP Registrar Considerations
11.1 Protocol Namespaces
The
XMPP Registrar
27
] includes "http://jabber.org/protocol/caps" in its registry of protocol namespaces (see <
>).
11.2 Service Discovery Features
The XMPP Registrar includes "http://jabber.org/protocol/caps" and "http://jabber.org/protocol/caps#optimize" in its registry of service discovery features (see <
>).
11.3 Stream Features
The XMPP Registrar includes "http://jabber.org/protocol/caps" in its registry of stream features (see <
>).
12.
XML Schema
targetNamespace='http://jabber.org/protocol/caps'
xmlns='http://jabber.org/protocol/caps'
elementFormDefault='qualified'>
The protocol documented by this schema is defined in
XEP-0115: http://www.xmpp.org/extensions/xep-0115.html
13.
Legacy Format
Before Version 1.4 of this specification, the 'ver' attribute was generated differently, the 'ext' attribute was used more extensively, and the 'hash' attribute was absent. For historical purposes, Version 1.3 of this specification is archived at <
>. For backwards-compatibility with the legacy format, the 'node' attribute is REQUIRED and the 'ext' attribute MAY be included.
An application can determine if the legacy format is in use by checking for the presence of the 'hash' attribute, which is REQUIRED in the current format.
If a caps-processing application supports the legacy format, it SHOULD check the 'node', 'ver', and 'ext' combinations as specified in the archived version 1.3 of this specification, and MAY cache the results.
If a caps-processing application does not support the legacy format, it SHOULD ignore the 'ver' value entirely (since the value cannot be verified) and SHOULD NOT cache it, since the application cannot validate the identity and features by checking the hash.
14.
Acknowledgements
Thanks to Rachel Blackman, Dave Cridland, Richard Dobson, Olivier Goffart, Sergei Golovan, Justin Karneges, Ralph Meijer, Ian Paterson, Kevin Smith, Tomasz Sterna, Michal Vaner, and Matt Yacobucci for comments and suggestions.
Appendices
Appendix A: Document Information
Series
XEP
Number
0115
Publisher
XMPP Standards Foundation
Status
Stable
Type
Standards Track
Version
1.6.0
2022-03-08
Approving Body
XMPP Council
Dependencies
XMPP Core, XMPP IM,
XEP-0030
Supersedes
None
Superseded By
None
Short Name
caps
Schema
Source Control
HTML
This document in other formats:
XML
PDF
Appendix B: Author Information
Joe Hildebrand
Email
jhildebr@cisco.com
JabberID
hildjj@jabber.org
Peter Saint-Andre
Email
stpeter@stpeter.im
JabberID
stpeter@jabber.org
URI
Remko Tronçon
URI
Jacek Konieczny
Email
jajcus@jajcus.net
JabberID
jajcus@jabber.bnet.pl
Appendix C: Legal Notices
This XMPP Extension Protocol is copyright © 1999 – 2024 by the
XMPP Standards Foundation
(XSF).
Permissions
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
Disclaimer of Warranty
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
Limitation of Liability
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
IPR Conformance
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <
> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
Visual Presentation
The HTML representation (you are looking at) is maintained by the XSF. It is based on the
YAML CSS Framework
, which is licensed under the terms of the
CC-BY-SA 2.0
license.
Appendix D: Relation to XMPP
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
Appendix E: Discussion Venue
The primary venue for discussion of XMPP Extension Protocols is the <
standards@xmpp.org
> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <
> for a complete list.
Errata can be sent to <
editor@xmpp.org
>.
Appendix F: Requirements Conformance
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in
BCP 14
RFC2119
RFC8174
] when,
and only when, they appear in all capitals, as shown here.
Appendix G: Notes
. XEP-0071: XHTML-IM <
>.
. XEP-0166: Jingle <
>.
. XEP-0167: Jingle RTP Sessions <
>.
. XEP-0096: SI File Transfer <
>.
. XEP-0060: Publish-Subscribe <
>.
. XEP-0030: Service Discovery <
>.
. XEP-0092: Software Version <
>.
. Entity capabilities is not limited to clients, and can be used by any entity that exchanges presence with another entity, e.g., a gateway. However, this specification mainly uses the example of clients.
. XEP-0045: Multi-User Chat <
>.
10
. The string can be relied upon because of how it is generated and checked, as explained later in this document.
11
. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <
>.
12
. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <
>.
13
. These first two requirements effectively eliminated
Publish-Subscribe (XEP-0060)
] as a possible implementation of entity capabilities.
14
. RFC 4790: Internet Application Protocol Collation Registry <
>.
15
. A registry of service discovery identities is located at <
>.
16
. The combination of category, type, and xml:lang forms a unique combination, so it is not necessary to also sort by name (the name merely provides some human-readable text associated with a category/type/lang).
17
. A registry of service discovery features is located at <
>.
18
. XEP-0128: Service Discovery Extensions <
>.
19
. RFC 3629: UTF-8, a transformation format of ISO 10646 <
>.
20
. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <
>.
21
. RFC 4648: The Base16, Base32, and Base64 Data Encodings <
>.
22
. The OpenSSL command for producing such output with SHA-1 is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".
23
. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <
>.
24
. IANA registry of Hash Function Textual Names <
>.
25
. The XMPP Council is a technical steering committee, authorized by the XSF Board of Directors and elected by XSF members, that approves of new XMPP Extensions Protocols and oversees the XSF's standards process. For further information, see <
>.
26
. RFC 4270: Attacks on Cryptographic Hashes in Internet Protocols <
>.
27
. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <
>.
28
[Security] Trivial preimage attack against the entity capabilities protocol
29
. XEP-0016: Privacy Lists <
>.
30
. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <
>.
Appendix H: Revision History
Note: Older versions of this specification might be available at
Version
1.6.0
(2022-03-08)
Mention preimage attacks explicitly
ssw
Version
1.5.2
(2020-05-05)
fix complex generation example by adding missing form field type
fs
Version
1.5.1
(2016-10-06)
Added registrar consideration about stream features.
egp
Version
1.5
(2008-02-26)
Defined SHA-1 as mandatory to implement
Specified that inclusion of hash attribute is required
Defined the nature of possible preimage attacks
More clearly specified security considerations
More clearly specified implementation notes
Modified generation method to incorporate service discovery extensions
More clearly specified processing method
Clarified meaning and construction of caps node attribute and disco node attribute
Specified that node attribute shall be included in disco#info request for backwards-compatibility
Clarified handling of the legacy format to assist developers
Added service discovery feature for caps optimization to prevent confusion regarding server support of caps vs. caps optimization
jjh/psa
Version
1.4
(2007-08-13)
In response to persistent security concerns over caps poisoning, redefined ver attribute to be a hash of the service discovery identity and features in a way that is backwards-compatible with the legacy format.
psa/jk/jjh
Version
1.3
(2007-04-10)
Added developer-friendly introduction; specified that ext names must be stable across application versions; further clarified examples; added stream feature use case; removed message example (send directed presence instead).
psa/rt/jjh
Version
1.2
(2007-02-15)
Clarified motivation and handling of service discovery requests.
psa
Version
1.1
(2004-10-29)
Clarified meaning of service discovery results for client#ver and client#ext.
psa
Version
1.0
(2004-08-01)
Per a vote of the Jabber Council, advanced status to Draft.
psa
Version
0.7
(2004-06-29)
Added several items to the Security Considerations; clarified naming requirements regarding 'node', 'ver', and 'ext' attributes.
jjh/psa
Version
0.6
(2004-04-25)
Made a number of editorial adjustments.
psa
Version
0.5
(2004-01-05)
Specified that the protocol can be used whenever presence is used (e.g., by gateways); improved the XML schema; made several editorial adjustments.
psa
Version
0.4
(2003-09-04)
IQ eets must be to a resource, since they are intended to go to a particular session.
jjh
Version
0.3
(2003-09-02)
Servers MUST strip extras changed to MAY, due to implementer feedback.
jjh
Version
0.2
(2003-08-28)
Add more clarifying assumptions and requirements, make it clear that clients don't have to send capabilities every time if the server is optimizing.
jjh
Version
0.1
(2003-08-27)
Initial version.
jjh
Appendix I: Bib(La)TeX Entry
@report{hildebrand2003caps,
title = {Entity Capabilities},
author = {Hildebrand, Joe and Saint-Andre, Peter and Tronçon, Remko and Konieczny, Jacek},
type = {XEP},
number = {0115},
version = {1.6.0},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0115.html},
date = {2003-08-27/2022-03-08},
END