mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
1.5pre15: full XEP-0092 equivalents
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1587 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
7d2def7915
commit
9a9dee750d
35
xep-0115.xml
35
xep-0115.xml
@ -34,8 +34,8 @@
|
||||
<jid>jajcus@jabber.bnet.pl</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>1.5pre14</version>
|
||||
<date>in progress, last updated 2008-01-14</date>
|
||||
<version>1.5pre15</version>
|
||||
<date>in progress, last updated 2008-01-17</date>
|
||||
<initials>psa/jjh</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
@ -47,7 +47,7 @@
|
||||
<li>Clarified meaning and construction of caps node attribute and disco node attribute</li>
|
||||
<li>Specified that node attribute shall be included in disco#info request for backwards-compatibility</li>
|
||||
<li>Clarified handling of the legacy format to assist developers</li>
|
||||
<li>Defined recommended v attribute to include the software version as in older verions of the protocol</li>
|
||||
<li>Defined recommended n, os, and v attributes to include the information from XEP-0092</li>
|
||||
<li>Added service discovery feature for caps optimization to prevent confusion regarding server support of caps vs. caps optimization</li>
|
||||
</ul>
|
||||
</remark>
|
||||
@ -144,6 +144,7 @@
|
||||
<presence from='romeo@montague.lit/orchard'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='Exodus'
|
||||
node='http://code.google.com/p/exodus'
|
||||
v='0.9.1'
|
||||
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
@ -180,7 +181,9 @@
|
||||
<presence from='benvolio@capulet.lit/230193'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='Psi'
|
||||
node='http://psi-im.org/'
|
||||
os='PPC Mac OS X Mach-O'
|
||||
v='0.11'
|
||||
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
</presence>
|
||||
@ -191,7 +194,9 @@
|
||||
<presence from='nurse@capulet.lit/chamber'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='Psi'
|
||||
node='http://psi-im.org/'
|
||||
os='Windows-XP 5.01.2600'
|
||||
v='0.10'
|
||||
ver='uCoVCteRe3ty2wU2gHxkMaA7xhs='/>
|
||||
</presence>
|
||||
@ -201,7 +206,9 @@
|
||||
<presence from='bard@shakespeare.lit/globe'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='Chatopus'
|
||||
node='http://www.chatopus.com'
|
||||
v='2.1'
|
||||
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
|
||||
</presence>
|
||||
]]></code>
|
||||
@ -253,14 +260,24 @@
|
||||
<td>The hashing algorithm used to generate the 'ver' attribute; see <link url='#security-mti'>Mandatory-to-Implement Technologies</link> regarding supported hashing algorithms.</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>n</td>
|
||||
<td>The natural-language name of the software, equivalent to the <name/> element from <cite>XEP-0092</cite>. **</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>node</td>
|
||||
<td>A URI that uniquely identifies a software application, typically a URL at the website of the project or company that produces the software. *</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>os</td>
|
||||
<td>The operating system on which the software is running, equivalent to the <os/> element from <cite>XEP-0092</cite>. **</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>v</td>
|
||||
<td>A specific version of the software. **</td>
|
||||
<td>A specific version of the software, equivalent to the <version/> element from <cite>XEP-0092</cite>. **</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -303,6 +320,7 @@
|
||||
<presence>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='Exodus'
|
||||
node='http://code.google.com/p/exodus'
|
||||
v='0.9.1'
|
||||
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
|
||||
@ -313,6 +331,7 @@
|
||||
<presence>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='Exodus'
|
||||
node='http://code.google.com/p/exodus'
|
||||
v='0.9.1'
|
||||
ver='66/0NaeaBKkwk85efJTGmU47vXI='/>
|
||||
@ -364,7 +383,9 @@
|
||||
<stream:features>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
hash='sha-1'
|
||||
n='jabberd14'
|
||||
node='http://jabberd.org'
|
||||
os='Debian GNU/Linux 2.6.9'
|
||||
v='1.6.1'
|
||||
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='>
|
||||
</stream:features>
|
||||
@ -434,7 +455,7 @@
|
||||
<p>If a connected client determines that its server supports caps optimization, MAY choose to send the capabilities annotation only on the first presence packet, as well as whenever its capabilities change.</p>
|
||||
</section2>
|
||||
<section2 topic='Friendly Name' anchor='impl-name'>
|
||||
<p>The 'name' attribute of the service discovery <identity/> element enables a responding application to specify the "friendly name" for its node. However, this attribute is excluded from the hash generation method, primarily because 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. However, a receiving application MAY send a service discovery information request to a particularly JID+node combination in order to determine the friendly name, then cache the result for that JID+node only.</p>
|
||||
<p>The 'name' attribute of the service discovery <identity/> element enables a responding application to specify the "friendly name" for its node. However, this attribute is excluded from the hash generation method, primarily because 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. However, a receiving application MAY send a service discovery information request to a particular JID+node combination in order to determine the friendly name, then cache the result for that JID+node only.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
@ -467,7 +488,7 @@
|
||||
<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 <link url='#legacy'>Legacy Format</link>), 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 or poisoned hashes.</p>
|
||||
</section2>
|
||||
<section2 topic='Information Exposure' anchor='security-exposure'>
|
||||
<p>Use of entity capabilities might make it easier for an attacker to launch certain application-specific attacks, since the attacker would know what kind of 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 &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 presence subscription of "both"); note, however, that such restrictions may be incompatible with the recommendation regarding <link url='#directed'>Directed Presence</link>.</p>
|
||||
<p>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 &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 presence subscription of "both"); note, however, that such restrictions may be incompatible with the recommendation regarding <link url='#directed'>Directed Presence</link>.</p>
|
||||
<p>A client MAY enable a human user to disable inclusion of the 'v' attribute, which specifies a version of the software. If the 'v' attribute is not included, the receiver SHOULD assume that the version is intended to be private and SHOULD NOT automatically send Software Version requests to the sender.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
@ -508,7 +529,9 @@
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='ext' type='xs:NMTOKENS' use='optional'/>
|
||||
<xs:attribute name='hash' type='xs:NMTOKEN' use='required'/>
|
||||
<xs:attribute name='n' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='node' type='xs:string' use='required'/>
|
||||
<xs:attribute name='os' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='v' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='ver' type='xs:string' use='required'/>
|
||||
</xs:extension>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user