XEP-xxxx: Stanza Exploders

This specification defines an XMPP extension that enables optimization of interdomain traffic that is intended for delivery to multiple recipients, using the concept of a stanza exploder.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2008-03-10
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED


Author Information

Joe Hildebrand

Email: jhildebrand@jabber.com
JabberID: hildjj@jabber.org

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Matt Yacobucci

Email: myacobucci@jabber.com
JabberID: myacobucci@corp.jabber.com


Legal Notices

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Errata may be sent to <editor@xmpp.org>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Table of Contents


1. Introduction
2. How It Works
3. Discovering an Exploder Service
4. Requesting an Exploder
5. Modifying an Exploder
6. Deleting an Exploder
7. Sending Stanzas to an Exploder
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
    10.1. Protocol Namespaces
    10.2. Service Discovery Category/Type
11. XML Schema
Notes
Revision History


1. Introduction

Extended Stanza Addressing [1] defines an XMPP protocol extension for optimization of interdomain traffic that is intended for delivery to multiple recipients. Unfortunately, in practice Extended Stanza Addressing has not resulted in traffic optimization. The authors have investigated the potential of modifying XEP-0033 to remedy its shortcomings and have found this to be difficult if not impossible. Therefore we have defined a new approach to the problem, using the concept of an alias that enables delivery to multiple recipients at a foreign domain (we call such a JabberID an "exploder").

Certain communication scenarios result in a large volume of identical stanzas sent between domains. Examples include:

In all of these scenarios, it would be desirable for the sending entity to send one stanza to the foreign domain and for the foreign domain to then reflect the stanza to all of the intended recipients. While XEP-0033 solved this problem, it did so in a verbose way that in practice did not save any bandwidth (and in certain cases increased the bandwidth).

We propose to solve the problem by defining a new kind of XMPP entity: a stanza exploder. An exploder is essentially an alias that enables a sender to generate one stanza and have the exploder deliver that stanza to all local entities. The exploder's JID is defined as a unique hash of the intended recipients' JIDs, which can be managed from afar by the sending entity if it has appropriate privileges at the foreign domain. These concepts are explained in more detail below.

Note: A stanza exploder probably saves bandwidth only if the list of aliased JIDs changes less frequently than stanzas are sent to the exploder. Implementation and deployment experience will help to define the situations when exploders are most useful, but in any case they are likely more efficient than Extended Stanza Addressing implementations (given that modifications to exploder lists are exchanged as diffs, not a full set of addresses).

2. How It Works

This section provides a friendly introduction to stanza exploders, using the example of XMPP rosters.

Let us imagine that a power user at one domain (say, poweruser@example.net) has 100 contacts at another domain (say, user0@example.com through user99@example.com). When the power user logs in, his server sends 100 presence probes to example.com (i.e., one probe to user0@example.com, one probe to user1@example.com, etc.). This is inefficient. It might be more efficient if example.net could send one stanza to example.com, which example.com could then deliver to its local users.

Now let us imagine that example.net has privileges to use a special service at example.com for just this purpose. The service is called exploder.example.com and example.net requests a special address at exploder.example.com which functions as an alias for user0@example.com -> user99@example.com: <e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com>.

Therefore, when example.com sends an XMPP stanza to the exploder address...

Example 1. Stanza as sent to exploder

<presence 
  from='poweruser@example.net/foo'
  to='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'
  type='probe'/>
  

... the exploder service delivers it to all of the aliased local JIDs:

Example 2. Stanza as exploded for local delivery

<presence 
  from='poweruser@example.net/foo'
  to='user0@example.com'
  type='probe'/>

<presence 
  from='poweruser@example.net/foo'
  to='user1@example.com'
  type='probe'/>

<presence 
  from='poweruser@example.net/foo'
  to='user2@example.com'
  type='probe'/>

[ ... ]

<presence 
  from='poweruser@example.net/foo'
  to='user99@example.com'
  type='probe'/>
  

3. Discovering an Exploder Service

A server can discover an exploder service at a peer server by using Service Discovery [2].

Example 3. Service discovery items request

<iq from='example.net'
    id='disco1'
    to='example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
  

Example 4. Service discovery items reply

<iq from='example.com'
    id='disco1'
    to='example.net'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    [ ... ]
    <item jid='exploder.example.com'/>
    [ ... ]
</iq>
  

Example 5. Service discovery information request

<iq from='example.net'
    id='disco2'
    to='exploder.example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  

Example 6. Service discovery information reply

<iq from='exploder.example.com'
    id='disco2'
    to='example.net'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='proxy' type='exploder'/>
</iq>
  

Now example.net knows that exploder.example.com is an exploder service.

The disco#info reply from the exploder service MAY include Service Discovery Extensions [3] information that specifies the maximum number of JIDs allowed in an exploder alias and other relevant details.

