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. Protocol
    3.1. Address Calculation
4. Integration of Repeaters with Presence
    4.1. Dramatis Personae
    4.2. Integration with Presence Subscription
    4.3. Integration with Subscription Removal
    4.4. Integration with Subscription Cancelling
    4.5. Cancelling a Mutual Subscription
    4.6. Presence Broadcast
    4.7. Error Handling and Subscription State Desync
5. Integration with Multi-User-Chat
    5.1. Entering a room
    5.2. Exiting a Room
    5.3. Occupant is Kicked From Room
    5.4. Sending a Message to all Occupants
6. Implementation Notes
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
10. XML Schemas
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].

However, a direct application of the repeater proposal was deemed overly complicated, because it did not take the specific model into account. Piggybacking the repeater modifications with the protocol actions of presence and Multi-User Chat [2] results in several simplifications of the protocol.

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

Both presence subscription and Multi-User Chat [3] have subscribe and unsubscribe operations. This proposal piggybacks repeater modification operations on top of these operations by adding a <repeater/> child to each of them. This child contains two fields:

After stripping those fields off the stanza and delivering the stanza to the intended recipient, the repeater modification takes place. The new repeater address is calculated by adding or removing (depending on the operation that is being piggybacked) the full JID of the operand ('to' or 'from', depending on operation) from the list of recipients that has the hash given in the <obsoletes/> element. The result of this calculation MUST be the same as the content of the <creates/>. The old repeater SHOULD be removed immediately when the sender of the modification is the creator of the node.

3.1 Address Calculation

Repeater addresses are calculated by the following algorithm:

nodepart = sha1(stringprepped-sourcejid:list;of;sorted;and;stringprepped;recipient;jids)

The concrete algorithm used may be discovered in the extended disco#info reply. This enables the receiving domain to choose hash space size according to it's needs. SHA1 is used in the examples in this document.

4. Integration of Repeaters with Presence

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

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

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

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

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

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

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

4.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 14. 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 15. 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 16. 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 17. 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.

5. Integration with Multi-User-Chat

This section shows how Multi-User Chat [4] 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 [5].

5.1 Entering a room

Example 18. 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 19. 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 20. 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>

5.2 Exiting a Room

Example 21. Occupant Exits a Room (C2S)

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

Example 22. 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 23. 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 24. 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>

5.3 Occupant is Kicked From Room

Example 25. 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 26. 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>

5.4 Sending a Message to all Occupants

Example 27. 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 28. 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>

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

7. Security Considerations

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

8. IANA Considerations

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

9. XMPP Registrar Considerations

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

10. XML Schemas

TBD

Notes

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

2. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.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. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

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

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

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)

Version 0.0.3 (2008-04-13)

added protocol section

(ph/cvl)

END