Difference between revisions of "XMPP IM Client Design Guidelines"

Jump to navigation Jump to search
→‎Description: Don't invent new <show> values
 
(→‎Description: Don't invent new <show> values)
(One intermediate revision by the same user not shown)
Line 62: Line 62:


Encoding semantics in the value of the resource is not recommend (see previous item).
Encoding semantics in the value of the resource is not recommend (see previous item).
== When making a custom extension, add new elements to <message>, <iq> or <presence> stanzas ==
=== Description ===
Do '''not''':
* Add new attributes on the <code><message></code>, <code><iq></code> or <code><presence></code> elements.
* Create new <code>type</code> values for stanzas.
* Create new top-level elements.
* Put your custom data in the <code><body></code> of a <code><message></code>.
* Invent new values for the <code><show></code> element in <code><presence></code> stanzas (allowed values are listed in [https://xmpp.org/rfcs/rfc6121.html#presence-syntax-children-show RFC 6121 section 4.7.2.1])
Do:
Add a new XML element in your own namespace:
<pre>
<message
    from='romeo@montague.net/orchard'
    to='juliet@capulet.com/balcony'
    type='chat'>
    <data xmlns='https://example.im/my-awesome-new-xmpp-app'></data>
</message>
</pre>
=== Rationale ===
XMPP is very extensible, but some rules need to be followed if you want (standard) XMPP servers to be able to handle your message. The attributes of <code><message></code>, <code><iq></code> or <code><presence></code> elements may be stripped by servers if they do not understand it, or the server may completely refuse to handle the packet. Anything inside the stanza will be passed along to the recipient unchanged. This will also make it easier for other XMPP libraries to work with your data.

Navigation menu