JEP-xxxx: Forwarding Request

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 <standards-jig@jabber.org> mailing list.


JEP Information

Status: ProtoJEP
Type: Informational
Number: xxxx
Version: 0.0.3
Last Updated: 2006-01-24
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0030, JEP-0033, JEP-0050, JEP-0131
Supersedes: None
Superseded By: None
Short Name: forwarding

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

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

Discussion Venue

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

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

Conformance Terms

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.


Table of Contents

1. Introduction
2. Requirements
3. Use Cases
3.1. Discover Support
3.2. Establish Forwarding
3.2.1. Old Account Requests Forwarding
3.2.2. New Account Confirms Forwarding
4. Security Considerations
5. IANA Considerations
6. Jabber Registrar Considerations
6.1. Service Discovery Features
6.2. Field Standardization
Notes
Revision History


1. Introduction

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 [1].

2. Requirements

This proposal addresses the following requirements:

  1. Enable an account owner to request that communications be forwarded to another address.
  2. Ensure appropriate access controls.

3. Use Cases

The following use cases assume two actors:

  1. Account Owner: A person or application that controls an account on a Jabber/XMPP server.
  2. Sender: A person or application that sends an XML stanza to an Account Owner's JID.

3.1 Discover Support

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 [2] 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.

Example 1. Disco request for information

<iq type='get'
    to='example.com'
    from='oldaccount@example.com'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

Example 2. Disco result for information

<iq type='result'
    from='example.com'
    to='oldaccount@example.com'
    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 [3] 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.

Example 3. Disco request for commands

<iq type='get'
    to='example.com'
    from='oldaccount@example.com'
    id='disco2'>
  <query xmlns='http://jabber.org/protocol/disco#items'
         node='http://jabber.org/protocol/commands'/>
</iq>
    

Example 4. Disco result for commands

<iq type='result'
    from='example.com'
    to='oldaccount@example.com'
    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>
    

3.2 Establish Forwarding

3.2.1 Old Account Requests Forwarding

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.

Example 5. Account Owner Initiates Forwarding Request

<iq type='set'
    from='oldaccount@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 [4] protocol.

Example 6. Empty Forwarding Form

<iq type='result'
    from='example.com'
    to='oldaccount@example.com/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 [5]) 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 (<node@domain.tld>) 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:

Example 7. Completed Forwarding Form

<iq type='set'
    from='oldaccount@example.com/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'>oldaccount@example.com</field>
      <field var='newaddress'>newaccount@example.net</field>
    </x>
  </command>
</iq>
      

Note: The old address SHOULD be of the form <node@domain.tld> but MAY be of the form <node@domain.tld/resource>, enabling the account owner to exercise more fine-grained control over forwarding if desired. If the old address is of the form <node@domain.tld/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.

Example 8. Request Successfully Processed

<iq type='result'
    from='example.com'
    to='oldaccount@example.com/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 oldaccount@example.com 
	to newaccount@example.net, pending approval by newaccount@example.net.
    </note>
  </command>
</iq>
      

3.2.2 New Account Confirms Forwarding

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:

Example 9. Server Requests Confirmation

<message 
    from='example.com'
    to='newaccount@example.net'
    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 oldaccount@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": [6]

Example 10. New Account Owner Confirms Request

<message 
    from='newaccount@example.net/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:

Example 11. Server Sends Informs Account Owner of Failure

<message from='example.com' to='oldaccount@example.com'>
  <body>
    Sorry, your request to forward mail to newaccount@example.net was
    not confirmed and therefore forwarding cannot be established.
  </body>
</message>
      

4. Security Considerations

A server MUST NOT establish forwarding until it has received confirmation of the forwarding request from the new address.

5. IANA Considerations

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

6. Jabber Registrar Considerations

6.1 Service Discovery Features

The Jabber Registrar [8] shall include 'http://jabber.org/protocol/forwarding' in its registry of service discovery features.

6.2 Field Standardization

To follow.


Notes

1. JEP-0133: Service Administration <http://www.jabber.org/jeps/jep-0133.html>.

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

3. JEP-0050: Ad-Hoc Commands <http://www.jabber.org/jeps/jep-0050.html>.

4. JEP-0004: Data Forms <http://www.jabber.org/jeps/jep-0004.html>.

5. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

6. In accordance with Section 3.2.2.1 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/>.


Revision History

Version 0.0.3 (2006-01-24)

Split forwarding semantics and forwarding request process into separate specifications. (psa)

Version 0.0.2 (2005-04-08)

Added confirmation protocol flow. (psa)

Version 0.0.1 (2005-03-03)

Initial version. (psa)


END