<remark><p>Modified cid generation rules to use a hash of the data instead of a UUID (of the form algo+hash@bob.xmpp.org); modified caching rules to typically base checking on the hash, not the sender JID.</p></remark>
<remark><p>Simplified the protocol; removed fetch element because the cid: URI uniquely identifies the data; changed the name of the protocol to something more catchy.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2008-08-06</date>
<initials>psa/ps</initials>
<remark><p>More clearly described recommended protocol and usage; added fetch element to diambiguate data from reference; cleaned up text throughout.</p></remark>
<remark><p>Removed alt attribute; more clearly specified where to include the data element in message, presence, and IQ stanzas; moved use cases to other specifications; removed service discovery features; modified examples.</p></remark>
<remark><p>Generalized text regarding inclusion of parameters in type attribute per RFC 2045; added max-age attribute, matching semantics from RFC 2965; added section on caching of data; more clearly specified generation of Content-ID.</p></remark>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2008-01-29</date>
<initials>psa</initials>
<remark><p>Separately described service discovery feature for inclusion of the data element in file previews.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2007-12-27</date>
<initials>psa</initials>
<remark><p>Described use cases for previewing data to be exchanged in file transfers and for inclusion of media information in data forms.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2007-12-18</date>
<initials>psa</initials>
<remark><p>Changed syntax to not use data: URL scheme; added cid and type attributes; described use cases for messaging and data retrieval.</p></remark>
<p>Sometimes it is desirable to include a small bit of binary data in an XMPP stanza. Typical use cases might be to include icon or emoticon in a message, a thumbnail in a file transfer request, a rasterized image in a whiteboarding session, or a small bit of media in a data form. Currently, there is no lightweight method for including such data in an XMPP stanza, since existing methods (e.g., &xep0047;) are designed for larger blobs of data and therefore require some form of negotiation (e.g., via &xep0096; or &xep0234;).</p>
<p>This document specifies just such a lightweight method. The key building blocks are:</p>
<ol>
<li>A Content-ID ("cid") that uniquely identifies the data.</li>
<li>A <data/> element (similar to the data: URL scheme defined in &rfc2397;) that enables the sender and recipient to exchange the data identified by the cid.</li>
<p>The RECOMMENDED approach is for the sender to include the cid when communicating with the recipient. The recipient SHOULD then check its cache of data to determine if the data identified by that cid is cached. If the data is cached, the recipient would then load its cached data. If the data is not cached, the recipient would then retrieve the data by sending an IQ-get to the sender (or potentially some other entity) containing an empty <data/> element whose 'cid' attribute specifies the data to be retrieved, to which the sender would reply with an IQ-result containing a <data/> element whose XML character data provides the binary data.</p>
<p>The <data/> element MUST be used only to encapsulate small bits of binary data and MUST NOT be used for large data transfers. Naturally the definitions of "small" and "large" are rather loose. In general, the data SHOULD NOT be more than 8 kilobytes, and dedicated file transfer methods (e.g., &xep0065; or &xep0047;) SHOULD be used for exchanging blobs of data larger than 8 kilobytes. However, implementations or deployments MAY impose their own limits.</p>
<p>If the data to be shared is particularly small (e.g., less than 1k), then the sender MAY send it directly by including a <data/> element directly in a &MESSAGE;, &PRESENCE;, or &IQ; stanza. The following rules apply:</p>
<ol>
<li>When the <data/> element is directly included in an XMPP &MESSAGE; or &PRESENCE; stanza, it SHOULD be a first-level child of the stanza.</li>
<li>When the <data/> element is directly included in an XMPP &IQ; stanza, it MUST be a child of the appropriate first-level child (since the IQ stanza must not include more than one first-level child).</li>
<li>When the <data/> element is used to retrieve the data from the sender as described under <linkurl='#retrieving'>Retrieving Uncached Data</link>, it MUST be a first-level child of the stanza.</li>
<p>The sender can refer to data that it hosts by including a cid in the data it sends. The following example shows how to include the cid in &xep0071; but any appropriate format can be used, such as &xep0221;.</p>
<examplecaption='An XHTML-IM message with a cid'><