This specification is a work in progress and is subject to change without notice.

What is it?

LIME Protocol (an acronym for Lightweight Messaging Protocol) is a JSON-based protocol for messaging, inspired by the XMPP protocol. It aims to be simple but extensible, with little verbosity yet providing good readability.

And why not just use XMPP?

XMPP is a protocol widely used for real-time communication but is complex due to the number of features and extensions that it implements. Just take a look at its specification to understand that XMPP goes far beyond what LIME proposes.

This protocol defines only a basic message structure and makes use of the MIME content-type declarations to remain extensible but is not meant to cover all the scenarios that XMPP supports.

Definitions

Concepts

The basic idea of the protocol is the exchange of JSON documents between elements in a network. These documents are called envelopes and these elements are called nodes.

The protocol defines four types of envelopes:

Message - Provides the transport of content between nodes in a network.
Notification - Notify events related to a message.
Command - Allows the manipulation of node resources, like server session parameters or information related to network nodes.
Session - Allows the configuration and establishment of the communication channel between nodes.

The nodes communicate with each other over persistent connections, like TCP or Websockets. The protocol is asynchronous, so there's no guarantee of delivery order of the envelopes, except during the session negotiation, where only session envelopes are allowed.

Every connected node must have an identity, presented in the name@domain format, as defined by the RFC 2822, section 3.4.1. The domain name should be a valid domain (i.e. can be resolved by a DNS server) and the name a valid user account identifier in the domain. The identity is authenticated by the server during the establishment of the session.

In addition to the identity, the connected node can suggest a name to the particular connection using an identifier called instance. This identifier should appear after the identity, separated by a slash (/) symbol, during the session authentication process. One identity can have more than one active connection in a domain so the instance should be used to differentiate these connections. Usually is used the name of the device (John-Cellphone, John-PC), but can be any valid string. If not provided, the server will set a default value.

Therewith, the complete format of a node identifier is name@domain/instance, similar to the XMPP's Jabber ID (the difference is that the identifier located after the slash is called instance instead of resource).

During a connection, there's a server which is the node that received the connection, and the client, the node which started it. The only difference between these roles is related to the session state management, where the server has full control of it. Besides that, they share the same set of functionality. During the session establishment, the server provides a session id, its own node identifier, and the client node identifier. It can optionally authenticate the client using an authentication scheme or provide an arbitrary node identifier without asking for any information about the client.

Although both parties of a session know each other's node identifier, they can receive and send envelopes with distinct node information of the remote party. This means that a node can act as an intermediate to be an envelopes switcher for nodes that are not directly connected. But it must be trusted by both sender and destination nodes for that.

For instance, in a session between client@domain/instance and server@domain/instance the first one can receive an envelope that the sender is someone@domain/instance in that session. In this case, the client must decide if it trusts the remote party to send envelopes with that node identifier. Specifically, it should look if the remote party is trusted to originate envelopes on behalf of the specified node domain. This trust should be built outside the protocol, using techniques like a DNS query to look for an SRV entry to connect to a specified domain and transport TLS authentication. You can trust a remote party if the remote certificate is a valid domain certificate, emitted by a trusted issuer. In the case of receiving an envelope addressed to a different node, the party that received it can forward it to the destination, but only if it can directly reach it. This means that the node must have a direct connection with that node or with a node that is trusted to receive this envelope, in the same conditions that are illustrated above. And after the envelope has been forwarded, the actual envelope destination should decide if it trusts the remote party in the same way.

Envelope

The JSON documents exchanged in a LIME conversation are called envelopes. The JSON data must be compliant with the RFC 4627 specification, using the UTF-8 encoding.

Every envelope may contains the following properties:

from - Identifier of the sender node of the envelope, in the name@domain/instance format. If a node receives an envelope without this value, it means that the envelope was originated by the remote party.
to - Identifier of the destination node of the envelope, in the same format of the sender. If a node receives an envelope without this value, it means that the envelope is addressed to itself.
pp - Acronym for per procurationem. Identifier of a delegate node (a node that received a permission to send on behalf of another), in the name@domain/instance format. Allows a node to send an envelope on behalf of another identity.
id - Identifier of the envelope, which can be any relevant value for the caller.
metadata - Allows the transport of generic information, in the "name": "value" format. This property is optional for all envelopes. Any value set in this property should not change the behavior of the server.

