This document specifies a method to request forwarding of stanzas from one address to another.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <firstname.lastname@example.org> mailing list.
Last Updated: 2006-01-24
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0030, JEP-0033, JEP-0050, JEP-0131
Superseded By: None
Short Name: forwarding
This Jabber Enhancement Proposal is copyright 1999 - 2006 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.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/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) 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 protocol defined in this JEP 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.
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.
The concept of communications forwarding is familiar from email and, before that, from postal mail: communications sent to one address are automatically re-directed to another address. Such forwarding can help make communications smoother when, for instance, people or applications move to new locations. In postal mail systems, such functionality is usually implemented by the entity responsible for delivery of communications within the locality of the original address (e.g., a local post office), as initiated by the person or organization that requires the change of address. The model is similar in electronic mail systems, often implemented by means of a .forward file.
This document specifies a method for setting up forwarding at a server. A companion document defines syntax and semantics for delivery of forwarded stanzas.
Note: Rather than allowing user-driven requests for stanza forwarding, a server MAY allow only a server administrator to establish stanza forwarding on behalf of a user; a method for doing so is specified in Service Administration .
This proposal addresses the following requirements:
The following use cases assume two actors:
If an entity (e.g., an Account Owner or another server) wants to discover whether a particular server supports, it MUST send a Service Discovery  information request to the server. If the server supports forwarding addresses, it MUST include a feature variable of "http://jabber.org/protocol/forwarding" in its disco#info response.
<iq type='get' to='example.com' email@example.com' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
<iq type='result' from='example.com' firstname.lastname@example.org' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'> ... <feature var='http://jabber.org/protocol/commands'/> <feature var='http://jabber.org/protocol/forwarding'/> ... </query> </iq>
Because the server supports the Ad-Hoc Commands  protocol, account owner SHOULD also query the server regarding the specific commands it supports by sending a disco#items query to the fixed node "http://jabber.org/protocol/commands". If the server supports forwarding addresses, it MUST include the command "forwarding" in its response.
<iq type='get' to='example.com' email@example.com' id='disco2'> <query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/protocol/commands'/> </iq>
<iq type='result' from='example.com' firstname.lastname@example.org' id='disco2'> <query xmlns='http://jabber.org/protocol/disco#items' node='http://jabber.org/protocol/commands'> ... <item jid='example.com' node='forwarding' name='Forwarding Address Service'/> ... </query> </iq>
In order to request conversion of an existing account into a forwarding address, the Account Owner MUST send an IQ-set to its server containing the "forwarding" command.
<iq type='set' email@example.com/resource' to='example.com' id='request1'> <command xmlns='http://jabber.org/protocol/commands' node='forwarding' action='execute'/> </iq>
Unless an error occurs (see below), the server then MUST return an appropriate form to the account owner, structured via the Data Forms  protocol.
<iq type='result' from='example.com' firstname.lastname@example.org/resource' id='request1'> <command xmlns='http://jabber.org/protocol/commands' sessionid='forwarding:20050923T213616Z-700' node='forwarding' status='executing'> <actions execute='next'> <next/> </actions> <x xmlns='jabber:x:data' type='form'> <title>Request Forwarding</title> <instructions> Please fill out the following form to request forwarding for your address. </instructions> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/forwarding</value> </field> <field label='Old Address' type='jid-single' var='oldaddress'> <required/> </field> <field label='New Address(es)' type='jid-multi' var='newaddress'> <required/> </field> </x> </command> </iq>
(Naturally, the data form might include more advanced fields, such as a start time and end time for the forwarding period.)
The server MUST stamp or validate the 'from' address (in accordance with XMPP Core ) before processing the address forwarding initiation command. If the domain identifier portion of the sender's 'from' address does not match the 'to' address of the server to which the request is sent (e.g., because the command was received over a server-to-server connection), then the server MUST return a <forbidden/> error to the sender. Additionally, if the bare JID (<email@example.com>) portion of the 'from' address does not match the bare JID portion of the old address specified in the form, then the server MUST also return a <forbidden/> error to the sender.
Upon receiving the form, the account owner SHOULD return a completed form but MAY cancel the forwarding process as described in JEP-0050. The form submission might look like this:
<iq type='set' firstname.lastname@example.org/resource' to='example.com' id='request2'> <command xmlns='http://jabber.org/protocol/commands' sessionid='forwarding:20050923T213616Z-700' node='forwarding'> <x xmlns='jabber:x:data' type='form'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/forwarding</value> </field> <field var='oldaddress'>email@example.com</field> <field var='newaddress'>firstname.lastname@example.org</field> </x> </command> </iq>
Note: The old address SHOULD be of the form <email@example.com> but MAY be of the form <firstname.lastname@example.org/resource>, enabling the account owner to exercise more fine-grained control over forwarding if desired. If the old address is of the form <email@example.com/resource> but the server does not support forwarding by resource (i.e., if it only forwards all stanzas sent to the account owner's JID, regardless of resource), the server MUST return a <not-acceptable/> error message to the sender.
If no error occurs, the server SHOULD process the form and inform the owner of the old address that forwarding will be established as soon as the server receives approval by the new address.
<iq type='result' from='example.com' firstname.lastname@example.org/resource' id='request2'> <command xmlns='http://jabber.org/protocol/commands' sessionid='forwarding:20050923T213616Z-700' node='forwarding' status='completed'> <note type='info'> Forwarding has been provisionally established from email@example.com to firstname.lastname@example.org, pending approval by email@example.com. </note> </command> </iq>
To help prevent bad actors from establishing forwarding to addresses they do not control, the server MUST send a confirmation request to the new address and receive positive confirmation before beginning to redirect messages from the old address to the new address.
First, the server sends a <message/> to the new address containing a data form requesting approval of the forwarding request:
<message from='example.com' firstname.lastname@example.org' id='confirm1'> <x xmlns='jabber:x:data' type='form'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/forwarding</value> </field> <field var='allow' type='boolean' label='Allow forwarding from email@example.com?'> <value>false</value> </field> </x> </message>
In order to confirm the forwarding request, the owner of the new account must return the data form with the boolean "allow" field set to a value of "true" or "1": 
<message firstname.lastname@example.org/someresource' to='example.com' id='confirm1'> <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/forwarding</value> </field> <field var='allow'> <value>1</value> </field> </x> </message>
Until and unless the server receives a properly-completed form from the owner of the new account, it MUST NOT establish forwarding. If the server does not receive confirmation within a configurable length of time (e.g., 24 hours), it SHOULD either resend the confirmation request message or delete the original forwarding request. Once the server receives a properly-completed form from the owner of the new account, it MUST establish forwarding and process incoming stanzas for the old account as described in the next section of this document. If the server does not receive a properly-completed form from the owner of the new account after a configurable number of retries, it MUST send a message to the owner of the old account:
<message from='example.com' email@example.com'> <body> Sorry, your request to forward mail to firstname.lastname@example.org was not confirmed and therefore forwarding cannot be established. </body> </message>
A server MUST NOT establish forwarding until it has received confirmation of the forwarding request from the new address.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) .
The Jabber Registrar  shall include 'http://jabber.org/protocol/forwarding' in its registry of service discovery features.
6. In accordance with Section 22.214.171.124 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.
7. 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/>.
8. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.