Promoting to Experimental.
+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: +
++ 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: +
++ 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: +
++ 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. +
+
+
+
+
+
+
+
+
+
+
+
+]]>
+
+