Message

A message provides the transport of a content between nodes in a network.

JSON Schema:


{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "message",
    "type": "object",
    "properties": {
        "from": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "to": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "pp": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "id" : {
            "type": "string"
        },
        "metadata": {
            "type": "object"
        },
        "type" : {
            "type": "string",
            "pattern": "^[-\w]+/[-\w.]+(\+\w+)?$"
        },
        "content" : {
            "type": "object"
        },
    },
    "required": [ "type", "content" ],
    "additionalProperties": false
}

In a message, the following constraints should apply to the envelope properties:

id - Optional. The sender just need provide this information in order to receive notifications related to the message. If not provided, the message is processed in the fire-and-forget mode.
from - Optional for the sender, since the value can be determined by the server in the session. mandatory in the destination.
to - Mandatory for the sender, but is allowed to ommit the value of the instance (the server will route the envelope according to the routing rule chosen by the destination) and/or domain (the server will assume that the destination is in the same domain of the sender) properties. optional in the destination.
pp - Optional for the sender, when is considered the identity of the session. Is mandatory in the destination if the identity of the originator is different of the identity of the from property.
metadata - Optional. The sender should avoid to use this property to transport any kind of content-related information, but merely data relevant to the context of the communication. Consider to define a new content type if there's a need to include more content information into the message.

Besides the properties defined in the envelope, a message should contains:

type - MIME declaration of the content type of the message. This property is used by the destination to handle the content in the appropriate way. The MIME can be any discrete type (text, application, image, video or audio; composite types, like message or multipart, are not supported). For structured data, is recommended to use JSON subtypes (like application/json or application/vnd.specific+json), althought is possible to send other types, like XML, provided that the unsupported characters in content are escaped, accordinally to the JSON specification. The protocol defines some common types that should be reused. If you are using a custom content type, consider registering it with IANA in order to provide interoperability.
content - The representation of the content. JSON content data are represented unescaped. Binary data (images, video and audio) should be represented with the Base64 encoding. The remaining data types should be represented as an escaped value.

Examples

Fire-and-forget (no id) text message:


{
    "from": "skyler@breakingbad.com/bedroom",
    "to": "ww@breakingbad.com",
    "type": "text/plain",
    "content": "Walter, are you in danger?"    
}

JSON text message with metadata and notification support, omitting the destination domain:


{
    "id": "my-id",
    "from": "heisenberg@breakingbad.com/bedroom",
    "to": "skyler/bedroom",
    "type": "application/vnd.lime.threadedtext+json",
    "content": {
        "text": "I am the one who knocks!",
        "thread": 2
    },
    "metadata": {
        "senderIp": "192.168.0.1"
    }
}

Binary text message with notification support:


