XEP-xxxx: Stanza Repeaters

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


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.2
Last Updated: 2008-03-24
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

Matt Yacobucci

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

Peter Saint-Andre

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

Craig Kaes

Email: ckaes@jabber.com
JabberID: ckaes@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. Service Discovery
    3.1. Discovering a Repeater Service
    3.2. Querying for the List of Repeaters
    3.3. Querying a Particular Repeater
4. Creating a Repeater
5. Modifying a Repeater
6. Deleting a Repeater
7. Managing Affiliations
8. Sending Stanzas to a Repeater
9. Implementation Notes
10. Security Considerations
11. IANA Considerations
12. XMPP Registrar Considerations
    12.1. Protocol Namespaces
    12.2. Service Discovery Category/Type
13. 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, for several reasons:

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 "repeater").

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 repeater. An repeater is essentially an alias that enables a sender to generate one stanza and have the repeater deliver that stanza to all aliased entities. The repeater'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 repeater probably saves bandwidth only if the list of aliased JIDs changes less frequently than stanzas are sent to the repeater. Implementation and deployment experience will help to define the situations when repeaters are most useful, but in any case they are likely more efficient than Extended Stanza Addressing implementations (given that modifications to repeater lists are exchanged as diffs, not a full set of addresses).

2. How It Works

This section provides a friendly introduction to stanza repeaters, using the example of publish-subscribe notifications.

Let us imagine that a pubsub node hosted at notifications.shakespeare.lit has a large number of subscribers (say, 1000) at the marlowe.lit XMPP domain. When a notification is published, the service must generate one notification for each of those subscribers, all of which must be sent over the server-to-server connection between shakespeare.lit and marlowe.lit. This is inefficient. It would be more efficient if notifications.shakespeare.lit could send one stanza to marlowe.lit for distribution by marlowe.lit to its local users.

Now let us imagine that notifications.shakespeare.lit has privileges to use a special service at marlowe.lit for just this purpose, called repeater.marlowe.lit. The notifications.shakespeare.lit pubsub service requests a special address at repeater.marlowe.lit, which functions as an alias for user0@marlowe.lit -> user999@marlowe.lit; this address (generated by the repeater service) is <repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db>.

Therefore, when notifications.shakespeare.lit sends an XMPP stanza to the repeater address...

Example 1. Stanza as sent to repeater

<iq from='notifications.shakespeare.lit'
    id='repeat1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='set'>
  <repeat xmlns='urn:xmpp:tmp:repeat'>
    <message xmlns='jabber:client'
             from='notifications.shakespeare.lit'>
      <event xmlns='http://jabber.org/protocol/pubsub#event'>
        <items node='princely_musings'>
          <item id='ae890ac52d0df67ed7cfdf51b644e901'>
            <entry xmlns='http://www.w3.org/2005/Atom'>
              <title>Macbeth</title>
              <summary>
                Macbeth! Murder, betrayal, witches, ghosts, 
                walking forests, and other eerie phenomena 
                make this great new production a must-see!
              </summary>
              <link rel='alternate' type='text/html'
                    href='http://shakespeare.lit/plays/2008/new.html'/>
              <id>tag:shakespeare.lit,2008:entry-32397</id>
              <published>2008-03-13T18:30:02Z</published>
              <updated>2008-03-13T18:30:02Z</updated>
            </entry>
          </item>
        </items>
      </event>
    </message>
  </repeat>
</iq>
  

... the repeater service delivers it to all of the aliased JIDs:

Example 2. Stanza as repeated for delivery

<message xmlns='jabber:client'
         from='notifications.shakespeare.lit'
         to='user0@marlowe.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Macbeth</title>
          <summary>
            Macbeth! Murder, betrayal, witches, ghosts, 
            walking forests, and other eerie phenomena 
            make this great new production a must-see!
          </summary>
          <link rel='alternate' type='text/html'
                href='http://shakespeare.lit/plays/2008/new.html'/>
          <id>tag:shakespeare.lit,2008:entry-32397</id>
          <published>2008-03-13T18:30:02Z</published>
          <updated>2008-03-13T18:30:02Z</updated>
        </entry>
      </item>
    </items>
  </event>
</message>

