To avoid confusion, renamed the hash attribute to the algo attribute; required inclusion of the algo attribute in non-legacy mode; removed schema default for algo attribute; to help prevent a race condition and ensure backward compatibility, specified that the disco#info request is sent to node#ver; clarified meaning of node attribute; further specified security considerations; clarified handling of the legacy format to assist developers.
Required inclusion of the hash attribute in non-legacy mode; removed schema default for hash attribute; clarified meaning of node attribute; further specified security considerations; clarified handling of the legacy format to assist developers.
@@ -138,11 +138,9 @@
id='disco1'
to='romeo@montague.lit/orchard'
type='get'>
- (Note: The disco#info request is sent to a service discovery node formed of the caps 'node' attribute and the caps 'ver' attribute to help prevent a race condition; see Discovering Capabilities.)
The response is:
@@ -171,8 +169,8 @@
@@ -180,7 +178,7 @@
Definition
Inclusion
-
- algo
- The hashing algorithm used in generated the 'ver' attribute (see &ianahashes;). The value SHOULD be "sha-1".
- REQUIRED
-
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 in generated the 'ver' attribute (see &ianahashes;). The value SHOULD be "sha-1".
+ REQUIRED
+
node
A unique identifier for the software underlying the entity, typically a URL at the website of the project or company that produces the software. *
@@ -243,7 +241,7 @@
REQUIRED
- * Note: It is RECOMMENDED for the value of the 'node' attribute to identify both the software product and the released version in the form "ProductURL;SoftwareVersion", such as "http://psi-im.org/;0.11" This enables a processing application to strip off everything after the ";" character and thereby determine a unique string for the generating application, which it could maintain in a list of known products or (if the string is a URL) which it could use to find more detailed information about the generating application. . In any case, the value of the 'node' attribute MUST NOT include the "#" character, which is used as a separator character in the Discovering Capabilities use case.
+ * Note: It is RECOMMENDED for the value of the 'node' attribute to identify both the software product and the released version in the form "ProductURL;SoftwareVersion", such as "http://psi-im.org/#0.11" This enables a processing application to strip off everything after the "#" character and thereby determine a unique string for the generating application, which it could maintain in a list of known products or (if the string is a URL) which it could use to find more detailed information about the generating application. .
** 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 backward-compatible, applications SHOULD appropriately handle the Legacy Format.
@@ -277,8 +275,8 @@
@@ -292,18 +290,11 @@
id='disco1'
to='romeo@montague.lit/orchard'
type='get'>
- The disco#info request is sent to a service discovery node whose value is generated as follows:
-
- - The value of the caps 'node' attribute.
- - The "#" character.
- - The value of the caps 'ver' attribute.
-
- Inclusion of the service discovery 'node' attribute (which is not to be confused with the entity capabilities 'node' attribute) helps to prevent a race condition, namely: if the user sends presence but changes capabilities (e.g., by enabling a plugin) before the contact requests the user's service discovery information.
+ The disco#info request is sent to the full JID (&FULLJID;) of the entity that generated the caps information.
The responding entity then returns all of the capabilities it supports.
@@ -330,7 +321,7 @@
@@ -347,8 +338,7 @@
-
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 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 &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 section of this document for both generation and checking of the 'ver' attribute helps to guard against poisoning of entity capabilities information by malicious or improperly implemented entities.
- If the value of the 'ver' attribute is a hash as defined herein (i.e., if the 'ver' attribute is not generated according to the legacy format), inclusion of the 'algo' attribute is required. Knowing explicitly that the value of the 'ver' attribute is a hash enables the recipient to avoid spurious notification of invalid hashes.
+ If the value of the 'ver' attribute is a hash 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 hash enables the recipient to avoid spurious notification of invalid hashes.
The 'name' attribute of the service discovery <identity/> element is not included in the hash generation method. The primary reason for excluding it is that it is human-readable text and therefore may be provided in different localized versions. As a result, its inclusion would needlessly multiply the number of possible hash values and thus the time and resources required to validate values of the 'ver' attribute.
@@ -409,8 +399,8 @@
-
@@ -429,13 +419,22 @@
- Before Version 1.4 of this specification, the 'ver' attribute was generated differently, the 'ext' attribute was used more extensively, and the 'algo' attribute was absent. 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.
- An application can determine if the legacy format is in use by checking for the presence of the 'algo' attribute, which is REQUIRED in the current format.
- In the legacy format, the value of the 'ver' attribute is not a hash of the service discovery identity and supported features. Therefore, a processing entity cannot validate the identity and features by checking the hash. If the processing entity 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 not, the processing entity SHOULD ignore the 'ver' value entirely (since it cannot be verified) and SHOULD NOT cache it.
+ 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 <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.
+ 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 an application supports the legacy format, it SHOULD proceed as follows:
+
+ - When receiving caps information from a legacy entity, an application SHOULD check the 'node', 'ver', and 'ext' combinations as specified in the archived version 1.3 of this specification, and MAY cache the results.
+ - When sending a disco#info request to a legacy entity, an application SHOULD send the request to the entity's JID with a service discovery node of "node#ver".
+
+ If an application does not support the legacy format, it SHUOLD proceed as follows:
+
+ - When receiving caps information from a legacy entity, an application SHOULD ignore the 'ver' value entirely (since it cannot be verified) and SHOULD NOT cache it, since the application cannot validate the identity and features by checking the hash.
+ - When sending a disco#info request to a legacy entity, an application SHOULD send the request to the entity's JID without a service discovery node of "node#ver".
+
- Thanks to Rachel Blackman, Dave Cridland, Richard Dobson, Sergei Golovan, Justin Karneges, Jacek Konieczny, Ian Paterson, Kevin Smith, Tomasz Sterna, Michal Vaner, and Matt Yacobucci for comments and suggestions.
+ Thanks to Rachel Blackman, Dave Cridland, Richard Dobson, Olivier Goffart, Sergei Golovan, Justin Karneges, Jacek Konieczny, Ian Paterson, Kevin Smith, Tomasz Sterna, Michal Vaner, and Matt Yacobucci for comments and suggestions.