{
    "id": "65603604-fe19-479c-c885-3195b196fe8e",   
    "to": "heisenberg@breakingbad.com/bedroom",
    "type": "image/png",
    "content": "iVBORw0KGgoAAAANSUhEUgAAACsAAAAqCAMAAAAd31JXAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6MEYyQzgwNTUxQkY2MTFFMkE2NzBBRjFERkI1MEFCQjUiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6MEYyQzgwNTYxQkY2MTFFMkE2NzBBRjFERkI1MEFCQjUiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDowRjJDODA1MzFCRjYxMUUyQTY3MEFGMURGQjUwQUJCNSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDowRjJDODA1NDFCRjYxMUUyQTY3MEFGMURGQjUwQUJCNSIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/PnkDBYEAAADAUExURcbhnr/flKbTaZPJSrPZfprMVKzWdMzlqcXinpTKS9jsvt7vyKDPX7ncieLxz9Los5vMVtTqt/j788bin6/Wec/lruby1dvswtXouJDIRfH459Lns+v13eDvy+r02+7246zUc6LRY6nTbev13t3txuXy05TJS73cj5vNV7HYe6LPYrjbh7bZhJ7OXL/fk7naiZfLUKrUb6XRZ9vtw+nz2uPw0LPXfsnipM3mq9jqvcDdk8zkqbzcjvH46P///43GP1/s3CQAAALWSURBVHjajJXpmqowDIYtlB1kVQE3wH0ddfalJ/d/V6fQAtUZz5n8kMfyJv2aJqHz5/fW+b4UdKkF/2UDf7cGOHmeB/nRv3UQ2XQHp2z/0RtQiz8fskOS+z+z6SbZrt6fCLOFRWbz4cth7f/A+kbRGRPiYmRBZYpFyGzw4eWTW9Y/rcbEkkpIZywgXdJH0zgzJtfsY7J6Ihpj+AM0hQbXyDiqYcamxv6JuHU8WfRRzHFmpAKbZ1QARwBL7KHW8eND3rJv3pCQ+hVIjDXr/9DtJGHNBsbD1NQaVkaVh9awznNhBJw9egMqQHKlWkR9stqZ9JYhZ2lYiSVJblgFQWvWbF8GpuzjMuYpUFjo8kdAJcsksedX7LHoN1qxzji5WVEdLIM2izYVm+/bHICtUeUyqJUaGevIrtSRjlGx8EmEHWVs06SVkm0OljLIEBjbE1mqw0KOAoqO2yWFvEOXsl3KjhAyTVNDSDN1ZNKSxKoqusOi17AES6XxF5S14NrMTqWhZB1x3RkRotHjS2KGv7jeLyKsSrriuIsyDQrGTn04sufsS8sqLq1IVZHrw9oqKtOnkmhdseuiX2+numUVUEW4rQbV1fRRv2B3sfPmrKZknR3eub5jqpbMvTdWD8lwVO3HS8cuPbAsZoHEyYTXWTSjWzp1RquQsnPFrta8Jnen2MWmDWL5gi4ENp8vR86m8DBtOhNs5qTowg33lmndb+ftgDQtg4SWZ+b2o2PTm11YzRZX3VZGq73x9PUUtD2/oY3MmTazXLFE4kMozIfAyOYL8WTVJbB+Hs0v+dWM6kI0Rs1FcBvJ9IRkfjOj6OyDbDijtSAJ1WWWg7V3uZ199PaMZTTsC+OH7j4dv0bLPP0+q4PQWGad8dRCNLSN9cV08LEFCO98L/w1bF+G8z6150G8ouR5cv871N1A4l2Kojh4CZzD9N/frMAPz7swDP3Jb75vd+2vAAMAIkNXL7uoiZEAAAAASUVORK5CYII="
}

Notification

A notification transports information about events associated to a message sent in a session. Can be originated by a server or by the message destination node.

JSON Schema:


{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "notification",
    "type": "object",
    "properties": {
        "from": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "to": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "pp": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "id" : {
            "type": "string"
        },
        "metadata": {
            "type": "object"
        },
        "event" : {
            "enum": [ 
                "accepted",
                "dispatched",
                "received",
                "consumed",
                "failed"
            ]
        },
        "reason" : {
            "type": "object",
            "properties": {
                "code" : {
                    "type": "integer"
                },
                "description": {
                    "type": "string"
                }
            },
            "required": [ "code" ]
        }
    },
    "required": [ "id", "event" ],
    "additionalProperties": false
}

In a notification, the following constraints should apply to the envelope properties:

id - Mandatory. The id references the related message.
from - Optional. If the value is not present in the destination, it means that the notification was generated by the connected node (server).
to - Mandatory for the sender and optional in the destination. The sender can ommit the value of the domain.
pp - Optional for the sender, when is considered the identity of the session. Is mandatory in the destination if the identity of the originator is different of the identity of the from property.
metadata - Optional. Avoid to use this property to transport any event-related data.

Besides the envelope properties, a notification may contains:

event - Name of the event. This property is mandatory. The possible values are:
- accepted - The message was received and accepted by the server.
- dispatched - The message was dispatched to the destination by the server.
- received - The destination has received the message. This event is generated by the destination node.
- consumed - The destination has consumed (read or processed) the message. This event is generated by the destination node.
- failed - A problem occurred during the processing of the message. In this case, the reason property of the notification should be present.
reason - In the case of a failed event, this property brings more details about the problem. It contains the following properties:
- code - Code number of the reason. There are some protocol pre-defined codes, but may exists specific codes for each implementation of the protocol.
- description - Description message of the problem. This property can be omitted.

