XEP-xxxx: ...

This specification provides a description how to couple Stanza Repeaters and Presence.

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-31
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP-IM, XEP 0045, XEP 0191, Repeaters
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

Author Information

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. Requirements
3. Integration of Repeaters with Presence
    3.1. Dramatis Personae
    3.2. Integration with Presence Subscription
    3.3. Integration with Subscription Removal
    3.4. Integration with Subscription Cancelling
    3.5. Presence Broadcast
    3.6. Privacy Lists
    3.7. Error Handling and Subscription State Desync
4. Integration with Multi-User-Chat
    4.1. Entering a room
    4.2. Exiting a Room
    4.3. Occupant is Kicked From Room
    4.4. Sending a Message to all Occupants
5. Implementation Notes
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
Notes
Revision History

1. Introduction

Deploying Stanza Repeaters makes it necessary to trust a remote sender. This XEP shows this trust can be based upon existing protocol operations. Therefore, repeaters can be applied to the use-cases of presence broadcast and Multi-User Chat [1].

Note: This document does not show error flows related to generic repeater use-cases.

2. Requirements

A server conforming to this specification SHOULD allow creation and modification of persistent repeaters by a trusted remote sender, whereas trust is defined by a relationship between the sender and one or more local nodes. The criteria for allowing a remote sender to add a local node to a repeater are:

A repeater SHOULD be stored permanently as long as there are local nodes interested in it.

3. Integration of Repeaters with Presence

This section shows the entanglement between presence subscriptions and repeaters, resulting in a 'Personal Repeater'.

3.1 Dramatis Personae

Table 1: Dramatis Personae

Person Full JID Initial Subscription Status to Romeo Subscription Status to Romeo later in the XEP
Romeo romeo@montague -- --
Juliet juliet@capulet None Both
Nurse nurse@capulet None To

3.2 Integration with Presence Subscription

Initially, Romeo and Juliet (and the Nurse) are not subscribed to each others presence. Romeo subscribes to Juliet's presence:

Example 1. User Subscribes to Presence

<presence from='romeo@montague'
    to='juliet@capulet' type='subscribe'/>

Juliet approves the subscription request:

Example 2. Subscription Request is Approved (C2S)

<presence from='juliet@capulet' 
    to='romeo@montague'
    type='subscribed'/>

The capulet server adds information (node part of the address only) about the repeater it will use to the packet:

Example 3. Juliet approves the subscription request (S2S)

<presence from='juliet@capulet' 
    to='romeo@montague'
    type='subscribed'>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>f0d85422a739e72ea044627ac5130d971eb8b60f</creates>
    <obsoletes/>
  </repeater>
</presence>

As Juliet wants to know if Romeo is available, she subscribes to his presence, making the subscription bidirectional. Unfortunately, the Nurse watches Juliet closely and wants him to allow her to subscribe to his presence also.

Example 4. More Subscriptions

<presence from='juliet@capulet'
  to='romeo@montague' type='subscribe'/>
<presence from='nurse@capulet'
  to='romeo@montague' type='subscribe'/>

Romeo acknowledges the subscription of Juliet and creates or modifies his repeater (which is assumed to be initially empty herein).

Example 5. Juliet's Subscription is Acknowledged (C2S)

<presence from='romeo@montague'
  to='juliet@capulet' type='subscribed'/>

Example 6. Juliet's Subscription is Acknowledged (S2S)

<presence from='romeo@montague'
  to='juliet@capulet' type='subscribed'>
    <repeater xmlns='urn:xmpp:tmp:repeat'>
      <creates>65db6a26fc52ddc91f6b611bc8d610aed6e51115</creates>
      <obsoletes/>
    </repeater>
</presence>

The Nurse talks Romeo into letting her subscribe to his presence also.

Example 7. Second Subscription is Acknowledged (C2S)

<presence from='romeo@montague'
  to='nurse@capulet' type='subscribed'/>

Example 8. Nurse's Subscription is Acknowledged (S2S)

<presence from='romeo@montague'
  to='nurse@capulet' type='subscribed'>
    <repeater xmlns='urn:xmpp:tmp:repeat'>
      <creates>35bb0982414b54184d14a961cf749de92d1cd952</creates>
      <obsoletes>65db6a26fc52ddc91f6b611bc8d610aed6e51115</obsoletes>
    </repeater>
</presence>

3.3 Integration with Subscription Removal

In order to unsubscribe from Juliet's presence, the following steps happen:

Example 9. Romeo Unsubscribes from Juliet's Presence (C2S)