<message xmlns='jabber:client'
         from='notifications.shakespeare.lit'
         to='user0@marlowe.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Macbeth</title>
          <summary>
            Macbeth! Murder, betrayal, witches, ghosts, 
            walking forests, and other eerie phenomena 
            make this great new production a must-see!
          </summary>
          <link rel='alternate' type='text/html'
                href='http://shakespeare.lit/plays/2008/new.html'/>
          <id>tag:shakespeare.lit,2008:entry-32397</id>
          <published>2008-03-13T18:30:02Z</published>
          <updated>2008-03-13T18:30:02Z</updated>
        </entry>
      </item>
    </items>
  </event>
</message>

[ ... ]

<message xmlns='jabber:client'
         from='notifications.shakespeare.lit'
         to='user999@marlowe.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Macbeth</title>
          <summary>
            Macbeth! Murder, betrayal, witches, ghosts, 
            walking forests, and other eerie phenomena 
            make this great new production a must-see!
          </summary>
          <link rel='alternate' type='text/html'
                href='http://shakespeare.lit/plays/2008/new.html'/>
          <id>tag:shakespeare.lit,2008:entry-32397</id>
          <published>2008-03-13T18:30:02Z</published>
          <updated>2008-03-13T18:30:02Z</updated>
        </entry>
      </item>
    </items>
  </event>
</message>
  

The repeater also informs the sender that the stanza has been repeated:

Example 3. Repeat successful

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='repeat1'
    to='notifications.shakespeare.lit'
    type='result'/>
  

3. Service Discovery

3.1 Discovering a Repeater Service

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

Example 4. Service discovery items request

<iq from='notifications.shakespeare.lit'
    id='disco1'
    to='marlowe.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

Example 5. Service discovery items reply

<iq from='marlowe.lit'
    id='disco1'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    [ ... ]
    <item jid='repeater.marlowe.lit'/>
    [ ... ]
  </query>
</iq>
    

Example 6. Service discovery information request

<iq from='notifications.shakespeare.lit'
    id='disco2'
    to='repeater.marlowe.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

Example 7. Service discovery information reply

<iq from='repeater.marlowe.lit'
    id='disco2'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='pubsub' type='repeater'/>
  </query>
</iq>
    

Now notifications.shakespeare.lit knows that repeater.marlowe.lit is a repeater service.

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

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

<iq from='repeater.marlowe.lit'
    id='disco2'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='pubsub' type='repeater'/>
    <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:repeat'/>
    [ ... ]
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:tmp:repeat</value>
      </field>
      <field var='max-jids'>
        <value>2000</value>
      </field>
    </x>
  </query>
</iq>
    

3.2 Querying for the List of Repeaters

If an entity sends a disco#items request to the repeater service, the service MAY return the list of repeaters.

Example 9. Service discovery items request

<iq from='notifications.shakespeare.lit'
    id='disco3'
    to='repeater.marlowe.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

Example 10. Service discovery items reply

<iq from='repeater.marlowe.lit'
    id='disco3'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    [ ... ]
    <item jid='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'/>
    [ ... ]
  </query>
</iq>
    

If the list of repeaters is large, the repeater service SHOULD use Result Set Management [4] to structure the result set.

If the repeater service does not reveal the list of repeaters, it MUST return an empty disco#items result (in accordance with XEP-0030).

Example 11. Service discovery items reply (empty)

<iq from='repeater.marlowe.lit'
    id='disco3'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

3.3 Querying a Particular Repeater

An entity can also query a particular repeater.

Example 12. Service discovery information request

<iq from='notifications.shakespeare.lit'
    id='disco4'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

Example 13. Service discovery information reply

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='disco4'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='pubsub' type='repeater'/>
  </query>
</iq>
    

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

The disco#info reply from the repeater itself MAY include extended information that specifies the maximum number of JIDs allowed in a repeater alias and other relevant details.

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

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='disco4'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='pubsub' type='repeater'/>
    <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:repeat'/>
    [ ... ]
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:tmp:repeat</value>
      </field>
      <field var='creator'>
        <value>poweruser@notifications.shakespeare.lit</value>
      </field>
      <field var='size'>
        <value>1000</value>
      </field>
    </x>
  </query>