Examples

Received notification sent by the destination node:


{
    "id": "48600604-ce09-479c-b985-1195b196fe8e",
    "from": "skyler@breakingbad.com/bedroom",
    "to": "heisenberg@breakingbad.com/bedroom",
    "event": "received"
}

Failure notification sent by the server:


{
    "id": "9d0c4fea-75c7-432a-a164-c1a219bc17a8",
    "to": "skyler@breakingbad.com/bedroom",
    "event": "failed",
    "reason": {
        "code": 42,
        "description": "The message destination was not found"
    }
}

Command

Allows the manipulation of node resources, like server session parameters or information related to the network nodes.

JSON Schema:


{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "command",
    "type": "object",
    "properties": {
        "from": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "to": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "pp": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})$"
        },
        "id" : {
            "type": "string"
        },
        "metadata": {
            "type": "object"
        },
        "method" : {
            "enum": [ 
                "get",
                "set",
                "merge",
                "delete",
                "subscribe",
                "unsubscribe",
                "observe"
            ]
        },
        "uri" : {
            "title": "limeUri",
            "type": "string",
            "pattern": "^((lime://)(\w\.?-?)+@@?(\w\.?-?@@?)+)?(/(\w\.?-?@@?)+)+(\?{1}((\w+=\w+)&?)+)?$"
        },
        "type" : {
            "type": "string",
            "pattern": "^[-\w]+/((json)|([-\w.]+(\+json)))$"
        },
        "resource" : {
            "type": "object"
        },
        "status": {
            "enum": [
                "success",
                "failure"
            ]
        },
        "reason" : {
            "type": "object",
            "properties": {
                "code" : {
                    "type": "integer"
                },
                "description": {
                    "type": "string"
                }
            },
            "required": [ "code" ]
        }
    },
    "required": [ "id", "method" ],
    "additionalProperties": false
}

In a command, the following constraints should apply to the envelope properties:

id - Mandatory, except for the observe method. Must be provided during the request and the same value should be in the related response command.
from - Optional. If the value is not present in the destination, it means that the notification was generated by the connected node (server).
to - Optional. If the value is left empty in the request, the command will be processed by the connected node (server).
pp - Optional. This property is useful to get resources in the server owned by different identities, like presence and account information. The value should be defined if the resource of an observe method command is owned by a different identity than the destination.
metadata - Optional. Avoid to use this property to transport any command-related data, like extra parameters.

Besides the envelope properties, a command may contains:

