This document specifies best practices for delivery of stanzas that are forwarded 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.
Status: ProtoJEP
Type: Informational
Number: xxxx
Version: 0.0.4
Last Updated: 2006-03-13
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0030, JEP-0033, JEP-0131
Supersedes: None
Superseded By: None
Short Name: forwarding
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
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 syntax and semantics for delivery of forwarding stanzas in Jabber/XMPP systems. A companion document defines a method for setting up forwarding at a server.
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 [1] 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/forwarding'/>
...
</query>
</iq>
Once forwarding is established from an old address to a new address, the server MUST redirect all stanzas sent to the old address (including any resource thereof) to the new address.
Example 3. Sender Communicates with Forwarded Address
<message from='entity@example.org/resource' to='oldaccount@example.com'>
<body>Hi!</body>
</message>
Before the server forwards the stanza, it MUST add a NumForwards Stanza Headers and Internet Metadata (SHIM) [2] header to the stanza (whose character data is the number 1) if there is no such header already included in the stanza, or if the stanza already includes such a header it MUST increment the value of the NumForwards header by 1 and include the revised NumForwards header in the stanza. (Inclusion and incrementing of the NumForwards header helps to prevent infinite forwarding loops; see the Security Considerations.)
In addition, the server MUST include 'oto' and 'ofrom' Extended Stanza Addressing [3] addresses so that the final recipient can determine the provenance of the stanza.
Example 4. Server Forwards Stanza
<message from='oldaccount@example.com' to='newaccount@example.net'>
<body>Hi!</body>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='NumForwards'>1</header>
</headers>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='oto' jid='oldaccount@example.com'/>
<address type='ofrom' jid='entity@example.org/resource'/>
</addresses>
</message>
Note: The 'oto' and 'ofrom' address types are not yet specified in JEP-0033; they will be added to that specification if this document advances to a status of Active within the Jabber Software Foundation's standards process.
Deployment of stanza forwarding introduces the possibility of a denial of service attack if infinite loops occur; therefore, a server that implements stanza forwarding MUST also implement checking and incrementing of the NumForwards header. In particular, a server MUST be configured with a reasonable default limit for the maximum number of acceptable forwards (e.g., 10), which MAY be further configurable by the server administrator but which MUST NOT be removable (or changeable to an unreasonable value).
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].
The Jabber Registrar [5] shall include 'http://jabber.org/protocol/forwarding' in its registry of service discovery features.
The Jabber Registrar shall include the following entry in its registry of SHIM headers.
<header>
<name>NumForwards</name>
<desc>The number of times a stanza has been forwarded (must be a positive integer).</desc>
<doc>JEP-xxxx</doc>
</header>
1. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
2. JEP-0131: Stanza Headers and Internet Metadata (SHIM) <http://www.jabber.org/jeps/jep-0131.html>.
3. JEP-0033: Extended Stanza Addressing <http://www.jabber.org/jeps/jep-0033.html>.
4. 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/>.
5. 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/>.
END