165
edits
Difference between revisions of "XMPP IM Client Design Guidelines"
Jump to navigation
Jump to search
XMPP IM Client Design Guidelines (view source)
Revision as of 14:12, 27 May 2015
, 14:12, 27 May 2015→Show the type of a remote resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource
| (3 intermediate revisions by the same user not shown) | |||
| Line 31: | Line 31: | ||
=== Description === | === Description === | ||
Instead of letting the user specify a resource or providing a pre-configured list of possible resource names (e.g. '/home', '/work', '/notebook') [http://xmpp.org/rfcs/rfc6120.html#bind-servergen-success let the server generate a resource for your client (RFC 6120 7.6)]. You may optionally provide a possibility to configure the resource to the user under a "advanced settings" menu (or similar). But a XMPP user should not need to configure or specify a resource. | Instead of letting the user specify a resource or providing a pre-configured list of possible resource names (e.g. '/home', '/work', '/notebook') [http://xmpp.org/rfcs/rfc6120.html#bind-servergen-success let the server generate a resource for your client (RFC 6120 7.6)]. Servers are required to support this. You may optionally provide a possibility to configure the resource to the user under a "advanced settings" menu (or similar). But a XMPP user should not need to configure or specify a resource. | ||
Store the resource you obtained from the server on the first connection, and re-use that on later connections. That way, a properly-configured server will close your old session if it still was deemed active by it. | |||
=== Rationale === | === Rationale === | ||
| Line 37: | Line 39: | ||
Resource names should not be guessable to prevent [http://xmpp.org/rfcs/rfc6120.html#security-leaks-presence presence leaks (RFC 6120 13.10.2)]. | Resource names should not be guessable to prevent [http://xmpp.org/rfcs/rfc6120.html#security-leaks-presence presence leaks (RFC 6120 13.10.2)]. | ||
== Show the type of a | == Show the type and name of a resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource string itself == | ||
=== Description === | === Description === | ||
| Line 64: | Line 66: | ||
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 == | == When making a custom extension, add new elements to <message>, <iq> or <presence> stanzas == | ||
| Line 92: | Line 93: | ||
=== Rationale === | === 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. | 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. Any XML element 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. | ||