method - Method for the manipulation of the resource. This property is mandatory. The possible values are:
- get - Gets an existing value of the resource.
- set - Sets or updates a for the resource.
- merge - Merges the resource document with an existing one. If the resource doesn't exists, it is created.
- delete - Deletes a value of the resource or the resource itself.
- subscribe - Subscribes to the resource, allowing the originator to be notified when the value of the resource changes in the destination.
- unsubscribe - Unsubscribes to the resource, signaling to the destination that the originator do not want to receive further notifications about the resource.
- observe - Notify the destination about a change in the resource value of the sender. Commands with this method are one-way and the destination should not send a response for it. Because of that, these commands may not have an id.
uri - The uniform resource identifier (RFC 3986). This property is mandatory in command requests and can be ommited in responses. It must be present in observe commands. The supported scheme is lime, and the authority must be always the identity of the resource owner. In command requests, this identity is always the same of the identity of from envelope property. Since the base URI is always the same for a specific identity (lime://user@domain), the URI can be represented as a fragment, like /groups, instead of lime://user@domain/groups. The URI may also contains a query string for filtering.
type - MIME type of the resource. Like the messages, the protocol defines some common resource types, but may exists specific resources to the implementation. This property should be present always when the value of resource property is defined.
resource - JSON representation of the resource. It must be present in commands with the methods set and observe and may be present in the method delete. In a command response, must be present in successfully processed command with the method get.

In addition of the above, the command response may contains the following properties:

status - Result status of the command processing. Mandatory in response commands. The valid values are:
- success - The command was processed successfully. In cases of command of method get, the property resource of the response should have a value.
- failure - A problem occurred while processing the command. In this case, the property reason of the response should have a value.
reason - If the command was not successfully processed, this property should provide more details about the problem. It contains the following properties:
- code - Code number of the reason. There are some protocol pre-defined codes, but may exists specific codes for each implementation of the protocol.
- description - Description message of the problem. This property can be omitted.

Examples

Setting the presence:

C:

{
    "id": "9cbe5fe1-b6b2-4afe-ab12-0675aa139f36",
    "from": "jesse@breakingbad.com/home", 
    "method": "set",
    "uri": "/presence",
    "type": "application/vnd.lime.presence+json",
    "resource": {
        "status": "available",
        "message": "Yo 148, 3-to-the-3-to-the-6-to-the-9. Representin' the ABQ. What up, biatch?"
    }
}

S:

{
    "id": "9cbe5fe1-b6b2-4afe-ab12-0675aa139f36",
    "from": "server@breakingbad.com",    
    "method": "set",
    "status": "success"    
}

Getting the roster with a filter:

C:

{
    "id": "b784a7d2-59d7-45de-a1eb-8c50a0f5edb8",
    "from": "jesse@breakingbad.com/home",    
    "method": "get",
    "uri": "lime://jesse@breakingbad.com/contacts?sharePresence=true&take=3"    
}

S:

{
    "id": "b784a7d2-59d7-45de-a1eb-8c50a0f5edb8",
    "from": "server@breakingbad.com",    
    "method": "get",
    "status": "success",
    "type": "application/vnd.lime.collection+json",
    "resource": {
        "total": "4",
        "itemType": "application/vnd.lime.contact+json",
        "items": [
            { 
                "identity": "skinnypete@breakingbad.com"
            },
            { 
                "identity": "badger@breakingbad.com"
            },
            { 
                "identity": "combo@breakingbad.com"
            }
        ]
    }
}

Trying without success to get another user account information:

C:

{
    "id": "5c95e87f-7f0c-4cc3-b55b-99056d9f288d",
    "from": "gusfring@breakingbad.com",
    "pp": "saul@breakingbad.com",
    "method": "get",
    "uri": "lime://gusfring@breakingbad.com/account"
}

S:

{
    "id": "5c95e87f-7f0c-4cc3-b55b-99056d9f288d",
    "from": "server@breakingbad.com",
    "method": "get",
    "status": "failure",
    "reason": {
        "code": 56,
        "description": "The request account is not sharing information with current session identity"
    }
}

Session

Allows the configuration and establishment of the communication channel between nodes. Parameters like authentication, cryptography and compression are set through the session envelope.

JSON Schema:


{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "session",
    "type": "object",
    "properties": {
        "from": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "to": {
            "type": "string",
            "pattern": "^(?:([^\"&'/:<>@@]{1,1023})@@)?([^/@@]{1,1023})(?:/(.{1,1023}))?$"
        },
        "id" : {
            "type": "string"
        },
        "metadata": {
            "type": "object"
        },
        "state" : {
            "enum": [ 
                "new",
                "negotiating",
                "authenticating",
                "established",
                "finishing",
                "finished",
                "failed"
            ]
        },
        "encryptionOptions": {
            "type": "array",
            "minItems": 1,
            "items": { "type": "string" },
            "uniqueItems": true
        },
        "encryption": {
            "type": "string"
        },
        "compressionOptions": {
            "type": "array",
            "minItems": 1,
            "items": { "type": "string" },
            "uniqueItems": true
        },
        "compression": {
            "type": "string"
        },
        "schemeOptions": {
            "type": "array",
            "minItems": 1,
            "items": { "type": "string" },
            "uniqueItems": true
        },
        "scheme": {
            "type": "string"
        },
        "authentication": {
            "type": "object"
        },
        "reason" : {
            "type": "object",
            "properties": {
                "code" : {
                    "type": "integer"
                },
                "description": {
                    "type": "string"
                }
            },
            "required": [ "code" ]
        }
    },
    "required": [ "state" ],
    "additionalProperties": false
}

In a session, the following constraints should apply to the envelope properties:

id - Mandatory, except in the first request sent by the client (new state). This value is generated by the server in the first session envelope sent to the client.
from - Mandatory for the client during the session authentication. Otherwise, is optional. The client may ommit the instance value. In this case, the server will define a default instance value.
to - Optional.
pp - Not applicable.
metadata - The server should ignore any value set in this property by the client but it can use this property to send statistics about itself (serverVersion, lastConnectionDate, and so) to the client.

Besides envelope properties, a session may contains:

state - Informs or changes the state of a session. Only the server can change the session state, but the client can request the state transition. The valid values are:
- new - The session is new and doesn't exists an established context. It is sent by a client node to start a session with a server.
- negotiating - The server and the client are negotiating the session options, like cryptography and compression. The server sends to the client the options (if available) and the client chooses the desired options. If there's no options (for instance, if the connection is already encrypted or the transport protocol doesn't support these options), the server should skip the negotiation.
- authenticating - The session is being authenticated. The server sends to the client the available authentication schemes list and the client must choose one and send the specific authentication data. The authentication can occurs in multiple roundtrips, according to the selected schema.
- established - The session is active and is possible to send and receive messages and commands. The server sends this state after the session was authenticated.
- finishing - The client node is requesting to the server to finish the session.
- finished - The session was finished by the server.
- failed - A problem occurred while the session was established, under negotiation or authentication and it was closed by the server. In this case, the property reason must be present to provide more details about the problem.
encryptionOptions - Encryption options provided by the server during the session negotiation. Some of the valid values (not limited to) are:
- none - The session will be not encrypted.
- tls - The session will be encrypted by TLS. This options is required for transport authentication in TCP transport connections.
encryption - The encryption option selected for the session. This property is provided by the client in the negotiation and by the server in the confirmation after that.
compressionOptions - Compression options provided by the server during the session negotiation. Some of the valid values (not limited to) are:
- none - The session will not be compressed.
- gzip - The session will use the GZip algorithm for compression.
compression - The compression option selected for the session. This property is provided by the client in the negotiation and by the server in the confirmation after that.
schemeOptions - List of available authentication schemas for session authentication provided by the server. Some of the valid values (not limited to) are:
- guest - The server doesn't requires a client credential, and provides a temporary identity to the node. Some restriction may apply to guest sessions, like the inability of sending some commands or other nodes may want to block messages originated by guest identities.
- plain - User and password authentication.
- transport - The authentication is made in the transport level. For the TCP transport, this indicates a TLS/SSL client authentication, which requires a certificate from the client. This certificate should be already presented during the session negotiation state, after the confirmation of the encryption options, in the TLS handshake.
scheme - The authentication scheme option selected for the session. This property must be present if the property authentication is defined.
authentication - Authentication data, related to the selected schema. Information like password sent by the client or roundtrip data sent by the server.
reason - In cases where the client receives a session with failed state, this property should provide more details about the problem. It contains the following properties:
- code - Code number of the reason. There are some protocol pre-defined codes, but may exists specific codes for each implementation of the protocol.
- description - Description message of the problem. This property can be omitted.