</iq>
    

A disco#items request to the repeater itself MAY result in a response that includes the JIDs subsumed by the repeater.

Example 15. Service discovery items request to repeater

<iq from='notifications.shakespeare.lit'
    id='disco5'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

Example 16. Service discovery items reply from repeater

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='disco5'
    to='notifications.shakespeare.lit'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='user0@marlowe.lit'/>
    <item jid='user1@marlowe.lit'/>
    [ ... ]
    <item jid='user99@marlowe.lit'/>
  </query>
</iq>
    

4. Creating a Repeater

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

Example 17. Repeater creation request

<iq from='poweruser@notifications.shakespeare.lit/foo'
    id='create1'
    to='repeater.marlowe.lit'
    type='set'>
  <create xmlns='urn:xmpp:tmp:repeat'>
    <jid>user0@marlowe.lit</jid>
    <jid>user1@marlowe.lit</jid>
    <jid>user2@marlowe.lit</jid>
    [ ... ]
    <jid>user999@marlowe.lit</jid>
  </create>
</iq>
  

The repeater service then creates a repeater and informs the requesting server of the repeater's JID.

Example 18. Repeater creation successful

<iq from='repeater.marlowe.lit'
    id='create1'
    to='notifications.shakespeare.lit'
    type='result'>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <jid>repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db</jid>
  </repeater>
</iq>
  

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

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

5. Modifying a Repeater

Once a repeater 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 repeater after requesting a modification and before receiving confirmation of successful modification.

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

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

The following example shows the protocol for adding one JID.

Example 19. Repeater modification request (add)

<iq from='notifications.shakespeare.lit'
    id='modify1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:repeat'>
    <add>
      <jid>user100@notifications.shakespeare.lit</jid>
    </add>
  </modify>
</iq>
  

Example 20. Repeater modification successful (add)

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='modify1'
    to='notifications.shakespeare.lit'
    type='result'/>
</iq>
  

The following example shows the protocol for removing one JID.

Example 21. Repeater modification request (remove)

<iq from='notifications.shakespeare.lit'
    id='modify2'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:repeat'
    <remove>
      <jid>user9@notifications.shakespeare.lit</jid>
    </remove>
  </modify>
</iq>
  

Example 22. Repeater modification successful (remove)

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='modify2'
    to='notifications.shakespeare.lit'
    type='result'/>
</iq>
  

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

Example 23. Repeater modification request (multiple changes)

<iq from='notifications.shakespeare.lit'
    id='modify3'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:repeat'>
    <add>
      <jid>user100@notifications.shakespeare.lit</jid>
      <jid>user101@notifications.shakespeare.lit</jid>
    </add>
    <remove>
      <jid>user9@notifications.shakespeare.lit</jid>
    </remove>
  </modify>
</iq>
  

Example 24. Repeater modification successful (multiple changes)

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='modify3'
    to='notifications.shakespeare.lit'
    type='result'/>
</iq>
  

If the modification request specifies adding and removing the same JID in the same request, the repeater service SHOULD return a <bad-request/> error. If the modification request specifies the removal of a JID that is not in the alias list, the repeater 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 repeater service SHOULD silently ignore the addition or removal (i.e., not return a <bad-request/> error).

6. Deleting a Repeater

Typically, a repeater will be deleted automatically by the repeater service (e.g., if it has not been used for some amount of time). However, once a repeater can be explicitly deleted via a deletion request.

Example 25. Repeater deletion request

<iq from='notifications.shakespeare.lit'
    id='delete1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'/>
    type='set'>
  <delete xmlns='urn:xmpp:tmp:repeat'/>
</iq>
  

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

Example 26. Repeater deletion successful

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'>
    id='delete1'
    to='notifications.shakespeare.lit'
    type='result'/>
  

The requesting entity SHOULD NOT send any stanzas to the repeater after requesting a deletion and before receiving confirmation of successful deletion.

7. Managing Affiliations

Once a repeater is created, its creator can enable another entity to send stanzas via the repeater by setting the entity's affiliation to "sender".

Example 27. Repeater authorization request

