Difference between revisions of "XMPP IM Client Design Guidelines"

From XMPP WIKI
Jump to navigation Jump to search
(→‎Description: Don't invent new <show> values)
 
Line 1: Line 1:
= Introduction =
= Introduction =
These Guidelines provide some advices and recommendations to XMPP IM Client developers about how to use XMPP for Instant Messaging purposes. This document was created collaboratively by the XMPP community, it is not a official publication of the XMPP Standards Foundation (XSF), nor are developers required to follow the recommendations.


= Advices And Recommendations =  
= Advices And Recommendations =  

Revision as of 11:07, 13 May 2015

Introduction

These Guidelines provide some advices and recommendations to XMPP IM Client developers about how to use XMPP for Instant Messaging purposes. This document was created collaboratively by the XMPP community, it is not a official publication of the XMPP Standards Foundation (XSF), nor are developers required to follow the recommendations.

Advices And Recommendations

Do not to split up JIDs into multiple input fields, require only the user's JID and password

Description

XMPP Clients should only ask the user for his JID and password. A proper XMPP setup does not require more information in order for the client to establish a successful connection to the server. There should be a single JID text field in which the user is expected to enter his bare JID. Visual feedback once it was detected that a valid bare JID was entered, e.g. a green check mark or changing the field's background color (from red) to green, is also a good idea.

Rationale

Splitting the JID into multiple input fields makes it impossible for the user to simply copy&paste his JID into the field. Asking the user for more then his bare JID and password increases the UI elements and reduces the usability.

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, let the server generate a resource for you

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

<iq type='result'
    from='romeo@montague.net/orchard'
    to='juliet@capulet.com/balcony'
    id='info4'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='client'
        type='pc'
        name='Work PC'/>
    <feature var='jabber:iq:time'/>
    <feature var='jabber:iq:version'/>
  </query>
</iq>

within the 'disco#info' results.

Rationale

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 <message>, <iq> or <presence> elements.
  • Create new type values for stanzas.
  • Create new top-level elements.
  • Put your custom data in the <body> of a <message>.
  • Invent new values for the <show> element in <presence> stanzas (allowed values are listed in RFC 6121 section 4.7.2.1)

Do:

Add a new XML element in your own namespace:

<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>

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 <message>, <iq> or <presence> 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.