mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-13 21:05:09 -05:00
142 lines
7.3 KiB
XML
Executable File
142 lines
7.3 KiB
XML
Executable File
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Stanza Forwarding</title>
|
|
<abstract>This specification defines best practices for delivery of XMPP stanzas that are forwarded from one address to another.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>xxxx</number>
|
|
<status>ProtoXEP</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>forwarding</shortname>
|
|
&stpeter;
|
|
<revision>
|
|
<version>0.0.5</version>
|
|
<date>2009-04-10</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Changed service discovery feature to urn:xmpp:forwarding:0 in compliance with XMPP Registrar processes.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.4</version>
|
|
<date>2006-03-13</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Specified that from address of forwarded stanza must be JID of forwarding address (not server).</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.3</version>
|
|
<date>2006-01-24</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Split forwarding semantics and forwarding request process into separate specifications; defined security considerations.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.2</version>
|
|
<date>2005-04-08</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Added confirmation protocol flow.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2005-03-03</date>
|
|
<initials>psa</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>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.</p>
|
|
<p>This document specifies syntax and semantics for delivery of forwarding stanzas in XMPP systems. A companion document defines a method for setting up forwarding at a server.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p>This proposal addresses the following requirements:</p>
|
|
<ol start="1">
|
|
<li>Define syntax and semantics for stanza forwarding.</li>
|
|
<li>Prevent infinite forwarding loops.</li>
|
|
</ol>
|
|
</section1>
|
|
|
|
<section1 topic='Protocol' anchor='protocol'>
|
|
<p>Before stanzas can be forwarded, forwarding needs to be established from an old address to a new address. Methods for doing so are out of scope for this specification.</p>
|
|
<p>Once forwarding is established, the server MUST redirect all stanzas sent to the old address (including any resource thereof) to the new address.</p>
|
|
<example caption="A sender communicates with a forwarded address"><![CDATA[
|
|
<message from='entity@example.org/resource' to='oldaccount@example.com'>
|
|
<body>Hi!</body>
|
|
</message>
|
|
]]></example>
|
|
<p>Before the server forwards the stanza, it MUST add a NumForwards &xep0131; 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 <link url="#security">Security Considerations</link>.)</p>
|
|
<p>In addition, the server MUST include 'oto' and 'ofrom' &xep0033; addresses so that the final recipient can determine the provenance of the stanza.</p>
|
|
<example caption="Server forwards stanza"><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<p class='box'>Note: The 'oto' and 'ofrom' address types are not yet specified in the <cite>Extended Stanza Addressing</cite> specification; they will be added if this document advances to a status of Draft within the standards process of the &XSF;.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Determining Support' anchor='support'>
|
|
<p>If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:forwarding:1" in response to &xep0030; information requests &NSNOTE;.</p>
|
|
<example caption="Service discovery information request"><![CDATA[
|
|
<iq type='get'
|
|
to='example.com'
|
|
from='oldaccount@example.com'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
</iq>
|
|
]]></example>
|
|
<example caption="Service discovery information response"><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>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).</p>
|
|
</section1>
|
|
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This specification requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
|
|
<section2 topic='Service Discovery Features' anchor='registrar-disco'>
|
|
<p>The ®ISTRAR; shall include 'urn:xmpp:forwarding' in its registry of service discovery features.</p>
|
|
</section2>
|
|
<section2 topic='SHIM Headers' anchor='registrar-shim'>
|
|
<p>The XMPP Registrar shall include the following entry in its registry of SHIM headers.</p>
|
|
<code><![CDATA[
|
|
<header>
|
|
<name>NumForwards</name>
|
|
<desc>The number of times a stanza has been forwarded (must be a positive integer).</desc>
|
|
<doc>XEP-xxxx</doc>
|
|
</header>
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
|
|
</xep>
|