moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.2pre1

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@503 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-08 22:08:46 +00:00
parent 0f6be46f25
commit dfc838138a
1 changed files with 85 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

112
xep-0115.xml
View File

@ -26,61 +26,67 @@
</schemaloc>
&hildjj;
&stpeter;
<revision>
<version>1.2pre1</version>
<date>in progress, last updated 2007-02-08</date>
<initials>psa</initials>
<remark><p>Clarified motivation and handling of service discovery requests.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2004-10-29</date>
<initials>psa</initials>
<remark>Corrected ext attribute to be of type NMTOKENS; clarified that values of the ext attribute may change during a session.</remark>
<remark><p>Clarified meaning of service discovery results for client#ver and client#ext.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2004-08-01</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Draft.</remark>
<remark><p>Per a vote of the Jabber Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2004-06-29</date>
<initials>jjh/psa</initials>
<remark>Added several items to the Security Considerations; clarified naming requirements regarding 'node', 'ver', and 'ext' attributes.</remark>
<remark><p>Added several items to the Security Considerations; clarified naming requirements regarding 'node', 'ver', and 'ext' attributes.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2004-04-25</date>
<initials>psa</initials>
<remark>Made a number of editorial adjustments.</remark>
<remark><p>Made a number of editorial adjustments.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2004-01-05</date>
<initials>psa</initials>
<remark>Specified that the protocol can be used whenever presence is used (e.g., by gateways); improved the XML schema; made several editorial adjustments.</remark>
<remark><p>Specified that the protocol can be used whenever presence is used (e.g., by gateways); improved the XML schema; made several editorial adjustments.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-09-04</date>
<initials>jjh</initials>
<remark>IQ gets must be to a resource, since they are intended to go to a particular session.</remark>
<remark><p>IQ gets must be to a resource, since they are intended to go to a particular session.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-09-02</date>
<initials>jjh</initials>
<remark>Servers MUST strip extras changed to MAY, due to implementer feedback.</remark>
<remark><p>Servers MUST strip extras changed to MAY, due to implementer feedback.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-08-28</date>
<initials>jjh</initials>
<remark>Add more clarifying assumptions and requirements, make
<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.</remark>
time if the server is optimizing.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2003-08-27</date>
<initials>jjh</initials>
<remark>Initial version.</remark>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
@ -91,7 +97,7 @@
<li>Allowing the initiation of Voice over IP (VoIP) sessions only to clients that support VoIP.</li>
<li>Not showing a "Send a File" button if another user's client does not support &xep0096;.</li>
</ul>
<p>Recently, some existing Jabber clients have begun sending &xep0092; requests to each entity from which they receive presence. That solution is impractical on a larger scale, particularly for users or applications with large rosters. This document proposes a more robust and scalable solution: namely, a presence-based mechanism for exchanging information about entity capabilities. <note>This proposal is not limited to clients, and could 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></p>
<p>Some older Jabber clients send one &xep0030; and one &xep0092; request to each entity from which they received presence after login. That "disco+version flood" results in an excessive use of bandwidth and is impractical on a larger scale, particularly for users or applications with large rosters. Therefore this document proposes 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>
</section1>
<section1 topic='Assumptions' anchor='assumptions'>
<p>This document makes several assumptions:</p>
@ -111,7 +117,7 @@
<section1 topic='Requirements' anchor='reqs'>
<p>The protocol defined herein addresses the following requirements:</p>
<ol>
<li>Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and &xep0030;.</li>
<li>Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and <cite>XEP-0030</cite>.</li>
<li>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.<note>These first two requirements effectively eliminated &xep0060; as a possible implementation of entity capabilities.</note></li>
<li>Clients MUST be able to retrieve information without querying each user.</li>
<li>Since presence is normally broadcasted to many users, the byte size of the proposed extension MUST be as small as possible.</li>
@ -141,41 +147,93 @@
<c xmlns='http://jabber.org/protocol/caps'
node='http://exodus.jabberstudio.org/caps'
ver='0.9'
ext='jingle ftrans xhtml'/>
ext='ftrans xhtml'/>
</presence>
]]></example>
</section2>
<section2 topic="Discovering Capabilities" anchor='discover'>
<p>Once someone on my roster knows what client I am using, they need to be able to figure out what features are supported by that client. The client that received the annotated presence sends a <strong>disco#info</strong> request (as defined in <strong>XEP-0030: Service Discovery</strong>) to <em>exactly</em> one of the users that sent a particular combination of <strong>node</strong> and <strong>ver</strong>. If the requestor has received the same annotation from multiple JIDs, the requestor SHOULD pick a random JID from that list to which the requestor will send the <strong>disco#info</strong> request.</p>
<p>Once someone on my roster knows what client I am using, they need to be able to figure out what features are supported by that client. In the deprecated "disco flood" approach, this has been done by sending one "disco#info" request to each entity in a user's roster. Entity capabilities makes that unnecessary through the use of annotated presence. In particular, a client that receives the annotated presence sends a <strong>disco#info</strong> request (as defined in <strong>XEP-0030: Service Discovery</strong>) to <em>exactly</em> one of the users that sent a particular combination of <strong>node</strong> and <strong>ver</strong>. If the requestor has received the same annotation from multiple JIDs, the requestor SHOULD pick a random JID from that list to which the requestor will send the <strong>disco#info</strong> request.</p>
<p>The <strong>disco#info</strong> request is sent to a JID + node combination that consists of the chosen <strong>&lt;user@host/resource&gt;</strong> JID and a service discovery <strong>node</strong> that is constructed as follows: concatenate (1) the value of the caps <strong>'node'</strong> attribute, (2) the "#" character, and (3) the version number specified in the caps <strong>'ver'</strong> attribute.</p>
<example caption='Disco#info request for client#version'><![CDATA[
<iq type='get' to='randomuser1@capulet.com/resource'>
<iq type='get' from='bard@shakespeare.lit/globe' to='randomuser1@capulet.com/resource' iq='123'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#0.9'/>
</iq>
]]></example>
<p>Subsequent requests MAY be made to determine the info for each extension. These requests MUST be sent to a random <strong>&lt;user@host/resource&gt;</strong> JID that sent a caps annotation that included a particular <strong>node</strong>/<strong>ext</strong> combination. The <strong>disco#info</strong> request shall be sent to a JID + node combination that consists of the chosen JID and a service discovery <strong>node</strong> that is constructed as follows: concatenate (1) the value of the caps <strong>'node'</strong> attribute, (2) the "#" character, and (3) the extension name specified by one of the space-separated names in the caps <strong>'ext'</strong> attribute. The requestor SHOULD try to use different JIDs for each of these requests, as well as for the first request.</p>
<example caption='Disco#info requests for client#extension'><![CDATA[
<iq type='get' to='randomuser2@capulet.com/resource'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#jingle'/>
</iq>
]]></example>
<iq type='get' to='randomuser3@capulet.com/resource'>
<p>The random user then returns all of the capabilities supported by the base installation of the application without plugins or other add-ons:</p>
<example caption='Disco#info response for client#version'><![CDATA[
<iq type='result' from='randomuser1@capulet.com/resource' to='bard@shakespeare.lit/globe' iq='123'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#0.9'>
<identity category='client' type='pc'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='http://jabber.org/protocol/feature-neg'/>
<feature var='http://jabber.org/protocol/muc'/>
</query>
</iq>
]]></example>
<p>Subsequent requests MAY be made to determine the supported features associated with each extension. These requests MUST be sent to a random <strong>&lt;user@host/resource&gt;</strong> JID that sent a caps annotation that included a particular <strong>node</strong>/<strong>ext</strong> combination. The <strong>disco#info</strong> request shall be sent to a JID + node combination that consists of the chosen JID and a service discovery <strong>node</strong> that is constructed as follows: concatenate (1) the value of the caps <strong>'node'</strong> attribute, (2) the "#" character, and (3) the extension name specified by one of the space-separated names in the caps <strong>'ext'</strong> attribute. The requestor SHOULD try to use different JIDs for each of these requests, as well as for the first request.</p>
<example caption='Disco#info request for client#extension'><![CDATA[
<iq type='get' from='bard@shakespeare.lit/globe' to='randomuser3@capulet.com/resource' id='234'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#ftrans'/>
</iq>
]]></example>
<iq type='get' to='randomuser4@capulet.com/resource'>
<example caption='Disco#info response for client#extension'><![CDATA[
<iq type='result' from='randomuser3@capulet.com/resource' to='bard@shakespeare.lit/globe' id='234'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#ftrans'>
<identity category='client' type='pc'/>
<feature var='http://jabber.org/protocol/bytestreams'/>
<feature var='http://jabber.org/protocol/si'/>
<feature var='http://jabber.org/protocol/si/profile/file-transfer'/>
</query>
</iq>
]]></example>
<example caption='Disco#info request for client#extension'><![CDATA[
<iq type='get' from='bard@shakespeare.lit/globe' to='randomuser4@capulet.com/resource' id='345'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#xhtml'/>
</iq>
]]></example>
]]></example>
<example caption='Disco#info response for client#extension'><![CDATA[
<iq type='result' from='randomuser4@capulet.com/resource' to='bard@shakespeare.lit/globe' id='345'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://exodus.jabberstudio.org/caps#xhtml'>
<identity category='client' type='pc'/>
<feature var='http://jabber.org/protocol/xhtml-im'/>
</query>
</iq>
]]></example>
<p>Note: The set of features that a given entity advertises in response to a "client#version" request and all "client#extension" requests MUST be equivalent to the response it gives to a <strong>disco#info</strong> request with no 'node' attribute:</p>
<example caption='Generic disco#info response'><![CDATA[
<iq type='result' from='randomuser2@capulet.com/resource' to='bard@shakespeare.lit/globe' iq='456'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='client' type='pc'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='http://jabber.org/protocol/feature-neg'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='http://jabber.org/protocol/bytestreams'/>
<feature var='http://jabber.org/protocol/si'/>
<feature var='http://jabber.org/protocol/si/profile/file-transfer'/>
<feature var='http://jabber.org/protocol/xhtml-im'/>
</query>
</iq>
]]></example>
<p>All of the responses to the <strong>disco#info</strong> queries SHOULD be cached. If a particular entity cannot store the responses, it SHOULD NOT make the requests. An entity SHOULD NOT make the service discovery requests unless the information is required for some local functionality. An entity MUST NOT ever make a request to another entity that has the same version of the same application as the requesting entity, except for extensions that are not supported by the requestor's installation (e.g., one "Exodus 0.9" client MUST NOT query another "Exodus 0.9" client unless the second client has advertised an extension or plugin that the first client does not have).</p>
</section2>