Difference between revisions of "XMPP IM Client Design Guidelines"
| (One intermediate revision by the same user not shown) | |||
| Line 21: | Line 21: | ||
=== Rationale === | === Rationale === | ||
== Do not to encode any | == Do not to encode any semantics into the resource and don't specify a resource == | ||
=== Description === | === Description === | ||
| Line 31: | Line 31: | ||
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 remote | == Show the type of a remote resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource == | ||
=== Description === | === Description === | ||
Users want to know the type of a remote resource, e.g. "Is this the resource of my friends mobile device or of his desktop?". Clients should display the type using the 'identity' information provided by [http://xmpp.org/extensions/xep-0030.html#info-basic XEP-30 disco#info] query results. So instead of having a resource like '/work-pc', the client should return | |||
<pre name='xml'> | |||
<identity | |||
category='client' | |||
type='pc' | |||
name='Work PC'/> | |||
</pre> | |||
within the 'disco#info' results. | |||
=== Rationale === | === Rationale === | ||
Encoding semantic in the value of the resource is not recommend (see previous item). | |||
Revision as of 09:34, 13 May 2015
Introduction
Advices
Do not to split up JIDs into multiple input fields
Description
Rationale
Show user's room nickname and allow to change it
Description
Rationale
Use only TLS secured XMPP c2s connections
Description
Rationale
Do not to encode any semantics into the resource and don't specify a resource
Description
Instead of letting the user specify a resource or providing a pre-configured list of possible resource names (e.g. '/home', '/work', '/notebook') 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.
Rationale
Resource names should not be guessable to prevent presence leaks (RFC 6120 13.10.2).
Show the type of a remote resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource
Description
Users want to know the type of a remote resource, e.g. "Is this the resource of my friends mobile device or of his desktop?". Clients should display the type using the 'identity' information provided by XEP-30 disco#info query results. So instead of having a resource like '/work-pc', the client should return
<identity category='client' type='pc' name='Work PC'/>
within the 'disco#info' results.
Rationale
Encoding semantic in the value of the resource is not recommend (see previous item).