<presence to='juliet@capulet' type='unsubscribe'/>

Example 10. Romeo Unsubscribes from Juliet's Presence (S2S)

<presence from='romeo@montague'
    to='juliet@capulet' 
    type='unsubscribe'>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>a8746a9a4c52affcd34f4a1ba7365d908a800d96</creates>
    <obsoletes>35bb0982414b54184d14a961cf749de92d1cd952</obsoletes>
  </repeater>
</presence>

Note: the obsolete repeater should not be deleted immediately. Instead, packets SHOULD be forwarded to the new repeater to avoid repeater errors due to a transiently inconsistent state.

3.4 Integration with Subscription Cancelling

Example 11. Juliet Cancels Romeo's Subscription (C2S)

<presence to='romeo@montague' type='unsubscribed'/>

Example 12. Juliet Cancels Romeo's Subscription (S2S)

<presence to='romeo@montague' 
  to='juliet@capulet'
  type='unsubscribed'>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>a8746a9a4c52affcd34f4a1ba7365d908a800d96</creates>
    <obsoletes>35bb0982414b54184d14a961cf749de92d1cd952</obsoletes>
  </repeater>
</presence>

Note: the obsolete repeater should not be deleted immediately. Instead, packets SHOULD be forwarded to the new repeater to avoid repeater errors due to a transiently inconsistent state.

3.1 Cancelling a Mutual Subscription

The flow for cancelling a mutual subscription is similar to the sequence of events happening during unsubscribe and cancel. However, the repeater modification happens only once.

3.5 Presence Broadcast

The 'presence broadcast' SHOULD use the repeaters generated during the course of subscription operations.

Example 13. Presence Broadcast Using Repeaters

<presence from='romeo@montague' 
    to='capulet/35bb0982414b54184d14a961cf749de92d1cd952'
    type='probe'/>
<presence from='romeo@montague/garden' 
    to='capulet/35bb0982414b54184d14a961cf749de92d1cd952'
  <status>I am here</status>
</presence>

3.6 Privacy Lists

This section shows how repeaters and privacy lists are connected. The examples use the blocking syntax of Simple Communications Blocking [2].

Example 14. Romeo Blocks the Nurse

<iq from='romeo@montague/garden' type='set' id='block1'>
  <block xmlns='urn:xmpp:blocking'>
    <item jid='romeo@montague'/>
  </block>
</iq>

As a result, Romeo creates a repeater which excludes the Nurse by modifying the existing repeater:

Example 15. A Repeater Excluding The Nurse is Created

<iq from='romeo@montague' 
    to='capulet/35bb0982414b54184d14a961cf749de92d1cd952'>
    id='modify'
    type='set'>
  <modify xmlns='urn:xmpp:tmp:repeat'>
    <remove>
      <jid>nurse@capulet</jid>
    </remove>
  </modify>
</iq>

Note: if the block is permanent, the old repeater could/should be deleted.

Example 16. Repeater Modification Result

<iq from='capulet/35bb0982414b54184d14a961cf749de92d1cd952'>
    to='romeo@montague' 
    id='modify'
    type='result'>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>65db6a26fc52ddc91f6b611bc8d610aed6e51115</creates>
  </repeater>
</iq>

After receiving the repeater modification result, the server informs Romeo about the outcome of his block command

Example 17. Block Command Has Been Processed

<iq type='result' id='block1'/>

3.7 Error Handling and Subscription State Desync

If repeater operations fail, a desync between what the sender believes to be the state of the subscriptions on the the remote server and what the remote server knows about that state has happenend is likely. Fixing this problem is out-of-scope for this specification. However, the following strategy may be used to determine if there is a desync:

Example 18. Romeo Uses The Capulet Repeater

<message from='romeo@montague/garden'
    to='capulet/35bb0982414b54184d14a961cf749de92d1cd952'>
  <body>Good Morning!</body>
</message>

We assume that Juliet has cancelled his subscription to her presence and that the <presence type='unsubscribed'> got lost somehow. The Capulet server has deleted the repeater in the meantime and returns a <item-not-found/> error.

Example 19. Repeater is Not Found

<message from='capulet/35bb0982414b54184d14a961cf749de92d1cd952'
    to='romeo@montague/garden' type='error'>
  <error type='cancel'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
  <body>Good Morning!</body>
</message>

Romeo SHOULD try to recreate the repeater with what he considers to be those Capulets that are subscribed to his presence:

Example 20. An Attempt to Recreate the Repeater

