JEP-01xx: Roster Subscription Synchronization

This proposal defines a protocol that enables gateways to synchronize subscription to contacts between the legacy service and a user's contact list.


WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply acceptance or approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.


Author Information

James Bunton

Email: james@delx.cjb.net
JID: james@delx.cjb.net

JEP Information

Status: Experimental
Type: Standards Track
Number: 01xx
Version: 0.0.3
Last Updated: 2004-09-14
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP IM, JEP-0030
Supersedes: None
Superseded By: None
Short Name: roster-subsync

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <https://jabberstudio.org/mailman/listinfo/standards-jig>.

Discussion on the JSF-IETF list may also be appropriate if this JEP references IETF technologies (see <https://jabberstudio.org/mailman/listinfo/jsf-ietf> for details).


Table of Contents

1. Introduction
2. Terminology
3. Requirements
4. Use Cases
4.1. User of a legacy service moving to Jabber
4.2. Subscription on the legacy service has moved from 'none' to 'both'
4.3. Subscription on the legacy service has moved from 'none' to 'to'
4.4. Subscription on the legacy service has moved from 'none' to 'from'
4.5. Subscription on the legacy service has moved from 'both' to 'to'
4.6. Subscription on the legacy service has moved from 'both' to 'from'
4.7. Subscription on the legacy service has moved from 'both' to 'none'
4.8. Subscription on the legacy service has moved from 'from' to 'none'
4.9. Subscription on the legacy service has moved from 'to' to 'none'
4.10. Subscription on the legacy service has moved from 'from' to 'to'
4.11. Subscription on the legacy service has moved from 'to' to 'from'
5. Examples
6. Business Rules
6.1. Rules for the client
6.2. Rules for the gateway
7. Implementation Notes
7.1. For existing gateways
7.2. For existing clients
8. Security Considerations
9. IANA Considerations
10. Jabber Registrar Considerations
Notes
Revision History


1. Introduction

This a proposal for a quick and easy solution to the current issues with transport rosters with a simple extension to the existing presence subscription protocol as defined in XMPP IM [1].

The situation is:

  1. A user with an account on a legacy service will have a legacy contact list that will need to be synchronized with their Jabber contact list by the gateway
  2. The current way that gateways do this is illegal according to XMPP. It also no longer works in Jabberd2s3 (and it shouldn't, because it is a security flaw to allow arbitrary contacts to add themselves to your contact list)
  3. There are no existing protocols for shared roster groups, and we need a way for this to work quickly so that users can enjoy a seamless migration from their legacy service to Jabber
  4. A user should not have to reauthorize all their legacy system contacts on Jabber. They have already authorized them on the legacy service

2. Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].

The word "user" will always refer to the Jabber user, using the legacy service gateway. While "contact" always refers to a person on the legacy network that the user wishes to talk to.

The words "gateway", and "transport" are used interchangeably to refer to a Jabber entity that acts as a proxy for a Jabber client to access a legacy network.

3. Requirements

This extension will allow a client to know when a subscription request it has received is in fact redundant, because the user has already authorized that contact on the legacy service.

A simple, backwards compatible protocol extension is needed to allow clients that are willing to improve the user experience with gateways to do so.

This extension will also allow users who may use a Jabber gateway in combination with other clients for a legacy service to keep their rosters synchronized.

4. Use Cases

This protocol extension is useful for the initial import of contacts for a user of a legacy service moving to Jabber, as well as for keeping the legacy and Jabber contact lists subscriptions synchronized from then on.

4.1 User of a legacy service moving to Jabber

A user has been using MSN Messenger, and has acquired a large contact list on this service. The user has heard about Jabber and wants to try it out. They still want to be able to talk to their MSN friends, so they will use the MSN transport on their server (host.com)

The alternate flow for a client that does not have support for this proposal is that the user must reauthorize each contact manually, they still however will receive their contact list. The transport should check to see if the remote client has support for the roster-subsync protocol, and warn the user if it doesn't.

4.2 Subscription on the legacy service has moved from 'none' to 'both'

Synchronizing the addition of a contact to the user's legacy contact list, and the user's legacy account being added to that contact's list.

A user of the MSN transport has used the MSN Messenger program to add a contact to their list, and that contact has added the user to their own list.

4.3 Subscription on the legacy service has moved from 'none' to 'to'

Synchronizing the user adding a contact to their list.

A user of the MSN transport has added a contact to their MSN list.

4.4 Subscription on the legacy service has moved from 'none' to 'from'

Synchronizing the user granting authorization to the contact.

4.5 Subscription on the legacy service has moved from 'both' to 'to'

Synchronizing the user being removed from the contact's list.

A user of the MSN transport has been removed from the list one of their contacts.

4.6 Subscription on the legacy service has moved from 'both' to 'from'

Synchronizing a contact removing the user's authorization.

A user of the MSN transport has had his authorization removed by one of their contacts.

4.7 Subscription on the legacy service has moved from 'both' to 'none'

Synchronizing the removal of a contact from the user's legacy contact list, and the user's removal from that contact's list.

A user of the MSN transport has used the MSN Messenger program to remove a contact from their list, and the MSN contact has in turn removed the user.

4.8 Subscription on the legacy service has moved from 'from' to 'none'

Synchronizing the user's removal from a contact's list.

A contact of a user of the MSN transport has removed that user from their list.

4.9 Subscription on the legacy service has moved from 'to' to 'none'

Synchronizing the removal of a contact from the user's legacy contact list.

A user of the MSN transport has used the MSN Messenger program to remove a contact from their list, or the MSN contact has removed their authorization.

4.10 Subscription on the legacy service has moved from 'from' to 'to'

Synchronizing the addition of a contact to the user's legacy contact list, and the user's legacy account being removed from that contact's list.

A user of the MSN transport has used the MSN Messenger program to add a contact to their list, and that contact has romevd the user from their own list.

4.11 Subscription on the legacy service has moved from 'to' to 'from'

Synchronizing the removal of a contact from the user's legacy list, and the user being added to that contact's list.

A user of the MSN transport has used the MSN Messenger program to remove a contact from their list, and that contact has then added the user to their own list.

5. Examples

Example 20. A generic roster-subsync packet

<presence to='user@host.com' from='user%hotmail.com@msn.host.com' type='subscribe'>
	<x xmlns="http://jabber.org/protocol/roster-subsync">
		<item name="Contact Name" subscription="both">
			<group>Friends</group>
			<group>Colleagues</group>
		</item>
	</x>
</presence>
    

6. Business Rules

6.1 Rules for the client

The following rules must be followed by client developers in order to provide a good user experience with gateways, and to ensure security of the user's contact list.

  1. A client MUST ignore any additional item tags present in the presence subscription.
  2. A client SHOULD NOT prompt the user more than once per session for permission to synchronize roster subscriptions from a particular domain.
  3. If the client receives a presence subscription packet with an roster-subsync tag, but the originating domain is not authorized on the user's contact list, the client MUST ignore the roster-subsync tag, and treat the presence packet as normal. This prevents arbitrary Jabber users from auto-authorizing themselves.
  4. A client MUST check with the user at least once before synchronizing any contact subscriptions. The client SHOULD remember the user's answer and never ask them again while the transport remains authorized on the user's roster. This allows the transport to keep contact lists synchronized transparently. The client MAY however choose to ask the user permission once per session.
  5. A client MUST NOT automatically synchronize any contacts that do not have an roster-subsync tag.
  6. A client MUST advertize its support for roster-subsync in a Service Discovery [3] info request.

6.2 Rules for the gateway

The following rules must be followed by gateway developers in order to allow clients to provide a good user experience with gateways, and to ensure the security of the user's Jabber contact list.

  1. The transport MUST send a presence packet with an roster-subsync tag for any subscription modifications based on changes made to the legacy contact list by a client other than the transport itself.
  2. The transport MUST NOT send a presence packet with an roster-subsync tag in any other case (eg, when a legacy user requests subscription for the first time)
  3. Transports MAY add extra information into a single item tag, as shown above, in order to give the client extra hints about the contact.
  4. Tranports MUST send the correct presence type that corresponds with the subscription attribute.
  5. A transport SHOULD make a service discovery info request to check if the client supports roster-subsync. If not, the transport SHOULD warn the user before registration.
  6. Before connecting to the legacy service after registration, gateways MUST request authorization (via an ordinary presence type=subscribe) from the user, and wait for their response.

7. Implementation Notes

7.1 For existing gateways

A quick way to implement this protocol extension in existing transports is to send

Example 21. Valid import of MSN contact

	<presence type="subscribe">
		<x xmlns="http://jabber.org/protocol/roster-subsync">
			<item subscription="both">
		</x>
	</presence>
    
wherever the transport would previously have sent the following illegal packet to push the contact onto the user's list

Example 22. Invalid import of MSN contact

	<presence type="subscribed"/>
    

Transports must also change their registration process so that the transport does not log onto the legacy service until it has received a presence subscribed from the user.

7.2 For existing clients

The flows documented in the use cases above are summarized for clients in the table below.

Table 1: Roster Subscription Synchronization flow

Subscription attribute Presence type Client action
both subscribe Grant authorization. Request authorization.
both subscribed Nothing.
to subscribed Nothing.
to subscribe Deny authorization. Request authorization.
to unsubscribe Nothing.
to unsubscribe Request authorization.
from subscribe Grant authorization.
from unsubscribed Nothing.
from unsubscribed Nothing.
from subscribe Grant authorization.
none * Remove contact from roster.

8. Security Considerations

The security of the user's Jabber contact list is an important concern. If clients follow the business rules listed above then the users contact list will remain secure. This is provided that the user trusts the gateway they are using, but that trust is not dependent on the protocol used to deliver the legacy contact list to the user.

9. IANA Considerations

This proposal requires no interaction with the Internet Assigned Numbers Authority (IANA).

10. Jabber Registrar Considerations

The 'http://jabber.org/protocol/roster-subsync' namespace must be registered in the protocol namespaces registry maintained by the Jabber Registrar


Notes

1. XMPP IM <http://www.jabber.org/ietf/> (Proposed Standard, RFC number to follow).

2. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <http://www.ietf.org/rfc/rfc2119.txt>.

3. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.


Revision History

Version 0.0.3 (2004-09-14)

Added more use cases to demonstrate the use of the subscription attribute. (jcb)

Version 0.0.2 (2004-09-11)

Emphasize the subscription synchronization part of this proposal. Changed the syntax somewhat. (jcb)

Version 0.0.1 (2004-09-09)

Initial version. (jcb)


END