<remark><p>Initial version; changed title to Pubsub Subscription Storage; changed namespace to storage:pubsubs for consistency with other storage XEPs.</p></remark>
<p>&xep0060; allows Jabber entities to subscribe to various kinds of information, but provides no way of remembering which nodes a user has subscribed to. Other protocols (e.g. &xep0080;, &xep0084;) allow information about a certain entity to be published to a Pubsub node. These protocols use &xep0030; to allow other entities to find the pubsub node used by a certain entity, but provide no way of performing the opposite mapping, from pubsub node to information source. This document attempts to fill that void, using &xep0049; for storing information about subscriptions.</p>
<p>This protocol enables Jabber clients to do the following:</p>
<ul>
<li>Remember which pubsub nodes the entity has subscribed to, and what kind of information is available at each node</li>
<li>Update the mappings when subscriptions are added or removed</li>
<li>Correlate incoming pubsub events to subscriptions</li>
</ul>
</section1>
<section1topic='Protocol'anchor='proto'>
<p>The <subscriptions/> element qualified by the 'storage:pubsubs' namespace is the root element used in the jabber:iq:private transactions. It has zero or more <subscription/> child elements, each of which MUST possess the following attributes:</p>
<ul>
<li><em>jid</em> -- The JID of the pubsub service used</li>
<li><em>node</em> -- The pubsub node at which the data is available</li>
<li><em>subscription</em> -- The current subscription state, one of "none", "pending", "unconfigured" and "subscribed"</li>
</ul>
<p>Additionally, the <subscription/> element MAY possess these attributes:</p>
<ul>
<li><em>resource</em> -- The resource that is subscribed to this pubsub node. If the 'resource' attribute is absent, the bare JID is subscribed.</li>
<li><em>user</em> -- The JID of the owner of this particular piece of data</li>
<li><em>targetns</em> -- The namespace of the data in question</li>
<p>Due to the nature of XEP-0049, incremental updates are not possible; a client MUST send the entire <subscriptions/> node for each update. Before performing the update, the client SHOULD retrieve the stored subscriptions, and incorporate any changes.</p>
<p>In this example, the user has just subscribed to Romeo's tune (see &xep0118;). Assuming that retrieving happened as in the previous use case, updating the subscriptions proceeds as follows:</p>
<p>Pubsub events offer an opportunity to spoof sender addresses e.g. through 'replyto' data (as specified by the &xep0033; protocol). This protocol attempts to close that hole. It does so by the following rules and assumptions:</p>
<li>A client MUST add mappings (i.e. associations between a publisher's JID and a pubsub node) only from trustworthy sources, i.e. published disco items (see &xep0030;). This relies on disco information not being cracked or falsified.</li>
<li>A client MUST retrieve mappings only from trustworthy sources, i.e. private XML storage. This assumes that no-one but the user is able to change such information.</li>