<iq from='poweruser@notifications.shakespeare.lit'
    id='auth1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'/>
    type='set'>
  <affiliations xmlns='urn:xmpp:tmp:repeat'>
    <item affiliation='sender' jid='someotheruser@notifications.shakespeare.lit'/>
  </affiliations>
</iq>
  

The repeater service then authorizes that entity to "publish" to the repeater.

Example 28. Authorization successful

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='auth1'
    to='notifications.shakespeare.lit'
    type='result'/>
  

The creator can also de-authorize another entity by setting the entity's affiliation to "none".

Example 29. Repeater de-authorization request

<iq from='poweruser@notifications.shakespeare.lit'
    id='deauth1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'/>
    type='set'>
  <affiliations xmlns='urn:xmpp:tmp:repeat'>
    <item affiliation='none' jid='someotheruser@notifications.shakespeare.lit'/>
  </affiliations>
</iq>
  

The repeater service then de-authorizes that entity.

Example 30. Authorization successful

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='deauth1'
    to='notifications.shakespeare.lit'
    type='result'/>
  

The creator can also get the list of senders.

Example 31. Requesting the list of senders

<iq from='poweruser@notifications.shakespeare.lit'
    id='getsenders1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'/>
    type='get'>
  <affiliations xmlns='urn:xmpp:tmp:repeat'>
    <item affiliation='sender'/>
  </affiliations>
</iq>
  

The repeater then returns the list of senders.

Example 32. Authorization successful

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='getsenders1'
    to='notifications.shakespeare.lit'
    type='result'>
  <affiliations xmlns='urn:xmpp:tmp:repeat'>
    <item affiliation='sender' jid='some-user@notifications.shakespeare.lit'/>
    <item affiliation='sender' jid='another-user@notifications.shakespeare.lit'/>
  </affiliations>
</iq>
  

8. Sending Stanzas to a Repeater

Once an entity has created a repeater, it can send stanzas to the repeater. Any stanza to be repeated MUST be sent within a wrapper element of <repeat/> qualified by the 'urn:xmpp:tmp:repeat' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces)

Example 33. Stanza as sent to repeater

<iq from='notifications.shakespeare.lit'
    id='repeat1'
    to='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    type='set'>
  <repeat xmlns='urn:xmpp:tmp:repeat'>
    <message xmlns='jabber:client'
             from='notifications.shakespeare.lit'>
      <event xmlns='http://jabber.org/protocol/pubsub#event'>
        <items node='princely_musings'>
          <item id='ae890ac52d0df67ed7cfdf51b644e901'>
            <entry xmlns='http://www.w3.org/2005/Atom'>
              <title>Macbeth</title>
              <summary>
                Macbeth! Murder, betrayal, witches, ghosts, 
                walking forests, and other eerie phenomena 
                make this great new production a must-see!
              </summary>
              <link rel='alternate' type='text/html'
                    href='http://shakespeare.lit/plays/2008/new.html'/>
              <id>tag:shakespeare.lit,2008:entry-32397</id>
              <published>2008-03-13T18:30:02Z</published>
              <updated>2008-03-13T18:30:02Z</updated>
            </entry>
          </item>
        </items>
      </event>
    </message>
  </repeat>
</iq>
  

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

Example 34. Stanza as repeated for delivery

<message xmlns='jabber:client'
         from='notifications.shakespeare.lit'
         to='user0@marlowe.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Macbeth</title>
          <summary>
            Macbeth! Murder, betrayal, witches, ghosts, 
            walking forests, and other eerie phenomena 
            make this great new production a must-see!
          </summary>
          <link rel='alternate' type='text/html'
                href='http://shakespeare.lit/plays/2008/new.html'/>
          <id>tag:shakespeare.lit,2008:entry-32397</id>
          <published>2008-03-13T18:30:02Z</published>
          <updated>2008-03-13T18:30:02Z</updated>
        </entry>
      </item>
    </items>
  </event>
</message>

<message xmlns='jabber:client'
         from='notifications.shakespeare.lit'
         to='user0@marlowe.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Macbeth</title>
          <summary>
            Macbeth! Murder, betrayal, witches, ghosts, 
            walking forests, and other eerie phenomena 
            make this great new production a must-see!
          </summary>
          <link rel='alternate' type='text/html'
                href='http://shakespeare.lit/plays/2008/new.html'/>
          <id>tag:shakespeare.lit,2008:entry-32397</id>
          <published>2008-03-13T18:30:02Z</published>
          <updated>2008-03-13T18:30:02Z</updated>
        </entry>
      </item>
    </items>
  </event>
