We announced a new communications product, Hangouts, in May 2013. Hangouts will replace Google Talk and does not support XMPP.

JID Domain Discovery

This document describes the XMPP extension used by Google Talk to enable gmail.com and googlemail.com clients to sign in to the Google Talk server with an incorrect domain.

Note: This extension is not intended to become a standard

Table of Contents

  • Introduction
  • Determining Server Support
  • Initiating the Authentication Request
  • About Google Talk Extensions
  • Introduction

    Google Talk now supports several domain names for usernames. This extensions allows users with accounts in the gmail.com or googlemail.com domain to sign in using either domain. This extension is only useful to clients with specific knowledge of the Google Talk Service.

    Best practice for all client applications to sign in to the Google Talk service is as follows:

    1. If the user specifies a domain name (e.g., someone@gmail.com), use that. If no domain name is given, use gmail.com as the default sign-in domain.
    2. As part of the authentication request, set the client-uses-full-bind-result attribute to "true" as described in this document.
    3. Use the JID returned by the server, which will specify the correct domain.

    Determining Server Support

    Unlike other XMPP extensions, server support is not available for this extension. This is because service discovery can only occur after signing in, and this extension is part of the sign-in process. If a server does not support this capability, it will ignore the extra attributes.

    Initiating the Authentication Request

    When a client sends authentication method to the server, it must add two new attributes to the <auth> element. These elements set the client-uses-full-bind-result attribute to "true."

    Example 1. Client selects an authentication method

    <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
      ... name and password information

    If the user does not enter a domain name, the service should use the domain gmail.com in the initial authentication request.

    The client-uses-full-bind-result value indicates a pledge that the client will use the full JID returned by the server in the bind response rather than the domain that it submitted in the authentication request.

    Example 2. Client receives the full JID that it should use

    <iq id="0" type="result">
      <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">

    The JID returned in the bind result is the one that the client should use for all communication.

    Here is an abbreviated exchange between client and server, where the client contacts the server with the gmail.com domain, and is assigned a JID with the googlemail.com domain. The client must then use the assigned googlemail.com node domain.

    Example 3. Client and server negotiate a connection and domain

    >>>>>>>>>>>>>>>>>>>>>>>>> Client sends sign-in information...
    <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" 
    ... encoded user name and password ... user=example@gmail.com password=supersecret
    <<<<<<<<<<<<<<<<<<<<<<<<< Server sends success...
    <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
    >>>>>>>>>>>>>>>>>>>>>>>>> Client initiates a new stream...
    <stream:stream to="gmail.com" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
    <<<<<<<<<<<<<<<<<<<<<<<<< Server sends stream header and binding feature...
    <?xml version="1.0" encoding="UTF-8"?>
    <stream:stream from="gmail.com" id="X86C60D2CEA180A3E" version="1.0" xmlns:stream=" http://etherx.jabber.org/streams" xmlns="jabber:client">
      <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
      <session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>
    >>>>>>>>>>>>>>>>>>>>>>>>> Client sends binding information...
    <iq type="set" id="0">
      <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
    <<<<<<<<<<<<<<<<<<<<<<<<< Server sends new JID in bind result...
    <iq id="0" type="result">
      <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">

    About Google Talk Extensions

    Extensibility is one of the greatest strengths of XMPP, the IETF standard protocol on which Google Talk is built. While XMPP itself defines a bare set of features, the protocol encourages third parties to develop their own extensions. During the development of Google Talk, we found it useful to define extensions to implement features not already found in XMPP or any of its currently defined extensions.The protocol defined in this document is currently used by the Google Talk clients and servers. However, note that it is not currently part of a proposed standardized extension, and therefore may change as we work to standardize these features.