This document describes the XMPP extension used by Google Talk to prevent server-side logging of a chat with a specific contact.
Note: This extension is not intended to become a standard and is subject to change.
Table of Contents
setting can be used to enable or disable chat logging on the
server for all conversations at once. However, a user might like
a way to turn off logging for individual conversations. Google Talk
enables this through an XMPP extension. At a client's request, the
Google Talk server disables server-side logging of individual conversations
and sends notifications; considerate client applications indicate
the logging state to the user and disable client-side chat logging
when either user in a conversation turns off server side logging.
The setting that describes an individual logging state is called the nosave setting. There is a nosave setting between every user and every other user in their roster. This setting is stored by the server, and it specifies whether or not to archive chats between those two users. nosave can have one of the following two values:
- enabled Chats will not be archived
- disabled Chats will be archived
The default value is disabled.
Before attempting to turn off logging individually, a client must first learn whether a server supports this extension by using service discovery. A client should send the following IQ stanza to discover what features the server supports.
Example 1. Client service discovery request
<iq type='get' to='gmail.com'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
If the server supports the disable archiving extension, the reply will include the 'google:nosave' feature as shown here:
Example 2. Client service discovery response
<iq type='result' firstname.lastname@example.org' from='gmail.com'> <query xmlns='http://jabber.org/protocol/disco#info'> ... <feature var='google:nosave'/> ... </query> </iq>
A chat client should display the nosave state to the user to let them know whether a conversation is being saved. The Google Talk server exposes nosave state in two ways:
- It includes an
<x/>element inside every message that gives the current nosave state.
- Any client can explicitly request all nosave states for all its roster members from the server.
<message/> stanza sent between two clients through
the Google Talk server includes an
<x/> element that
describes the nosave state between those clients. For example, when a
client sends the following message:
Example 3. Client sends a message
<message email@example.com' firstname.lastname@example.org'> <body>O day and night, but this is wondrous strange!</body> </message>
The server inserts an
<x xmlns='google:nosave' /> element
with a value attribute describing the nosave state. The resulting
message, shown here, is sent to the message recipient:
Example 4. Server inserts off the record state
<message email@example.com' firstname.lastname@example.org'> <body>O day and night, but this is wondrous strange!</body> <x xmlns='google:nosave' value='disabled' /> </message>
If the nosave state conflicts with the value expected by the recipient, the recipient should explicitly query the state, as described next.
To request the current nosave state for all members of the current user's
roster, a client sends an IQ get containing a
qualified by the 'google:nosave' namespace, as shown here:
Example 5. Client requests nosave states for all roster members
<iq type='get' email@example.com/castle' firstname.lastname@example.org' id='otr-1'> <query xmlns='google:nosave' /> </iq>
This query returns nosave values for all members of that user's roster, whether or not they are signed in. You cannot request the nosave state of a specific roster member.
The first time this request is sent, in addition to returning the current user states, the server subscribes the client to receive notifications whenever any contact changes the nosave state of a chat with them.
The server responds to an explicit request with an IQ result containing
<query/> IQ stanza qualified by the 'google:nosave'
<query/> IQ stanza contains an
for each contact in the roster. Each
has a value attribute that is set to "enabled" or "disabled".
Note: Even if an
<item/> element is
listed as "disabled", Google Talk Server will not archive a
conversation unless the
archivingenabled user setting is
set to "true", as described in User
The following response lists the nosave settings for four contacts.
Example 6. Server responds with nosave states
<iq type='result' email@example.com' firstname.lastname@example.org/castle' id='otr-1'> <query xmlns='google:nosave'> <item xmlns='google:nosave' email@example.com' value='disabled' /> <item xmlns='google:nosave' firstname.lastname@example.org' value='disabled' /> <item xmlns='google:nosave' email@example.com/castle' value='enabled' /> <item xmlns='google:nosave' firstname.lastname@example.org' value='disabled' /> </query> </iq>
When a client wishes to change their nosave state for a specific user,
it sends the server a
<query/> IQ stanza qualified
by the "google:nosave" namespace. This element should contain
<item/> stanza for each contact whose nosave state
should be changed. The following stanza is a request to block chat archiving
with one contact:
Example 7. Client changes nosave state for one contact
<iq type='set' email@example.com/castle' firstname.lastname@example.org' id='otr-2'> <query xmlns='google:nosave'> <item xmlns='google:nosave' email@example.com' value='enabled'/> </query> </iq>
If the requests fails, it will send an error response. If it succeeds, it will send an empty response similar to the following example:
Example 8. Server response to an accepted setting change
<iq type='result' firstname.lastname@example.org/castle' id='otr-2' />
The server then broadcasts the new states to all clients who have been affected, as well as all instances of the current user that have previously queried the nosave state. These notifications are described below. Any client that receives a notification that archiving has been turned off should alert the user and turn off local chat archiving.
When a client changes a nosave state, The Google Talk service sends the following two notifications to both parties in the relationship:
- An IQ set stanza indicating the change
<message/>stanza that contains only an
<x/>element describing the new state.
Both these notifications are described below.
When a client changes the nosave state between itself and another contact, the server sends a notification to all registered instances of both parties. Clients should listen for these notifications, and turn local logging on or off and alert the user appropriately.
This notification consists of a
<query/> element with
<item/> element for each state changed. This is
similar to the IQ result returned for an explicit nosave state query
(described previously), except that each
has a source attribute set to the JID of the user that changed
the state. The following notification is sent to Horatio and Guildenstern
when Horatio enables archiving in his conversation with Guildenstern:
Example 9. Server sends a nostate change notification
<iq type='set' email@example.com/field' id='otr-3'> <query xmlns='google:nosave'> <item firstname.lastname@example.org' email@example.com/castle' value='enabled' /> </query> </iq>
In addition to an IQ set, when a client changes the nosave state an off-the-record
server will send an empty
<message/> stanza with an
to the recipient only. So, for example, if Hamlet changes his nosave
state with Horatio, Hamlet's server will send the following stanza to
Example 10. Server sends empty message with new off-the-record state
<message firstname.lastname@example.org' email@example.com'> <x xmlns='google:nosave' value='disabled' /> </message>
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.