<abstract>This document specifies an XMPP protocol extension that enables entities to include RFC822-style address headers within XMPP stanzas in order to specify multiple recipients or sub-addresses.</abstract>
<remark>Re-worked to simpler/more structured XML.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-04-19</date>
<initials>jjh</initials>
<remark>Initial version.</remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>On the existing Jabber network, there are many opportunities to optimize stanza traffic. For example, clients that want to send the same stanza to multiple recipients currently must send multiple stanzas. Similarly, when a user comes online the server sends many nearly-identical presence stanzas to remote servers.</p>
<p>The 'http://jabber.org/protocol/address' specification provides a method for both clients and servers to send a single stanza and have it be delivered to multiple recipients, similar to that found in &rfc0822;. As a side-effect, it also provides all of the functionality specified by the old 'jabber:x:envelope' <note><linkurl='http://www.jabber.org/old-docs/proto-draft/envelope.html'>jabber:x:envelope</link> - Message Envelope Information Extension</note> proposal, which this XEP can supersede.</p>
<p>Support for Extended Stanza Addressing in a given server instance SHOULD be determined using &xep0030;. A conforming server MUST respond to disco#info requests.</p>
<p>The IM service MAY implement multicast directly, or it MAY delegate that chore to a separate service. A client can use the following approach to find a multicast-capable service hosted by its domain:</p>
<ol>
<li>Send a disco#info request to the IM server; if its reply includes the 'http://jabber.org/protocol/address' feature, then it is a multicast-capable service.</li>
<li>If the IM server is not a multicast-capable service, send a disco#items request to the IM server; the IM server will then return a list of associated services.</li>
<li>Send a disco#info request to each of the services associated with the IM server; if one of the replies includes the 'http://jabber.org/protocol/address' feature, then that service is a multicast-capable service.</li>
</ol>
<p>The multicast service MAY choose to limit which local users can use the service. The server MAY choose to limit whether non-local servers can send address headers that require the local server to send to third parties (relaying). In either case, if the server chooses to disallow the request, the server MUST return a Forbidden error (see the <linkurl='#errors'>Error Conditions</link> section below). In the relaying case, the server SHOULD NOT deliver to <em>any</em> of the addresses (even the local ones) if the sender is disallowed.</p>
</section2>
<section2topic='Caching'anchor='disco-caching'>
<p>Implementations MAY choose to cache the disco response.
Positive responses MAY be cached differently than negative
responses. The result SHOULD NOT be cached for more than 24
hours, unless some sort of time-to-live information is
added to the Service Discovery protocol in the future.</p>
</section2>
</section1>
<section1topic='Outer Stanza'anchor='outer'>
<p>For multicast processing, the stanza containing an address header
(the 'outer stanza') MUST be addressed to the multicast service,
with no username or resource in the 'to' attribute.</p>
<p>When used for additional information in a one-to-one stanza
(e.g. using the 'node' attribute), the outer stanza SHOULD be
addressed directly to the recipient, not to the multicast
service.</p>
<p>A multicast service MUST NOT change the 'from' address on
the outer stanza. Note that this will limit third-party
relaying across server-to-server connections as a side-effect.</p>
<p>Address headers MAY be included in message or presence
stanzas. They MUST NOT be included as the direct child of an
IQ stanza.</p>
</section1>
<section1topic='Addresses'anchor='addresses'>
<p>Address values are packaged together into an
<addresses/> element.</p>
<examplecaption='Message with an extended address'><