In order to ensure proper processing by the recipient of an XML stanza, some Jabber protocols and other XMPP extensions may need to enable the sender to communicate non-addressing information about the stanza (this is especially true of protocols that translate from a foreign format to XMPP; a good example is A Transport for Initiating and Negotiating Sessions (XEP-0111) XEP-0111: A Transport for Initiating and Negotiating Sessions <https://xmpp.org/extensions/xep-0111.html>.). Such information was formerly included in Extended Stanza Addressing (XEP-0033) XEP-0033: Extended Stanza Addressing <https://xmpp.org/extensions/xep-0033.html>., but was removed from that specification when it was changed to focus on addressing information only. Therefore, this document defines a mechanism for encapsulating non-addressing "header" information about stanzas, including standard Internet metadata such as that defined by RFC 2045 RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://tools.ietf.org/html/rfc2045>., RFC 2616 RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://tools.ietf.org/html/rfc2616>., RFC 2617 RFC 2617: HTTP Authentication: Basic and Digest Access Authentication <http://tools.ietf.org/html/rfc2617>., RFC 2822 RFC 2822: Internet Message Format <http://tools.ietf.org/html/rfc2822>., and RFC 3261 RFC 3261: Session Initiation Protocol (SIP) <http://tools.ietf.org/html/rfc3261>.. Such information is encapsulated in a protocol extension qualified by the 'http://jabber.org/protocol/shim' namespace, where "SHIM" stands for "Stanza Headers and Internet Metadata".

This protocol addresses the following requirements:

1. Enable the inclusion of any header information
2. Encapsulate all information in XML
3. Ensure interoperability with existing non-XMPP header and metadata formats (HTTP, MIME, SIP, SMTP, etc.)

In a fashion similar to the structure of Extended Stanza Addressing, headers for <message/> and <presence/> stanzas are contained in a <headers/> wrapper element qualified by the 'http://jabber.org/protocol/shim' namespace; each header is a child of this wrapper element, and is encapsulated via a <header/> element whose 'name' attribute identifies the header and whose XML character data specifies the relevant value: Standard XML escaping rules apply to the XML character data, so that the characters < > ' " & MUST be escaped to &lt; &gt; &apos; &quot; &amp; respectively when translating from non-XML protocols (such as MIME and SIP) to SHIM, and the escaped sequences (e.g., &lt;) MUST be transformed to the equivalent non-escaped character (e.g., '<') when translating from SHIM to the non-XML protocol. Escaping and unescaping will normally be performed by a gateway that translates between XMPP and a foreign protocol such as MIME or SIP.

In accordance with XMPP Core RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>., an <iq/> stanza must not contain more than one non-error child element; this places constraints on the location of SHIM headers in the XML hierarchy. Specifically, the <headers/> wrapper element MUST NOT be a direct child of <iq/> and instead SHOULD be a grandchild of <iq/> and a direct child of the content-bearing child element of <iq/> (e.g., <query/>, not <error/>).

All public headers SHOULD be registered with the XMPP Registrar following the process specified in the XMPP Registrar Considerations section of this document. Many such headers are defined by other protocol specifications, such as RFCs 2045, 2616, 2617, 2822, and 3261; implementors MUST refer to those specifications for definition of the relevant headers.

This document defines several additional headers that may prove useful within Jabber protocols and other XMPP extensions, as specified in the following sections; further headers may be registered with the XMPP Registrar, either directly or via definition in XMPP Extension Protocol specifications.

Date formats differ widely. XMPP Date and Time Profiles (XEP-0082) XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>. defines the Date, DateTime, and Time profiles of ISO 8601 ISO 8601: Representation of Dates and Times (2000). This specification is not freely available; however, a good summary is located at <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>., which correspond to the Date, DateTime, and Time headers registered herein. The SHIM Date header also corresponds to the Date metadata element used in Dublin Core Metadata Initiative (DCMI) The Dublin Core Metadata Initiative (DCMI) is an organization dedicated to promoting the widespread adoption of interoperable metadata standards. For further information, see <http://www.dublincore.org/>. as specified in RFC 2413 RFC 2413: Dublin Core Metadata for Resource Discovery <http://tools.ietf.org/html/rfc2413>..

However, many Internet standards use a different datetime format that ultimately derives from RFC 822 RFC 822: Standard for the Format of ARPA Internet Text Messages <http://tools.ietf.org/html/rfc0822>. as updated by RFC 1123 RFC 1123: Requirements for Internet Hosts -- Application and Support <http://tools.ietf.org/html/rfc1123>.; specifically, that format is used by email (RFC 2822 RFC 2822: Internet Message Format <http://tools.ietf.org/html/rfc2822>.), the World Wide Web (RFC 2616), and the Session Initiation Protocol (RFC 3261). To map dates to and from these protocols, we define the SHIM RFC2822Date header.

In general, security considerations are the responsibility of the "using protocol".

Certain SHIM headers MAY be security-sensitive (e.g., the "Classification", "Distribute", and "Store" headers specified herein). If an entity plans to use such headers, it MUST determine whether the intended recipient supports both the SHIM protocol and the particular security-sensitive headers of interst, as described under Service Discovery; furthermore, an implementation MUST warn a human user (if any) before use if the security-sensitive headers of interest are not supported.

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>..