Example 7. Service discovery information reply (with extended info)

<iq from='exploder.example.com'
    id='disco2'
    to='example.net'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='proxy' type='exploder'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='jabber:iq:register'/>
    <feature var='urn:xmpp:tmp:explode'/>
    [ ... ]
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:tmp:explode</value>
      </field>
      <field var='max-jids'>
        <value>200</value>
      </field>
    </x>
  </query>
</iq>
  

An entity can also query a particular exploder.

Example 8. Service discovery information request

<iq from='example.net'
    id='disco3'
    to='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  

Example 9. Service discovery information reply

<iq from='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'
    id='disco3'
    to='example.net'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='proxy' type='exploder'/>
  </query>
</iq>
  

If the particular exploder does not exist, the exploder service MUST return an <item-not-found/> error.

4. Requesting an Exploder

A server can request an exploder by sending a create requesting (containing the JIDs to be aliased) to the exploder service.

Example 10. Exploder creation request

<iq from='example.net'
    id='create1'
    to='exploder.example.com'
    type='set'>
  <create xmlns='urn:xmpp:tmp:explode'
          for='poweruser@example.net'>
    <jid>user0@example.net</jid>
    <jid>user1@example.net</jid>
    <jid>user2@example.net</jid>
    [ ... ]
    <jid>user99@example.net</jid>
  </create>
</iq>
  

The exploder service then creates an exploder and informs the requesting server of the exploder's JID.

Example 11. Exploder creation successful

<iq from='exploder.example.com'
    id='create1'
    to='example.net'
    type='result'>
  <exploder xmlns='urn:xmpp:tmp:explode'>
    <jid>e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com</jid>
  </exploder>
</iq>
  

The JID of the exploder MUST be unique within the context of the exploder service. The exploder service MAY use any method in creating the JID.

The examples in this specification use the following method:

  1. Create an empty string 'S'.
  2. Append the JID of the entity for whom the exploder is being created, i.e., "poweruser@example.net", followed by the colon character ":" as a separator.
  3. Append each JID, followed by the comma character "," as a separator (except for the last JID), where the JIDs are sorted using "i;octet" collation as specified in Section 9.3 of RFC 4790 [4].
  4. Hash the string using the SHA-1 algorithm with hexcode output (see RFC 3174 [5]).

The exploder service may return any of the following stanza error conditions as defined in XMPP Core [6] (other conditions may be appropriate):

5. Modifying an Exploder

Once an exploder is created, it can be modified by adding or removing JIDs from the alias. This is done by sending a modification request.

The requesting entity SHOULD NOT send any stanzas to the exploder after requesting a modification and before receiving confirmation of successful modification. If the exploder service receives such a stanza, it SHOULD deliver it only to the JIDs defined for the exploder before modification.

If the exploder can be modified, the exploder service informs the requesting entity of success. The service MAY create a new JID for the exploder (e.g., appending an added JID and rehashing the string to yield a new JID). Whether or not the service creates a new JID, it MUST return the exploder's JID in the IQ-result informing the requesting entity of success.

If the requesting entity does not have control over that exploder, the exploder service MUST return a <forbidden/> error. Otherwise if the exploder does not exist, the exploder service MUST return an <item-not-found/> error.

The following example shows the protocol for adding one JID.

Example 12. Exploder modification request (add)

<iq from='example.net'
    id='modify1'
    to='exploder.example.com'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:explode'
          exploder='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'>
    <add>user100@example.net</add>
  </modify>
</iq>
  

Example 13. Exploder modification successful (add)

<iq from='exploder.example.com'
    id='modify1'
    to='example.net'
    type='result'>
  <exploder xmlns='urn:xmpp:tmp:explode'>
    <jid>10783c928720e4ad3482456ea6f01e86f5d52bc4@exploder.example.com</jid>
  </exploder>
</iq>
  

The following example shows the protocol for removing one JID.

Example 14. Exploder modification request (remove)

<iq from='example.net'
    id='modify2'
    to='exploder.example.com'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:explode'
          exploder='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'>
    <remove>user9@example.net</remove>
  </modify>
</iq>
  

Example 15. Exploder modification successful (remove)

<iq from='exploder.example.com'
    id='modify2'
    to='example.net'
    type='result'>
  <exploder xmlns='urn:xmpp:tmp:explode'>
    <jid>af8038f7ad7371d3f0995eb9dcba064b206fc5a1@exploder.example.com</jid>
  </exploder>
</iq>
  

A modify request can contain multiple JIDs in any combination of add and remove.

Example 16. Exploder modification request (multiple changes)

