Mention where to get textual names of hash functions.
Per a vote of the XMPP Council, advanced status to Draft; concurrently, the XMPP Registrar issued the urn:xmpp:bob namespace.
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.
Added section on determining support.
Simplified the protocol; removed fetch element because the cid: URI uniquely identifies the data; changed the name of the protocol to something more catchy.
More clearly described recommended protocol and usage; added fetch element to diambiguate data from reference; cleaned up text throughout.
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.
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.
Allowed inclusion of codecs parameter in type attribute per RFC 4281.
Added service discovery feature for in-band message images use case.
Initial published version.
Separately described service discovery feature for inclusion of the data element in file previews.
Described use cases for previewing data to be exchanged in file transfers and for inclusion of media information in data forms.
Changed syntax to not use data: URL scheme; added cid and type attributes; described use cases for messaging and data retrieval.
First draft.
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., In-Band Bytestreams (XEP-0047)
This document specifies just such a lightweight method. The key building blocks are:
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.
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., SOCKS5 Bytestreams (XEP-0065)
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:
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 XHTML-IM (XEP-0071)
Yet here's a spot.
]]>The recipient can then retrieve the data from the sender as described in the next section.
Data is requested and transferred using the XMPP <iq/> stanza type by making reference to the cid. In particular, the recipient requests the binary data by sending an IQ-get containing an empty <data/> element with a 'cid' attribute that matches the cid URI previously communicated.
The recipient then would either return an error (e.g., <item-not-found/> if it does not have data matching the Content-ID) or return the data.
It is RECOMMENDED for the recipient to cache data; however, the recipient MAY opt not to cache data, for example because it runs on a device that does not have sufficient space for data storage.
The default behavior is for the recipient to cache the data only for the life of the entity's application session (not a client'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 recipient would clear the cache when the application is terminated or restarted.
As a hint regarding the suggested period for caching the data, the sender MAY include a 'max-age' attribute whenever it sends a <data/> element. The meaning of the 'max-age' attribute exactly matches that of the Max-Age attribute from RFC 2965.
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).
A recipient SHOULD cache data based on the hash of the data as encapsulated in the cid. However, if a hash cannot be extracted from the cid, if the recipient does not support the hashing algorithm used, or the recipient does not support hashes, then the recipient SHOULD cache based on the JID of the sender.
To exchange binary data, the data is encapsulated as the XML character data of a <data/> element qualified by the 'urn:xmpp:bob' namespace, where the data MUST be encoded as Base64 in accordance with Section 4 of RFC 4648
The following attributes are defined for the <data/> element.
Attribute | Description | Inclusion |
---|---|---|
cid | A Content-ID that can be mapped to a cid: URL as specified in RFC 2111 |
REQUIRED |
max-age | A suggestion regarding how long (in seconds) to cache the data; the meaning matches the Max-Age attribute from RFC 2965 |
RECOMMENDED |
type | The value of the 'type' attribute MUST match the syntax specified in RFC 2045 |
REQUIRED if the <data/> element is non-empty |
The following example illustrates the format (line endings are provided for readability only).
The value of the 'algo' parameter MUST be one of the values from the
IANA Hash Function Textual Names Registry
If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:bob" in response to Service Discovery (XEP-0030)
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 Entity Capabilities (XEP-0115)
The ability to include arbitrary binary data implies that it is possible to send scripts, applets, images, and executable code, which may be potentially harmful. To reduce the risk of such exposure, an implementation MAY choose to not display or process such data but instead either completely ignore the data, show only the value of the 'alt' attribute, or prompt a human user for approval (either explicitly via user action or implicitly via a list of approved entities from whom the user will accept binary data without per-event approval).
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
The XMPP Registrar
The protocol documented by this schema is defined in
XEP-0231: http://www.xmpp.org/extensions/xep-0231.html
]]>
Thanks to Rachel Blackman, Dave Cridland, Zenon Kuder, and Tomasz Sterna for their feedback.