<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 inclusion of an 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. At present, 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;). Therefore, this document specifies just such a lightweight method, using a <data/> element that provides semantics similar to the data: URL scheme defined in &rfc2397;.</p>
<p>The format for including binary data is straightforward: the data is encapsulated as the XML character data of a <data/> element qualified by the 'urn:xmpp:tmp:data-element' namespace &NSNOTE;, where the data MUST be encoded as Base64 in accordance with Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set the number of pad bits to zero).</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. Naturally, implementations or deployments may impose their own limits.</p>
<td>A Content-ID that can be mapped to a cid: URL as specified in &rfc2111;. The 'cid' value MUST be generated so that the local-part is a UUID as specified in &rfc4122; and the domain is the XMPP domain identifier portion of the sending entity's JabberID.</td>
<td>The value of the 'type' attribute MUST match the syntax specified in &rfc2045;. That is, the value MUST include a top-level media type, the "/" character, and a subtype; in addition, it MAY include one or more optional parameters (e.g., the "audio/ogg" MIME type in the example shown below includes a "codecs" parameter as specified in &rfc4281;). The "type/subtype" string SHOULD be registered in the &ianamedia;, but MAY be an unregistered or yet-to-be-registered value.</td>
<p>When the <data/> element is included in an XMPP &MESSAGE; or &PRESENCE; stanza, it SHOULD be included as a first-level child of the stanza.</p>
<p>When the <data/> element is included in an XMPP &IQ; stanza for data retrieval, it MUST be included as a first-level child of the stanza.</p>
<p>When the <data/> element is included in an XMPP &IQ; stanza to refer to the data, it MUST be included as a second-level child of the stanza.</p>
<p>When one party sends a data element to another party, it SHOULD NOT include the data itself unless the data is particularly small (e.g., less than 1k) or is ephemeral and therefore will never be used again. Instead, it SHOULD send an empty <data/> element with a 'cid' attribute, then depend on the receiving party to retrieve the data if not cached.</p>
<p>As a hint regarding the suggested period for caching the data, the sending party SHOULD include a 'max-age' attribute whenever it sends a non-empty <data/> element. The semantics of the 'max-age' attribute exactly matches that of the Max-Age attribute from <cite>RFC 2965</cite>.</p>
<p>It is RECOMMENDED for the receiving entity to cache data; however, the receiving entity MAY opt not to cache data, for example because it runs on an a device that does not have sufficient space for data storage.</p>
<p>The default behavior is for the receiving entity to cache the data only for the life of the entity's application session (not a controlling user's presence session with the server or the controlling user's communication session with the contact from whom the user received the data); that is, the receiving entity would clear the cache when the application is terminated or restarted.</p>
<p>If it is not suggested to cache the data (e.g., because it is ephemeral), the value of the 'max-age' attribute MUST be "0" (the number zero).</p>
<p>A receiving entity MUST cache based on the JID of the sending entity; this helps to prevent certain data poisoning attacks.</p>
<p>Data can be requested and transferred using the XMPP &IQ; stanza type by making reference to the 'cid' of the data to be retrieved. In particular, the requesting entity can request data by sending an IQ-get containing an empty <data/> element with a 'cid' attribute.</p>
<p>This specification does not place limits on the entities from which data can be requested. In particular, such an entity need not be the "owner" of the data (e.g., it could be a peer in a chatroom or whiteboarding session, or the chatroom or whiteboarding service itself).</p>
<p>In addition, bits of data could be hosted by XMPP servers, distributed via &xep0060; nodes, or included in data collections that are available via HTTP (e.g., emoticon sets). Such data could be identified by the value of the 'cid' attribute, but methods for specifying those values are out of scope for this specification.</p>
</section1>
<section1topic='Examples'anchor='examples'>
<p>As an example, consider the use of the <data/> element in conjunction with &xep0071;. Here the cid: URL scheme points to a data element within a &MESSAGE; stanza.</p>
<examplecaption='A message with included data'><