From dfc838138a592d640734927dbb547d63ecebf2f4 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 8 Feb 2007 22:08:46 +0000 Subject: [PATCH] 1.2pre1 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@503 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0115.xml | 112 ++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 85 insertions(+), 27 deletions(-) diff --git a/xep-0115.xml b/xep-0115.xml index 8e06a449..726aa9ad 100644 --- a/xep-0115.xml +++ b/xep-0115.xml @@ -26,61 +26,67 @@ &hildjj; &stpeter; + + 1.2pre1 + in progress, last updated 2007-02-08 + psa +

Clarified motivation and handling of service discovery requests.

 + 1.1 2004-10-29 psa - Corrected ext attribute to be of type NMTOKENS; clarified that values of the ext attribute may change during a session. +

Clarified meaning of service discovery results for client#ver and client#ext.

 1.0 2004-08-01 psa - Per a vote of the Jabber Council, advanced status to Draft. +

Per a vote of the Jabber Council, advanced status to Draft.

 0.7 2004-06-29 jjh/psa - Added several items to the Security Considerations; clarified naming requirements regarding 'node', 'ver', and 'ext' attributes. +

Added several items to the Security Considerations; clarified naming requirements regarding 'node', 'ver', and 'ext' attributes.

 0.6 2004-04-25 psa - Made a number of editorial adjustments. +

Made a number of editorial adjustments.

 0.5 2004-01-05 psa - Specified that the protocol can be used whenever presence is used (e.g., by gateways); improved the XML schema; made several editorial adjustments. +

Specified that the protocol can be used whenever presence is used (e.g., by gateways); improved the XML schema; made several editorial adjustments.

 0.4 2003-09-04 jjh - IQ gets must be to a resource, since they are intended to go to a particular session. +

IQ gets must be to a resource, since they are intended to go to a particular session.

 0.3 2003-09-02 jjh - Servers MUST strip extras changed to MAY, due to implementer feedback. +

Servers MUST strip extras changed to MAY, due to implementer feedback.

 0.2 2003-08-28 jjh - Add more clarifying assumptions and requirements, make +

Add more clarifying assumptions and requirements, make it clear that clients don't have to send capabilities every - time if the server is optimizing. + time if the server is optimizing.

 0.1 2003-08-27 jjh - Initial version. +

Initial version.

 @@ -91,7 +97,7 @@
  • Allowing the initiation of Voice over IP (VoIP) sessions only to clients that support VoIP.
  • Not showing a "Send a File" button if another user's client does not support &xep0096;.
    • -

    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. 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.

    +

    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 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. 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.

    This document makes several assumptions:

    @@ -111,7 +117,7 @@

    The protocol defined herein addresses the following requirements:

      -
    1. Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and &xep0030;.
      2. +
    2. Clients MUST be able to participate even if they support only &xmppcore;, &xmppim;, and XEP-0030.
    3. 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.These first two requirements effectively eliminated &xep0060; as a possible implementation of entity capabilities.
    4. Clients MUST be able to retrieve information without querying each user.
    5. Since presence is normally broadcasted to many users, the byte size of the proposed extension MUST be as small as possible.
      6. @@ -141,41 +147,93 @@ + ext='ftrans xhtml'/> ]]> -

      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 disco#info request (as defined in XEP-0030: Service Discovery) to exactly one of the users that sent a particular combination of node and ver. 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 disco#info request.

      +

      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 disco#info request (as defined in XEP-0030: Service Discovery) to exactly one of the users that sent a particular combination of node and ver. 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 disco#info request.

      The disco#info request is sent to a JID + node combination that consists of the chosen <user@host/resource> JID and a service discovery node that is constructed as follows: concatenate (1) the value of the caps 'node' attribute, (2) the "#" character, and (3) the version number specified in the caps 'ver' attribute.

      + -]]> - -

      Subsequent requests MAY be made to determine the info for each extension. These requests MUST be sent to a random <user@host/resource> JID that sent a caps annotation that included a particular node/ext combination. The disco#info request shall be sent to a JID + node combination that consists of the chosen JID and a service discovery node that is constructed as follows: concatenate (1) the value of the caps 'node' attribute, (2) the "#" character, and (3) the extension name specified by one of the space-separated names in the caps 'ext' attribute. The requestor SHOULD try to use different JIDs for each of these requests, as well as for the first request.

      - - - - + ]]> - +

      The random user then returns all of the capabilities supported by the base installation of the application without plugins or other add-ons:

      + + + + + + + + + +       + ]]> + +

      Subsequent requests MAY be made to determine the supported features associated with each extension. These requests MUST be sent to a random <user@host/resource> JID that sent a caps annotation that included a particular node/ext combination. The disco#info request shall be sent to a JID + node combination that consists of the chosen JID and a service discovery node that is constructed as follows: concatenate (1) the value of the caps 'node' attribute, (2) the "#" character, and (3) the extension name specified by one of the space-separated names in the caps 'ext' attribute. The requestor SHOULD try to use different JIDs for each of these requests, as well as for the first request.

      + + + ]]> - + + + + + + + + + ]]> + + -]]> + ]]> + + + + + + + + ]]> + +

      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 disco#info request with no 'node' attribute:

      + + + + + + + + + + + + + + + ]]>

      All of the responses to the disco#info 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).