XEP-xxxx: Private Multi-User Conferencing

Jabber client pretends to be a Multi-User Conference server


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.1.5
Last Updated: 2007-05-17
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0045, XEP-0193, XEP-0201, XEP-0203
Supersedes: None
Superseded By: None
Short Name: Not yet assigned

Author Information

Bruce Campbell

Email: b+jabber@bruce-2007.zerlargal.org
JabberID: b@bruce-2007.zerlargal.org

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

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

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. Use Cases
    3.1. Outline
    3.2. Starting a Private Conference
    3.3. Actions of the Central Client During Chat
       3.3.1. Relaying Room Messages
       3.3.2. Relaying Private Messages
    3.4. Leaving a PMUC room
    3.5. Multiple PMUCs with a single client
    3.6. Redundant Conferencing
4. Security Considerations
5. IANA Considerations
6. XMPP Registrar Considerations
    6.1. SHIM Headers Registry
7. Worthy Mentions
Notes
Revision History


1. Introduction

This document briefly highlights how a 'standard' XMPP Client can appear to be a room in a Multi-User Conference. The initial impetus for this was the desire to have a 3-way chat with other XMPP Clients, without involving a 3rd-party MUC server.

2. Requirements

XEP-0045 MUST be followed in its entirety, especially all of the items declared as 'SHOULD'. At least one of the XMPP Clients MUST be using a server that allows multiple Resources to be bound onto one connection.

3. Use Cases

3.1 Outline

XEP-0045 describes (in section 7.6) how to convert a one-to-one chat into a multi-user conference. The weak link in this process flow is the involvement of a 4th party, the MUC server, in the 3-way (or more) chat. A perusal of the MUC specifications shows that there is a way for one of the parties in the one-to-one chat to act as a central conference room.

3.2 Starting a Private Conference

When one of the users wishes to convert a one-to-one chat to a Private Multi-User Conference (PMUC), it can only do so if its server supports binding multiple Resources. If the client knows that this is supported (or has forgotten whether 'urn:ietf:params:xml:ns:xmpp-bind' was supplied by the server), it MUST first attempt to register two additional Resources for use within the private conference; one for a submission address used for this specific PMUC (or indeed, any PMUC managed by this client), the other for its preferred nickname:

Example 1. Crone1 attempts to bind its submission resource and preferred nickname


<iq type='set' id='bind_1'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>cauldron</resource>
  </bind>
</iq>

<iq type='set' id='bind_2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>firstwitch</resource>
  </bind>
</iq>

Note: The resource bound as the PMUC submission address can be any Resource currently bound by the client, provided that the Resource is only used for this client's management of PMUC rooms.

Assuming that there is support for binding multiple resources, and the resources are not already in use, the server will supply successful acknowledgements.

Example 2. Crone1's server allows additional Resource binding

<iq type='result' id='bind_1'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>crone1@shakespeare.lit/cauldron</jid>
  </bind>
</iq>
<iq type='result' id='bind_2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>crone1@shakespeare.lit/firstwitch</jid>
  </bind>
</iq>

Note: From this point on, crone1@shakespeare.lit's client MUST supply a complete 'from' address on every stanza it sends out.

Note: If the server replies with a 'bad-request' error (indicating that the server does not support binding of multiple resources), this should be indicated to the User, who can ask (via the existing one-to-one chat) that the other entity set up the conference. If the server replies with a 'not-allowed' error, this may indicate that the server will not bind any additional resources, or that it will not bind that particular resource, or some other error. The client MAY try again with another resource, but MUST NOT enter a continual loop of trying to bind additional resources.

After binding the additional resources representing its own nickname in the upcoming conference and the full JID of the conference, the central client MUST issue an invitation to all JIDs that are to participate in the conference, using a 'from' of the JID to be used for addressing the room as a whole. In these examples, crone1@shakespeare.lit/cauldron is the full JID for the PMUC room, with crone1@shakespeare.lit being the central client.

Example 3. Central JID sends out invitations

<message
    from='crone1@shakespeare.lit/cauldron'>
    to='wiccarocks@shakespeare.lit/laptop'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1@shakespeare.lit/desktop'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue/>
    </invite>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</message>

<message
    from='crone1@shakespeare.lit/cauldron'>
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='crone1@shakespeare.lit/desktop'>
      <reason>This coven needs both wiccarocks and hag66.</reason>
      <continue/>
    </invite>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</message>

On receiving the invitations, the clients (wiccarocks@shakespeare.lit and hag66.shakespeare.lit) SHOULD prompt the user on whether to join the conference. Users MAY be warned that this appears to be a PMUC run by a central client (crone1@shakespeare.lit) instead of an 'actual' MUC server, based on the appearance of a Resource ('cauldron') in the invitation's 'from' field.

Note: Clients receiving invitations from what appears to be a nickname within a conference room (crone1@shakespeare.lit/cauldron) vs the bare JID of a conference room itself (crone1@shakespeare.lit) may be a little confused, as XEP-0045 specifies that such invitations should come from the bare JID of the room. Clients MAY ignore such invitations unless they are satisfied that the bare JID of the inviting party matches the bare JID of an entity that the client has been recently communicating with, or is in the client's roster (etc). However, clients MUST use the full JID (crone1@shakespeare.lit/cauldron) supplied in the invitation in further communication with the apparent room.

Note: The 'RoomID' shim header MUST be retained by the client, and MUST be included in every message sent to or from the PMUC room. This is to ensure that messages sent to multiple PMUC rooms can be properly differentiated by the central client, even if the central client is unable to get a seperate Resource for each PMUC room's submission address.

On deciding to join the conference (user confirmation or auto-join), or to change its nickname within a PMUC room, the clients MUST first query the apparent room (crone1@shakespeare.lit/cauldron) for the nickname that the client can use. The client MAY specify a preferred initial nickname (and probably should):

Example 4. Hag66 checks for nickname conflicts, and supplies a preferred nickname

<iq from='hag66@shakespeare.lit/pda'
    id='getnick1'
    to='crone1@shakespeare.lit/cauldron'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='x-roomuser-item'>
    <identity
        category='conference'
        name='thirdwitch'
        type='text'/>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </query>
</iq>

On receiving the above check for a particular nickname, the central client (crone1@shakespeare/desktop) attempts to bind the preferred nickname with its server:

Example 5. Crone1 attempts to bind the resource/nickname requested by Hag66

<iq type='set' id='bind_2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>thirdwitch</resource>
  </bind>
</iq>

If the server allows the binding of an additional Resource, it returns another JID to the client:

Example 6. Crone1's server allows additional Resource binding

<iq type='result' id='bind_2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>crone1@shakespeare.lit/thirdwitch</jid>
  </bind>
</iq>

The (central) client then returns the allowed nickname to the requesting client:

Example 7. Crone1's informs Hag66 that the nickname can be used

<iq from='crone1@shakespeare.lit/cauldron'
    id='getnick1'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='x-roomuser-item'>
    <identity
        category='conference'
        name='thirdwitch'
        type='text'/>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </query>
</iq>

Note: If the server did not allow the binding of the additional Resource, or the requested nickname is already in use by another participant, the central client MUST invite the requesting client to supply another preferred nickname, as per XEP-0045.

Finally, the requesting client sends its initial presence to the 'room' (central client), supplying its preferred nickname and the RoomID header:

Example 8. Hag66 now attempts to join the room.

<presence
    from='hag66@shakespeare.lit/pda'
    to='crone1@shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

The central client then responds with the presence stanzas of the other participants:

Example 9. Hag66 receives presence stanzas from Crone1

<presence
    from='crone1@shakespeare.lit/firstwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' role='moderator'
	jid="crone1@shakespeare.lit/desktop"/>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

<presence
    from='crone1@shakespeare.lit/secondwitch'
    to='hag66@shakespeare.lit/pda'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' role='participant'/>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

<presence
    from='crone1@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'/>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

The other initial steps described in XEP-0045 should be followed, including notifying other participants that 'thirdwitch' joined, the playback of selected history of the chat, etc.

Note: The 'RoomID' header uniquely identifies the nominated PMUC room. It MUST be included in the initial presence sent by the client.

Note: The central client SHOULD identify which nickname is its own, by supplying a 'jid' attribute listing its original resource ('crone1@shakespeare.lit/desktop'). The JIDs of the other participants may or may not be revealed, depending on whether the room is considered to be semi-anonymous or non-anonymous. Since the central client must know the full JID of every participant, the room cannot be considered to be fully anonymous, although the central client may not necessarily take up the role of moderator.

3.3 Actions of the Central Client During Chat

3.3.1 Relaying Room Messages

Assuming that all invited JIDs took up the invitations, there is now an Private Multi-User Conference in a room named 'cauldron' with a submission JID of 'crone1@shakespeare.lit/cauldron', with three participants, being 'crone1@shakespeare.lit/firstwitch' (crone1@shakespeare.lit/desktop), 'crone1@shakespeare.lit/secondwidth' (wiccarocks@shakespeare.lit/laptop) and 'crone1@shakespeare.lit/thirdwidth' (hag66@shakespeare.lit/pda). The central Client now has the responsibility of distributing messages to all JIDs participating in the conference:

Example 10. Hag66 sends a message to the room

<message
    from='hag66@shakespeare.lit/pda'
    to='crone1@shakespeare.lit/cauldron'
    type='groupchat'>
  <body>Harpier cries 'Tis time, 'tis time.</body>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
</message>

Example 11. The central client sends the message outwards to other participants

<message
    from='crone1@shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='groupchat'>
  <body>Harpier cries 'Tis time, 'tis time.</body>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
</message>

<message
    from='crone1@shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'
    type='groupchat'>
  <body>Harpier cries 'Tis time, 'tis time.</body>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
</message>

Note: The central client MUST NOT send stanzas back to itself by way of its server. Instead, stanzas that would be sent from itself (as central client) to itself (as participant) should be processed internally as though it was received from the server.

Note: XEP-0046 specifies that messages sent to the room should be sent to the bare JID. When sending messages to a PMUC room however, sending a 'groupchat' message to the bare JID of the central client may end up at an instance of the client that does not know about the room, and thus be effectively lost. Clients participating in a PMUC room MUST always send 'groupchat' messages destined for the PMUC room to the full JID specified in the original invitation, and MUST include the 'RoomID' shim header as supplied in the original invitation. The central client MUST verify that each incoming 'groupchat' message contains a valid 'RoomID' header and was addressed to the correct submission address, and reject the message if these conditions are not met.

Note: Clients acting as a central client MUST implement checks on duplicate transmission as described below, and SHOULD apply rate limitations.

Note: Clients acting as a central client MAY add a urn:xmpp:delay stamp to the message stanza if one is not already present.

3.3.2 Relaying Private Messages

The central client should also forward private messages, as per XEP-0045:

Example 12. Hag66 sends a private message to be relayed.

<message
    from='wiccarocks@shakespeare.lit/pda'
    to='crone1@shakespeare.lit/firstwitch'
    type='chat'>
  <body>Her time, more like.</body>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
</message>

Example 13. The private message is relayed

<message
    from='crone1@shakespeare.lit/secondwitch'
    to='crone1@shakespeare.lit/desktop'
    type='chat'>
  <body>Her time, more like.</body>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
</message>

Note: The central client MUST NOT forward messages sent to the individual room nicknames (eg, crone1@shakespeare.lit/secondwitch) to any participants other than the one named. The central client SHOULD relay messages sent from one participant to another participant, but MAY refuse to do so based on its own administrative settings.

Note: Private messages intended for relay by the central client MUST include the 'RoomID' header, even though the message is not destined for the room. This ensures that messages intended for the central client which are broadcast to all Resources bound by the central client are not forwarded onto the PMUC participant.

3.4 Leaving a PMUC room

A participant may leave a PMUC room for any of the reasons described in XEP-0045. The central client should follow XEP-0045:

Example 14. Hag66 leaves the room.

<presence
    from='hag66@shakespeare.lit/pda'
    to='crone1@shakespeare.lit/thirdwitch'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

The central client then confirms this by sending an 'unavailable' stanza to each participant, including the one that has just left:

Example 15. Hag66 receives confirmation from the room

<presence
    from='crone1@shakespeare.lit/thirdwitch'
    to='hag66@shakespeare.lit/pda'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

<presence
    from='crone1@shakespeare.lit/thirdwitch'
    to='crone1@shakespeare.lit/desktop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

<presence
    from='crone1@shakespeare.lit/thirdwitch'
    to='wiccarocks@shakespeare.lit/laptop'
    type='unavailable'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <headers xmlns='http://jabber.org/protocol/shim'>
     <header name='RoomID'>cauldron</header>
    </headers>
  </x>
</presence>

If this is the only PMUC room that the participant's nickname was being used in, the central client MUST immediately unbind the Resource used for the nickname. If the participant is still using this nickname in other rooms, the Resource MUST NOT be unbound.

