moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

1.5pre2

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1187 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-28 02:11:20 +00:00
parent 349258664b
commit f4c5b40389
1 changed files with 32 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
xep-0115.xml
View File

@ -28,10 +28,10 @@
&stpeter;
&remko;
<revision>
<version>1.5pre1</version>
<date>2007-08-24</date>
<version>1.5pre2</version>
<date>2007-08-27</date>
<initials>jjh/psa</initials>
<remark><p>To avoid confusion, renamed the hash attribute to the algo attribute; required inclusion of the algo attribute in non-legacy mode; clarified handling of the legacy format to assist developers.</p></remark>
<remark><p>To avoid confusion, renamed the hash attribute to the algo attribute; required inclusion of the algo attribute in non-legacy mode; to help prevent a race condition, specified that the disco#info request is sent to node#ver; clarified handling of the legacy format to assist developers.</p></remark>
</revision>
<revision>
<version>1.4</version>
@ -121,13 +121,13 @@
<p>In the past, some Jabber clients sent one &xep0030; and one &xep0092; request to each entity from which they received presence after login. That "disco+version flood" resulted in an excessive use of bandwidth and was impractical on a larger scale, particularly for users or applications with large rosters. Therefore this document defines a more robust and scalable solution: namely, a presence-based mechanism <note>This proposal is not limited to clients, and can be used by any entity that exchanges presence with another entity, e.g., a gateway. However, this document uses the example of clients throughout.</note> 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.</p>
</section2>
<section2 topic='How It Works' anchor='howitworks'>
<p>This section provides a friendly introduction to entity capabilities.</p>
<p>This section provides a friendly introduction to entity capabilities ("caps").</p>
<p>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 a &lt;c/&gt; element with special attributes to its presence packets. As a result, your client receives the following presence packet:</p>
<code><![CDATA[
<presence from='romeo@montague.lit/orchard'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://exodus.jabberstudio.org/#0.9.1'
node='http://exodus.jabberstudio.org/;0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
]]></code>
@ -138,9 +138,11 @@
id='disco1'
to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/;0.9.1#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</iq>
]]></code>
<p>(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 <link url='#discover'>Discovering Capabilities</link>.)</p>
<p>The response is:</p>
<code><![CDATA[
<iq from='romeo@montague.lit/orchard'
@ -160,7 +162,7 @@
<presence from='benvolio@capulet.lit/230193'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://psi-im.org/#0.11'
node='http://psi-im.org/;0.11'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
]]></code>
@ -170,7 +172,7 @@
<presence from='nurse@capulet.lit/chamber'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://psi-im.org/#0.10'
node='http://psi-im.org/;0.10'
ver='uCoVCteRe3ty2wU2gHxkMaA7xhs='/>
</presence>
]]></code>
@ -179,7 +181,7 @@
<presence from='bard@shakespeare.lit/globe'>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://www.chatopus.com/#2.2'
node='http://www.chatopus.com/;2.2'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
</presence>
]]></code>
@ -232,15 +234,17 @@
</tr>
<tr>
<td>node</td>
<td>A unique identifier for the software underlying the entity, typically a URL at the website of the project or company that produces the software. Although this information is an "FYI" in the current version of entity capabilities, it is required for backward-compatibility with older versions (see the <link url='#legacy'>Legacy Format</link> section of this document). It is RECOMMENDED for the value to identify both the software product and the released version in the form "ProductURL#Version", such as "http://psi-im.org/#0.11".</td>
<td>A unique identifier for the software underlying the entity, typically a URL at the website of the project or company that produces the software. Although this information is an "FYI" in the current version of entity capabilities, it is required for backward-compatibility with older versions (see the <link url='#legacy'>Legacy Format</link> section of this document). *</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>ver</td>
<td>A string that specifies the identity and supported features of the entity. 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 <link url='#legacy'>Legacy Format</link>.</td>
<td>A string that specifies the identity and supported features of the entity. **</td>
<td>REQUIRED</td>
</tr>
</table>
<p>* 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". In any case, the value of the 'node' attribute MUST NOT include the "#" character, which is used as a separator character in the <link url='#discover'>Discovering Capabilities</link> use case.</p>
<p>** 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 <link url='#legacy'>Legacy Format</link>.</p>
</section1>
<section1 topic='Generation of ver Attribute' anchor='ver'>
@ -274,7 +278,7 @@
<presence>
<c xmlns='http://jabber.org/protocol/caps'
algo='sha-1'
node='http://exodus.jabberstudio.org/#0.9.1'
node='http://exodus.jabberstudio.org/;0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
]]></example>
@ -288,11 +292,20 @@
id='disco1'
to='romeo@montague.lit/orchard'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/;0.9.1#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</iq>
]]></example>
<p>The entity then returns all of the capabilities it supports.</p>
<p>The disco#info request is sent to a service discovery node whose value is generated as follows:</p>
<ol>
<li>The value of the caps 'node' attribute.</li>
<li>The "#" character.</li>
<li>The value of the caps 'ver' attribute.</li>
</ol>
<p>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.</p>
<p>The responding entity then returns all of the capabilities it supports.</p>
<example caption='Disco#info response'><![CDATA[
<iq from='romeo@montague.lit/orchard'
@ -326,7 +339,7 @@
</section1>
<section1 topic='Server Optimizations' anchor='optimizations'>
<p>A server that is managing an entity's presence 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 (e.g., an updated 'ver' attribute)(e.g., an updated 'ver' attribute) are sent to all subscribers.</p>
<p>A server that is managing an entity's presence 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 (e.g., an updated 'ver' attribute) are sent to all subscribers.</p>
<p>A client MAY query the server using <strong>disco#info</strong> to determine if the server supports the <strong>'http://jabber.org/protocol/caps'</strong> 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.</p>
@ -334,7 +347,8 @@
<iq from='juliet@capulet.lit/balcony'
to='capulet.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/;0.9.1#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</iq>
<iq from='capulet.lit'
@ -360,6 +374,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>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").</p>
<p>Adherence to the algorithm defined in the <link url='#ver'>Generation of ver Attribute</link> 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.</p>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
@ -419,7 +434,7 @@
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>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.</p>
<p>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.</p>
</section1>
</xep>