diff --git a/inbox/content-types.xml b/inbox/content-types.xml new file mode 100644 index 00000000..4c1aa65d --- /dev/null +++ b/inbox/content-types.xml @@ -0,0 +1,209 @@ + + + %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; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0030 + + + + content + &peterwaher; + + 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. +

+ + + + + + + + + + + + + + +]]> + + +