<iq from='example.net'
    id='modify3'
    to='exploder.example.com'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:explode'
          exploder='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'>
    <add>user100@example.net</add>
    <remove>user9@example.net</remove>
    <add>user101@example.net</add>
  </modify>
</iq>
  

Example 17. Exploder modification successful (remove)

<iq from='exploder.example.com'
    id='modify3'
    to='example.net'
    type='result'>
  <exploder xmlns='urn:xmpp:tmp:explode'>
    <jid>4edcb8588be7e23ae63a96a6098c3f35019b752c@exploder.example.com</jid>
  </exploder>
</iq>
  

If the modification request specifies adding and removing the same JID in the same request, the exploder service MUST return a <bad-request/> error. If the modification request specifies the removal of a JID that is not in the alias list, the exploder service SHOULD silently ignore the removal (e.g., not return an <item-not-found/> error). If the modification request specifies more than one instance of addition for the same JID or removal for the same JID, the exploder service SHOULD silently ignore the addition or removal (i.e., not return a <bad-request/> error).

6. Deleting an Exploder

Once an exploder is created, it can be deleted via a deletion request.

Example 18. Exploder deletion request

<iq from='example.net'
    id='delete1'
    to='exploder.example.com'
    type='set'>
  <delete xmlns='urn:xmpp:tmp:explode'
          exploder='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'/>
</iq>
  

The exploder service then deletes the exploder and informs the requesting server of success.

Example 19. Exploder deletion successful

<iq from='exploder.example.com'
    id='delete1'
    to='example.net'
    type='result'/>
  

The requesting entity SHOULD NOT send any stanzas to the exploder after requesting a deletion and before receiving confirmation of successful deletion. If the exploder service receives such a stanza, it SHOULD deliver it to the JIDs defined for the exploder before deletion.

7. Sending Stanzas to an Exploder

Once an entity has created an exploder, it can send stanzas to the exploder.

Example 20. Stanza as sent to exploder

<presence 
  from='poweruser@example.net/foo'
  to='e4df4399642aed42b579b05dc5c663aee27d6ec4@exploder.example.com'
  type='probe'/>
  

The exploder service then delivers it to all of the aliased local JIDs.

Example 21. Stanza as exploded for local delivery

<presence 
  from='poweruser@example.net/foo'
  to='user0@example.com'
  type='probe'/>

<presence 
  from='poweruser@example.net/foo'
  to='user1@example.com'
  type='probe'/>

<presence 
  from='poweruser@example.net/foo'
  to='user2@example.com'
  type='probe'/>

[ ... ]

<presence 
  from='poweruser@example.net/foo'
  to='user99@example.com'
  type='probe'/>
  

If the sender does not have permission to send stanzas to that exploder, the exploder service MUST return a <forbidden/> error.

8. Security Considerations

An exploder service SHOULD restrict the exploder creation privilege to trusted entities. Such trusted entities could be local users of the XMPP server where the exploder service is hosted, trusted peer servers (or services thereof), or approved / registered entities from foreign domains. The definition of trusted entity is a matter of service provisioning.

Exploder services MAY further restrict the types of traffic that will be accepted (e.g., by payload type or size), and SHOULD make sure to institute appropriate rate limiting measures in order to prevent denial of service attacks (see Best Practices to Discourage Denial of Service Attacks [7]).

9. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [8].

10. XMPP Registrar Considerations

10.1 Protocol Namespaces

Until this specification advances to a status of Draft, the associated namespace for its stream feature shall be "urn:xmpp:tmp:explode"; upon advancement of this specification, the XMPP Registrar [9] shall issue a permanent namespace in accordance with the process defined in Section 4 of XMPP Registrar Function [10].

10.2 Service Discovery Category/Type

The XMPP Registrar shall include the "proxy" category and associated "exploder" type in the Service Discovery registry. The registry submission is as follows:

  <category>
    <name>proxy</name>
    <type>
      <name>exploder</name>
      <desc>A service that enables multicast delivery via stanza explosion</desc>
      <doc>XEP-xxxx</doc>
    </type>
  </category>
    

11. XML Schema

To follow.


Notes

1. XEP-0033: Extended Stanza Addressing <http://www.xmpp.org/extensions/xep-0033.html>.

2. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

3. XEP-0128: Service Discovery Extensions <http://www.xmpp.org/extensions/xep-0128.html>.

4. RFC 4790: Internet Application Protocol Collation Registry <http://tools.ietf.org/html/rfc4790>.

5. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.

6. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

7. XEP-0205: Best Practices to Discourage Denial of Service Attacks <http://www.xmpp.org/extensions/xep-0205.html>.

8. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

9. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

10. XEP-0053: XMPP Registrar Function <http://www.xmpp.org/extensions/xep-0053.html>.


Revision History

Version 0.0.1 (2008-03-10)

First draft.

(jjh/psa/my)

END