%ents; ]>
Content Types in Messages This specification describes a generic method whereby content in messages can be tagged as having a specific Internet Content Type. It also provides a method for sending the same content using different content types, as a fall-back mechanism when communicating between clients having different content type support. &LEGALNOTICE; 0481 Experimental Standards Track Standards Council XMPP Core XEP-0030 content &peterwaher; 0.1.0 2023-05-04 XEP Editor: ks

Promoting to Experimental.

 0.0.1 2016-01-15 pw

First draft.

Sometimes it is desirable for clients to communicate, or to send messages between each other, using a well defined Internet Content Type. Reasons can vary between the purely esthetic to funcional data-exchange. While there are XEPs, such as &xep0071; that provides means for sending richer content using a specific type, this extensions provides a similar mechanism, but for the general case of any content having a defined Internet Content Type.

Note: While the examples in this extensions uses Markdown as an example, any other text-based content type can be used.

The simplest use case is hinting at the content type of the textual content presented in the message body. This is done by aggregating a content element of namespace urn:xmpp:content to the message, with the attribute type specifying the content type. If the element does not provide a value, it is understood that the body contains the textual body of the content. This method should only be used if there's no risk of misunderstanding the message if the content type is not understood by the receiver, and the textual representation is readable. Example:

**Note:** This message is very important. ]]>

If there is a risk of misunderstanding the message if it's content type is not recognized, or the presentation of the message is done in an undesireable fashion, you can provide an alternate encoding of the message in the content element itself. If the content element contains a message, and the content type is recognized, the message should be taken from the content element instead of the body element. The body element in turn, should contain the plain text version of the same message. Example:

Note: Go to Google and search for it. **Note:** Go to [Google](http://www.google.com/) and search for it. ]]>

By providing multiple content elements in the same message, you can allow the receiver to choose the encoding best suited for its purpose. It also makes it possible to interchange messages that are understood by both humans and machines in the same message. If an empty content element is found, it is interpreted as above, i.e. providing a hint as to the content type of the message in the body element. Example:

Your energy consumption this month is 5000 kWh. That is very much. It will cost you 200 USD. You can find current tariffs at our web page. Your energy consumption this month is **5000 kWh**. That is *very much*. It will cost you **200 USD**. You can find current tariffs at our [web page](http://www.example.com/Energy). <Quote xmlns='somenamespace'> <Consumption unit='kWh'>5000</Consumption> <Cost unit='USD'>200</Cost> </Quote> ]]>

If an entity supports content types as specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:content" in response to &xep0030; information requests.

]]> ... ... ]]>

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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

This document does not specify how content types are to be interpreted, or if content types are valid or well defined. It does not specify which content types are to be understood, or when. It only provides a means to hint or include different encodings in the same message.

It is possible to use custom or vendor-specific content types. These types are marked by prefixing the subtype with x. for custom unregistered types, and with vnd. for registered vendor specific types.

Care has to be taken when sending multiple encodings of the same message, as to not reach the smallest allowed maximum stanza size used by client and server software.

This document requires no interaction with &IANA;.

The protocol schema needs to be added to the list of XMPP protocol schemas.

]]>