mirror of https://github.com/moparisthebest/xeps
1.5pre11
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1477 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
58f751a658
commit
8bb682093d
44
xep-0115.xml
44
xep-0115.xml
|
|
@ -34,10 +34,10 @@
|
|||
<jid>jajcus@jabber.bnet.pl</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>1.5pre10</version>
|
||||
<date>in progress, last updated 2007-12-06</date>
|
||||
<version>1.5pre11</version>
|
||||
<date>in progress, last updated 2007-12-18</date>
|
||||
<initials>jjh/psa</initials>
|
||||
<remark><p>Specified that inclusion of hash attribute is required and removed default value of sha-1; mentioned pre-image attack and added reference to RFC 4270; clarified meaning of node attribute; specified that node attribute shall be included in disco#info request for backwards-compatibility; further specified security considerations; clarified handling of the legacy format to assist developers; defined optional v attribute for the software version.</p></remark>
|
||||
<remark><p>Specified that inclusion of hash attribute is required and removed default value of sha-1; mentioned pre-image attack and added reference to RFC 4270; 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; further specified security considerations; clarified handling of the legacy format to assist developers; defined optional v attribute for the software version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.4</version>
|
||||
|
|
@ -103,9 +103,7 @@
|
|||
<version>0.2</version>
|
||||
<date>2003-08-28</date>
|
||||
<initials>jjh</initials>
|
||||
<remark><p>Add more clarifying assumptions and requirements, make
|
||||
it clear that clients don't have to send capabilities every
|
||||
time if the server is optimizing.</p></remark>
|
||||
<remark><p>Add more clarifying assumptions and requirements, make it clear that clients don't have to send capabilities every time if the server is optimizing.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
|
|
@ -133,7 +131,7 @@
|
|||
<presence from='romeo@montague.lit/orchard'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
node='http://code.google.com/p/exodus/'
|
||||
node='http://code.google.com/p/exodus'
|
||||
v='0.9.1'
|
||||
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
</presence>
|
||||
|
|
@ -146,7 +144,7 @@
|
|||
to='romeo@montague.lit/orchard'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
node='http://code.google.com/p/exodus#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
</iq>
|
||||
]]></code>
|
||||
<p>The response is:</p>
|
||||
|
|
@ -156,7 +154,7 @@
|
|||
to='juliet@capulet.lit/chamber'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='>
|
||||
node='http://code.google.com/p/exodus#8RovUdtOmiAjzj+xI7SK5BCw3A8='>
|
||||
<identity category='client' name='Exodus 0.9.1' type='pc'/>
|
||||
<feature var='http://jabber.org/protocol/disco#info'/>
|
||||
<feature var='http://jabber.org/protocol/disco#items'/>
|
||||
|
|
@ -286,14 +284,14 @@
|
|||
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Advertising Capabilities' anchor='advertise'>
|
||||
<p>Each time a conformant entity sends presence, it annotates that presence with an entity identifier ('node' attribute) and identity and feature identifier ('ver' attribute). In order that servers can remember the last presence for use in responding to probes, the client SHOULD include entity capabilities with every presence change.</p>
|
||||
<p>If the supported features change during a client's presence session (e.g., a user installs an updated version of a client plugin), the application MUST recompute the 'ver' attribute and SHOULD send a new presence broadcast.</p>
|
||||
<p>Each time a generating entity sends presence, it annotates that presence with an entity identifier ('node' attribute) and identity and feature identifier ('ver' attribute). In order that servers can remember the last presence for use in responding to probes, a client SHOULD include entity capabilities with every presence change.</p>
|
||||
<p>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 'ver' attribute and SHOULD send a new presence broadcast.</p>
|
||||
|
||||
<example caption='Annotated presence sent'><![CDATA[
|
||||
<presence>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
node='http://code.google.com/p/exodus/'
|
||||
node='http://code.google.com/p/exodus'
|
||||
v='0.9.1'
|
||||
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
</presence>
|
||||
|
|
@ -301,7 +299,7 @@
|
|||
</section2>
|
||||
|
||||
<section2 topic="Discovering Capabilities" anchor='discover'>
|
||||
<p>An application can learn what features another entity supports by sending a disco#info request (see <cite>XEP-0030</cite>) to any entity that sent a particular value of the <strong>ver</strong> attribute.</p>
|
||||
<p>An application (here called the "requesting entity") can learn what features another entity supports by sending a disco#info request (see <cite>XEP-0030</cite>) to the entity that generated the caps information (here called the "generating entity").</p>
|
||||
|
||||
<example caption='Disco#info request'><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
|
|
@ -309,13 +307,15 @@
|
|||
to='romeo@montague.lit/orchard'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
node='http://code.google.com/p/exodus#8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>The disco#info request is sent to the full JID (&FULLJID;) of the entity that generated the caps information.</p>
|
||||
<p>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 (&FULLJID;).</p>
|
||||
|
||||
<p>The responding entity then returns all of the capabilities it supports.</p>
|
||||
<p>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., "8RovUdtOmiAjzj+xI7SK5BCw3A8=") as provided by the generating entity.</p>
|
||||
|
||||
<p>The generating entity then returns all of the capabilities it supports.</p>
|
||||
|
||||
<example caption='Disco#info response'><![CDATA[
|
||||
<iq from='romeo@montague.lit/orchard'
|
||||
|
|
@ -323,7 +323,7 @@
|
|||
to='juliet@capulet.lit/balcony'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
node='http://code.google.com/p/exodus/#8RovUdtOmiAjzj+xI7SK5BCw3A8='>
|
||||
node='http://code.google.com/p/exodus#8RovUdtOmiAjzj+xI7SK5BCw3A8='>
|
||||
<identity category='client' type='pc'/>
|
||||
<feature var='http://jabber.org/protocol/disco#info'/>
|
||||
<feature var='http://jabber.org/protocol/disco#items'/>
|
||||
|
|
@ -332,7 +332,7 @@
|
|||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>The client MUST check the identities and supported features against the 'ver' value by calculating the hash as described under <link url='#ver'>Generating the ver Attribute</link> and making sure that the values match. If the values do not match, the client MUST NOT accept or cache the 'ver' value as reliable and SHOULD check the service discovery identity and supported features of another user who advertises that value (if any). This helps to prevent poisoning of entity capabilities information.</p>
|
||||
<p>The requesting entity MUST check the identities and supported features against the 'ver' value by calculating the hash as described under <link url='#ver'>Generating the ver Attribute</link> and making sure that the values match. If the values do not match, the requesting entity MUST NOT accept or cache the 'ver' value as reliable and SHOULD check the service discovery identity and supported features of another generating entity who advertises that value (if any). This helps to prevent poisoning of entity capabilities information.</p>
|
||||
|
||||
</section2>
|
||||
|
||||
|
|
@ -352,8 +352,7 @@
|
|||
|
||||
<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) 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>
|
||||
<p>If the server did not advertise its capabilities using the <link url='#stream'>Stream Feature</link>, a connected 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>
|
||||
|
||||
<example caption='Disco#info request for server optimization'><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
|
|
@ -379,11 +378,12 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Caching' anchor='caching'>
|
||||
<p>An application that accepts entity capabilities information SHOULD cache associations between the 'ver' attribute and discovered features within the scope of one presence session and MAY cache such associations across sessions. This obviates the need for extensive service discovery requests within a session or at the beginning of a session.</p>
|
||||
<p>It is RECOMMENDED for an application that processes entity capabilities information to cache associations between the 'ver' attribute and discovered features within the scope of one presence session. This obviates the need for extensive service discovery requests within a session.</p>
|
||||
<p>It is OPTIONAL for an application to cache associates across presence sessions. However, since this obviates the need for extensive service discovery requests at the beginning of a session, such caching is strongly encouraged, especially in bandwidth-constrained environments.</p>
|
||||
</section1>
|
||||
|
||||
<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>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"); note, however, that such restrictions may be incompatible with the recommendation regarding <link url='#directed'>Directed Presence</link>.</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 '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.</p>
|
||||
<p>Theoretically it may become possible to launch a "pre-image" attack (see &rfc4270;) against the hashes used in the 'ver' attribute, at least when the SHA-1 algorithm is used. However, such attacks are not currently practical, and may not become practical in the foreseeable future. If and when such attacks become practical, this specification will be updated to strongly recommend use of a hashing algorithm that is safer than SHA-1, such as SHA-256. Nevertheless, the SHA-256 algorithm can be used today if implementors are concerned about the safety of the SHA-1 algorithm.</p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue