XEP-xxxx: MUC Auto-Join

This document defines a method for IM users to automatically join a multi-user chat room on login.


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

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.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. Process Flow
3. Determining Support
4. Security Considerations
5. IANA Considerations
6. XMPP Registrar Considerations
    6.1. Service Discovery Features
7. Acknowledgements
Notes
Revision History


1. Introduction

Multi-User Chat [1] defines a protocol for multi-user text chat in XMPP. Sometimes it is desirable for a user to automatically join a room on login. Some Jabber clients make this possible by storing the chatroom address via Bookmark Storage [2]. However, since the chatroom address is simply a Jabber Identifier (JID), it makes sense to store the address in the XMPP roster rather than in a specialized storage location. If the chatroom JID is stored in the roster and the user regularly visits the room, it also makes sense to share presence with the room. This enables the room to know when the user comes online and to send the user an invitation to join the room on login. A method for enabling that functionality is defined in this document.

2. Process Flow

If a user wants to share presence with a MUC room, it can send the room a subscription request:

Example 1. User Subscribes to Room

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

Note: If the user simply wishes to bookmark the room but not to share presence with it, it can simply add the room to its roster without requesting a presence subscription:

Example 2. User Adds Room to Roster

<iq type='set'
    from='hag66@shakespeare.lit/pda'
    id='roster1'>
  <query xmlns='jabber:iq:roster'>
    <item jid='darkcave@macbeth.shakespeare.lit'
  </query>
</iq>
  

Upon receiving a presence subscription request from the user, the room SHOULD approve the request and also send a subscription request to the user:

Example 3. Room Approves Subscription Request

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

Example 4. Room Subscribes to User

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

Alternatively, if the user completes the Registering with a Room described in XEP-0045, the room SHOULD send a subscription request to the user:

Example 5. Room Subscribes to User

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

The user SHOULD then approve the subscription request:

Example 6. User Approves Subscription Request

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

Either way, the room now will receive presence updates from the user.

If the user logs in, the room will now receive presence from the user:

Example 7. User Logs In

<presence
    from='hag66@shakespeare.lit'
    to='darkcave@macbeth.shakespeare.lit'/>
  

Upon receiving presence from the user, the room SHOULD send an invitation request from itself to the user:

Example 8. Room Sends Invitation to User

<message
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite from='darkcave@macbeth.shakespeare.lit'/>
  </x>
</message>
  

The user's client then either presents the invitation to the user or (based on local configuration settings) automatically sends a join request to the room:

Example 9. User Enters Room

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

3. Determining Support

If a MUC room or service supports the presence sharing and auto-join functionality defined herein, it SHOULD return a feature of "http://jabber.org/protocol/muc#autojoin" in response to Service Discovery [3] information requests.

4. Security Considerations

To follow.

5. IANA Considerations

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

6. XMPP Registrar Considerations

6.1 Service Discovery Features

The XMPP Registrar shall add the following feature to its registry of service discovery features (see <http://www.xmpp.org/registrar/disco-features.html>).

<var>
  <name>http://jabber.org/protocol/muc#autojoin</name>
  <desc>The room or service supports MUC auto-join.</desc>
  <doc>XEP-xxxx</doc>
</var>
    

7. Acknowledgements

Thanks to Mridul Muralidharan for encouragement.


Notes

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

2. XEP-0048: Bookmark Storage <http://www.xmpp.org/extensions/xep-0048.html>.

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

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


Revision History

Version 0.0.1 (2007-06-01)

First draft.

(psa)

END