<iq from='romeo@montague' 
    to='capulet'
    id='recreate'
    type='set'>
  <create xmlns='urn:xmpp:tmp:repeat'>
    <jid>juliet@capulet</jid>
    <jid>nurse@capulet</jid>
  </create>
</iq>

Example 21. Recreation Attempt Fails

<iq from='capulet'
    to='romeo@montague'
    id='recreate'
    type='error'>
  <error type='cancel'>
    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If this fails with a <forbidden/> error, this means that there is a desync in the subscription states and Romeo needs to initiate a resync for all his Capulet contacts.

Should a <forbidden/> error occur during repeater modification, this means that at least one of the JIDs contained in the modification request has a desynchronized state. The resync may take this information into account.

4. Integration with Multi-User-Chat

This section shows how Multi-User Chat [3] may be used in conjunction with repeaters. It assumes that the MUC room itself acts as the creator of the repeater. The examples used are the same as in Multi-User Chat [4].

4.1 Entering a room

Example 22. User Seeks to Enter a Room

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

Example 23. Service Sends New Occupant's Presence to All Occupants Using the Repeater

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='shakespeare.lit/802692880d2869f99ca359e7122f58d13178d701'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
  </x>
</presence>

Example 24. Service Sends New Occupant's Presence to New Occupant

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <status code='110'/>
    <status code='210'/>
  </x>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>48fbcb7fe3bdf4a455a13dbd1c5732f75e884fe3</creates>
    <obsoletes>802692880d2869f99ca359e7122f58d13178d701</obsoletes>
  </repeater>
</presence>

4.2 Exiting a Room

Example 25. Occupant Exits a Room (C2S)

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit/thirdwitch'
    type='unavailable'/>

Example 26. Occupant Exits a Room (S2S)

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit/thirdwitch'
    type='unavailable'>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>802692880d2869f99ca359e7122f58d13178d701</creates>
    <obsoletes>48fbcb7fe3bdf4a455a13dbd1c5732f75e884fe3</obsoletes>
  </repeater>
</presence>

The MUC service sends the directed presence of type 'unavailable' to the departing occupant.

Example 27. Service Sends Presence Related to Departure of Occupant to the Departing Occupant

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
    <status code='110'/>
  </x>
</presence>

Example 28. Service Sends Presence Related to Departure of Occupant Using New Repeater

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='shakespeare.lit/802692880d2869f99ca359e7122f58d13178d701'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
  </x>
</presence>

4.3 Occupant is Kicked From Room

Example 29. Service Removes Kicked Occupant

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none' role='none'/>
    <status code='307'/>
  </x>
  <repeater xmlns='urn:xmpp:tmp:repeat'>
    <creates>48fbcb7fe3bdf4a455a13dbd1c5732f75e884fe3</creates>
    <obsoletes>802692880d2869f99ca359e7122f58d13178d701</obsoletes>
  </repeater>
</presence>

Example 30. Service Informs Remaining Occupants

<presence
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='shakespeare.lit/48fbcb7fe3bdf4a455a13dbd1c5732f75e884fe3'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='none'/>
    <status code='307'/>
  </x>
</presence>

4.4 Sending a Message to all Occupants

Example 31. Occupant Sends a Message to All Occupants

<message
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

Example 32. Service Reflects Message to All Occupants using Repeater

<message
    from='darkcave@macbeth.shakespeare.lit/thirdwitch'
    to='shakespeare.lit/48fbcb7fe3bdf4a455a13dbd1c5732f75e884fe3'
    type='groupchat'>
  <body>Harpier cries: 'tis time, 'tis time.</body>
</message>

5. Implementation Notes

Servers already possess the necessary data structures for checking that a remote sender is trusted to add a local JID to a repeater. Those are the subscription status and the list of JIDs the user has sent directed presence to.

Applications implementing repeater functionality should use an API similar to the one described in RFC 5058 [5] for sending a message to all recipients instead of looping over the receivers directly. The case of a recipient list containing a only a single element can then be treated as plain XMPP and repeater managment operations are left out.

6. Security Considerations

If properly implemented, this protocol extension does not introduce any new security concerns above and beyond those defined in Repeaters.

7. IANA Considerations

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

8. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [7].

Notes

1. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

2. XEP-0191: Simple Communications Blocking <http://www.xmpp.org/extensions/xep-0191.html>.

3. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

4. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

5. RFC 5058: Explicit Multicast (Xcast) Concepts and Options <http://tools.ietf.org/html/rfc5058>.

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

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

Revision History

Version 0.0.1 (2008-03-31)

First draft.

(ph)

Version 0.0.2 (2008-04-07)

changed flows for presence + muc

(ph)

END