</message>

[ ... ]

<message xmlns='jabber:client'
         from='notifications.shakespeare.lit'
         to='user999@marlowe.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Macbeth</title>
          <summary>
            Macbeth! Murder, betrayal, witches, ghosts, 
            walking forests, and other eerie phenomena 
            make this great new production a must-see!
          </summary>
          <link rel='alternate' type='text/html'
                href='http://shakespeare.lit/plays/2008/new.html'/>
          <id>tag:shakespeare.lit,2008:entry-32397</id>
          <published>2008-03-13T18:30:02Z</published>
          <updated>2008-03-13T18:30:02Z</updated>
        </entry>
      </item>
    </items>
  </event>
</message>
  

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

The repeater also informs the sender that the stanza has been repeated:

Example 35. Repeat successful

<iq from='repeater.marlowe.lit/8c95a24c-f9ad-11dc-8a14-001143d5d5db'
    id='repeat1'
    to='notifications.shakespeare.lit'
    type='result'/>
  

9. Implementation Notes

A service may want to expire a repeater if it has not been used in a certain amount of time (in which case the service shall return an <item-not-found/> error if an entity attempts to interact with the repeater). Therefore, the user of a repeater needs to be able to handle re-creation of the repeater if necessary.

10. Security Considerations

A repeater service SHOULD restrict the repeater creation privilege to trusted entities. Such trusted entities could be local users of the XMPP server where the repeater 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.

A repeater service SHOULD restrict the JIDs that are included in a repeater list to local entities registered with the trust domain with which it is associated (e.g., the repeater service at repeater.marlowe.lit would repeat stanzas only to JIDs at *.marlowe.lit). However, a repeater service MAY repeat stanzas to remote JIDs if it trusts such remote JIDs to appropriately repeat traffic at the remote domain or if the remote domain has registered for repeating via the repeater service.

Repeater 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 [6]).

The existence of repeaters makes it possible to amplify the impact of certain attacks. Therefore, a repeater service MUST appropriately restrict sending of stanzas via repeaters to authorized entities, and SHOULD apply repeater use to existing rate limiting procedures (commonly known as "karma").

11. IANA Considerations

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

12. XMPP Registrar Considerations

12.1 Protocol Namespaces

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

12.2 Service Discovery Category/Type

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

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

13. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:tmp:archive'
    xmlns='urn:xmpp:tmp:archive'
    elementFormDefault='qualified'>

  <xs:import 
      namespace='jabber:client'
      schemaLocation='http://www.xmpp.org/schemas/jabber-client.xsd'/>

  <xs:element name='add'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='jid' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='authorize'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='jid' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='create'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='jid' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
    <xs:attribute name='for' type='xs:string' use='optional'/>
    <xs:attribute name='name' type='xs:string' use='optional'/>
  </xs:element>

  <xs:element name='deauthorize'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='jid' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='delete' type='empty'>

  <xs:element name='jid' type='xs:string'>

  <xs:element name='modify'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='add' minOccurs='0' maxOccurs='1'/>
        <xs:element ref='remove' minOccurs='0' maxOccurs='1'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='repeater'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='jid' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='repeat'>
    <xs:complexType>
      <xs:choice xmlns:xmpp='jabber:client'>
        <xs:element ref='xmpp:iq' maxOccurs='1'/>
        <xs:element ref='xmpp:message' maxOccurs='1'/>
        <xs:element ref='xmpp:presence' maxOccurs='1'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='remove'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='jid' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
  

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. XEP-0059: Result Set Management <http://www.xmpp.org/extensions/xep-0059.html>.

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

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

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

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

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


Revision History

Version 0.0.2 (2008-03-24)

Removed modification of repeater JID on add/change/remove; modified examples to use pubsub; added security note about remote JIDs.

(psa)

Version 0.0.1 (2008-03-16)

First draft.

(jjh/my/psa/ck)

END