Examples

Establishment and closing of a session with negotiation and authentication:

C:

{
    "state": "new"
}

S:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "from": "server@breakingbad.com/server1",    
    "state": "negotiating",
    "encryptionOptions": [ "none", "tls" ],
    "compressionOptions": [ "none", "gzip" ]
    
}

C:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "state": "negotiating",    
    "encryption": "tls",
    "compression": "none"
}

S:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "from": "server@breakingbad.com/server1",    
    "state": "negotiating",    
    "encryption": "tls",
    "compression": "none"
}

S:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "from": "server@breakingbad.com/server1",    
    "state": "authenticating",    
    "schemeOptions": [ "guest", "plain" ]
}

C:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "from": "gale@breakingbad.com/lab",
    "state": "authenticating",
    "scheme": "plain",
    "authentication": {
        "password": "aWxvdmV1d3c="
    }
}

S:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "from": "server@breakingbad.com",   
    "to": "gale@breakingbad.com/lab",             
    "state": "established"    
}

C:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "state": "finishing"
}

S:

{
    "id": "d35ad2be-9aa9-4825-9096-d6332655ed1d",
    "from": "server@breakingbad.com/server1",
    "state": "finished"
}

Introduction

What is it?

And why not just use XMPP?

Definitions

Concepts

Envelope

Message

Notification

Command

Session