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 07:53, 11 August 2015
, 07:53, 11 August 2015→Show the type and name of a resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource string itself
Link Mauve (talk | contribs) (→Rationale: Addition of the multiple same-client usecase.) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 41: | Line 41: | ||
Providing a default resource also prevents the user from using the same software from two different locations at the same time. | Providing a default resource also prevents the user from using the same software from two different locations at the same time. | ||
== Show the type and name of a resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource string itself == | == Show the type and name of a resource (mobile, pc, home, work, etc.) by means of Service Discovery and not the resource string itself. Also set meaningful 'identity' information yourself == | ||
=== 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 | 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. Also they should set a meaningful XEP-30 'identity'. So instead of having a resource like '/work-pc', the client should return | ||
<pre name='xml'> | <pre name='xml'> | ||
| Line 96: | Line 96: | ||
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. | 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. | ||
== Implement SCRAM-SHA-1 == | |||
=== Description === | |||
Do '''not''': Implement DIGEST-MD5 or CRAM-MD5. These mechanisms only work if the server has access to the plain password. | |||
Do: Implement SCRAM-SHA-1 and PLAIN. | |||
=== Rationale === | |||
Hashing and salting passwords helps making it hard to retrieve the plain password from a compromised server. However, we would also like to be able to protect the password while it is in transit. These two concepts are difficult to combine: DIGEST-MD5 and CRAM-MD5 only protect the password in transit – the mechanisms can't work if the server wants to store the password hashed and salted. SCRAM-SHA-1 fixes that and supports both hashed storage and hashed transmission. | |||
While it would be nice to deprecate PLAIN, it is still needed for servers who use a different hashing mechanism than SCRAM-SHA-1 needs. | |||
See [[SASLandSCRAM-SHA-1]] for help with implementing SCRAM-SHA-1. | |||