Note: The central client MAY leave a PMUC room that it is hosting without closing the PMUC room. However, this is not suggested as the User now does not see conversations going on in the PMUC room, and in some jurisdictions, may be held liable for actions taken in the PMUC room even though there is no oversight. Implementations MAY eject all other participants from a PMUC room when the central client leaves a PMUC room that it is hosting.

Note: An 'unavailable' presence may have been generated by the server of the participant as a result of the participant logging off. If the participant was in multiple PMUC rooms, multiple 'unavailable' presence stanzas MAY be received, one for each PMUC rooms. A central client SHOULD check whether the participant has logged off (leaving all PMUC rooms) or has just left a single PMUC room.

3.5 Multiple PMUCs with a single client

It should be noted that a given PMUC room, and its list of participants, is identified by the value of the 'RoomID' header. By changing this value, a single client can host multiple PMUC rooms.

A central client SHOULD use a different full JID as a submission address for each PMUC room that it hosts, but MAY utilise the same full JID as the submission/management address for every PMUC room that it hosts where circumstances dictate. Clients participating in PMUCs MUST NOT expect that each PMUC room hosted by a single client will have a different full JID as the submission/management address. While a central client is managing (a) PMUC room(s), the full JID used as their PMUC submission/management address MUST NOT be used for any purpose apart from PMUC while any PMUC room is using that address.

Note: A central client may use its connect Resource to manage a PMUC room, but Implementations should be aware that doing so precludes the client from using said connect Resource for other purposes, such as one-on-one chats etc, for the duration of the PMUC room.

Resources bound to represent nicknames of participants must only be used in conjunction with the PMUC room, and MUST be unbound once the participant has left all PMUC rooms the participant was in, or said PMUC rooms have been closed.

Note: A Resource bound for a given remote JID's nickname MUST always point to that remote JID, even if the remote JID is a participant in multiple PMUC rooms. A given remote JID can naturally request a seperate nickname for each PMUC room, or it can use the same nickname in each room.

3.6 Redundant Conferencing

The above setup describes a single client acting as the central client. Naturally, the conference only lasts as long as that particular client instance remains connected, and is subject to various issues covered in the Security section.

This section is intended to describe a way of having more than one client acting as the central client for a single PMUC room. Doing so in a scalable fashion is presenting problems however, so this is just a placeholder for now.

4. Security Considerations

The central client is in a perfect position to manipulate the messages being passed between participants in the conference. Security-aware clients should avoid placing too much trust in the central client, and SHOULD sign all stanzas sent to the apparent conference. Following the redundant conferencing section above may give greater confidence towards a message arriving to all participants in its original form.

If clients participating in the conference receive a signed stanza that fails verification, or starts receiving unsigned stanzas from a participant that previously signed their stanzas, the client MUST NOT participate further in the conference (beyond sending an 'unavailable' presence stanza to the room JID to be polite), and MUST alert the User to a possible security breach.

If clients are utilising encryption between themselves and the central client, they MUST NOT assume that the central client will transmit the stanzas onwards in an encrypted form.

Not implementing the loop detection could result in your server (or administrator) disconnecting your client.

Implementations of the central client MUST NOT use the Resources bound for the PMUC submission/management and the PMUC nicknames to send out presence stanzas that relate solely to the central client.

5. IANA Considerations

This document requires no interaction with IANA.

6. XMPP Registrar Considerations

6.1 SHIM Headers Registry

The XMPP Registrar shall add "RoomID" to its registry of SHIM headers. The submission is as follows:

<header> <name>RoomID</name> <desc> This header is used to authoritatively identify the name of the room used in PMUC conversations. </desc> <doc>XEP-XXXX</doc> </header>

7. Worthy Mentions

This document has its origins in http://www.jabber.org/muc-logs/jdev@conference.jabber.org/2007-05-11.html ; Dag, stpeter, Kev and TobiasFar should be listed as co-conspirators, along with Andreas Monitzer.


Notes


Revision History

Version 0.1.5 (2007-05-17)

Run through cases using 'RoomID' header, removed Redundant conferencing for now

(bxc)

Version 0.1.4 (2007-05-16)

Changed to using 'RoomID' header after talking with Andreas Monitzer

(bxc)

Version 0.1.1 (2007-05-14)

First draft.

(bxc)

END