The MITRE Corporation released an open source Instant Messaging system in March of 2000 called Simple Instant Messaging and Presence Service. This document describes a major revision to the protocol used by that system.
Copyright © 2003 The MITRE Corporation. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to The MITRE Corporation.
This document and the information contained herein is provided on an "AS IS" basis and THE MITRE CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Instant messaging is designed to support message exchange at a rate that supports chat-like conversations. An instant message is delivered quickly to a recipient if the recipient is listening for messages, otherwise the message is dropped and the sender is informed of the delivery failure.
A user of an instant messaging service can employ a presence service to keep track of the listening status of a set of users. By consulting this service, a user has a good chance of predicting if a message will get to its recipient.
The Simple Instant Messaging and Presence Protocol is designed so that instant messaging and presence services can be provided by a set of distributed servers spread across many administrative domains. The vision is a service provided by a large number of sites much in the way that electronic mail service is provided today.
The protocol is similar to email protocols. Users are identified by an Instant Message Address (IMA). Every instant message address is syntactically an Internet email address as described in RFC 2822 [Email]. A message is delivered by connecting to the user's home server. The protocol allows the use of digital signatures to authenticate the originator of a message transported by this protocol.
Unlike most email systems, a user listening for instant messages remains connected to their home server. This connection is used to deliver messages in a timely fashion. Another difference from email systems is that an instant message is never queued, rather it is dropped if there is any obstacle to immediate delivery. Fundamentally, email is built on one way message passing, while most of this protocol is built on request-reply pairs.
The protocol is built on the transfer of one simple type of object represented as an XML document [XML]. The simplicity of the wire protocol gives it its name, which is abbreviated as the SIMP Protocol.
For each domain name associated with an instant message address, one or more servers provide two types of connection points, one for routing messages to servers, and the other for notifying clients. A simple implementation of the service might use one program to implement both connection points. A domain name that maps to multiple IP addresses can be used to produce a highly available service.
An instant message address identifies the location of a user's contact place. The contact place provides presence service and, when the user is online, a relay for instant messages.
A user listens for instant messages by maintaining a notification connection to the user's contact place. In addition to receiving instant messages by this connection, the client also uses it to receive change of presence notifications, get and set an access control list, and get and set a user profile. The contact point's access control list and profile will be described later. The client can use this connection to send messages that are routed by the user's contact place to other users. The use of this connection requires user authentication.
A routing connection is used to deliver messages to a user's contact place. Both clients and other servers can make requests through this connection. The initial step in user authentication occurs on this connection.
The description of the protocol has been divided into two levels. This section describes the transfer of objects as XML documents. The remaining sections describe the interactions of clients and servers in terms of the transfer of objects described here. The paper concludes with a glossary of relevant terms.
The SIMP Protocol currently runs over TCP/IP. The routing connection is made available on port 7467 which is SIMP on a telephone touchtone keypad. The login protocol establishes the port for the notification connection.
A properties object is the one and only type of data exchanged in this protocol. A properties object is a partial map from strings to strings. An item from its domain is called a key and the item from its range associated with the key is called the key's value. A key value pair is called an entry.
Every properties object has a representation as a sequence of octets that make up a valid XML document. This representation is called the object's XML representation. The document type declaration which defines the validity follows.
<!ELEMENT properties (entry)*> <!ELEMENT entry (#PCDATA)> <!ATTLIST entry key CDATA #REQUIRED>
Since a properties object is a partial map, the order in which the entry elements appear in its XML representation is of no significance. Furthermore, a given string can be the key of at most one entry.
For example, the following properties object has five entries, and the key "action" maps to the value "send".
<properties> <entry key="action">send</entry> <entry key="to">fella@home</entry> <entry key="from">guy@work</entry> <entry key="type">text/plain</entry> <entry key="body">Please meet at 8 AM in my office.</entry> </properties>
In what follows, the phrase "the KEY attribute is VALUE" abbreviates the phrase "the key KEY maps to the value VALUE". In the previous example, the "action" attribute is "send".
A properties object with an "action" attribute is called a command. Every properties object exchanged by the protocol is a command.
Any command can be signed if it contains a "from" attribute giving the IMA of the originator of the command. The protocol uses the encapsulate command to exchange digitally signed commands. An encapsulate command contains the signed command, a signature of the signed command, and an X.509 Version 3 Certificate [X.509V3] containing the signer's public key. Every certificate used in this protocol must contain a URI [URI] that embeds the originator's IMA as one of the certificate's Subject Alternative Names. The scheme of the URI must be "simp". The certificate authority issues a certificate with a given IMA only to the user of the contact place named by the IMA. One can be sure a command is signed by the originator by comparing the embedded IMA with the one in the "from" attribute of the encapsulated command.
To prevent replay attacks, every command that can be signed must have a "date" attribute giving the time at which the command was created.
Every connection contains a pair of streams that transfer octets in opposite directions. Each command sent on a stream is preceded by a pair of 32-bit integers in network byte order. The first integer gives the number of bytes used to encode the command as XML. The second integer is called the command's tag, and its purpose is described in the next section.
A command that provokes a reply is known as a request. Requests are entirely asynchronous. Several requests can be made without waiting for a reply and replies need not arrive in the order in which the corresponding requests were issued.
Tags are used to match a request with its reply. A stream generates a positive integer as a tag for each request. A reply is tagged with a negative integer that, when negated, matches its corresponding request. A command that is neither a request or a reply is tagged with zero.
The tags must be unique long enough to correctly match a request with its reply. Tags generated from a signed 32-bit counter are more than adequate for satisfying the uniqueness constraint.
A description is a properties object that users use to describe themselves. The description is included as part of a user's presence information.
There is currently only one attribute required in all descriptions. The "message" attribute contains a string given by the user to be displayed with the user's online state.
<properties> <entry key='message'>Joe's message</entry> </properties>
A user's profile is stored at the user's contact place. The profile is given as a partial map from strings to strings. When transferred by the protocol, they are encoded as a properties object.
In this version of the protocol, the semantics of two keys is defined. The "message" attribute contains the complete description of the user as defined in the previous section. The "buddies" attribute is the XML representation of a buddy list, a properties object encoding interest in presence information.
A user can request that the presence service notify the user when the online states of another user, called a buddy, changes. A user can name sets of buddies. A named set is called a group, and a set of buddies is a white space-separated sequence of IMAs. A buddy list maps group names to sets of buddies.
What follows is a user's profile represented as an XML properties object. The user has two groups named Pals and Coworkers. Pals has one member, friend@neighbor, and Coworkers has two members, fella@home and guy@work.
<properties> <entry key='message'><?xml version="1.0"?> <properties> <entry key='message'>Joe's message</entry> </properties> </entry> <entry key='buddies'><?xml version="1.0"?> <properties> <entry key='Pals'>friend@neighbor </entry> <entry key='Coworkers'>fella@home guy@work</entry> </properties> </entry> </properties>
Access control decisions on behalf of the user are made at the user's contact place, but a client can be used to modify an access control list. This section defines the representation of an access control list as a properties object used when passing lists between a client and a server.
An access control list is used to decide if a request is permitted. Abstractly, the decision depends on three parameters, the originator of the request, the operation requested, and the validity of the signature if the request is signed. The originator of the request is an IMA. There are five operations, "send", "fetch", "subscribe", "change", and "end". The "action" attribute of a request determines the operation. In this version of the protocol, the operation is the last word of the "action" attribute of every checked request.
In representing an access control list as a properties object, each key is either an IMA or "everybody". The value associated with a key is a list of white space separated operations. An operation is preceded with a plus sign if a valid signature is required for the operation.
The access decision is made as follows. Given a request, the originator's IMA is determined by the "from" attribute. Next, the list of permitted operations is determined. If the properties object has an entry with the originator's IMA as a key, its associated value is the list of operations used to make the decision. Otherwise, if the domain name of the IMA is HOST, and the properties object has an entry with "@HOST" as a key, the value is the list of operations used to make the decision. Otherwise, if there is an entry with the key "everybody", the value is the list of operations used to make the decision. Otherwise, all operations are permitted.
Given the list of permitted operations, the next step is to determine the requested operation, which is derived from the "action" attribute of the request. If the requested operation is in the list of permitted operations, the request is permitted. If the requested operation is in the list of permitted operations, but preceded by a plus sign, the request is permitted only if it contains a valid signature.
A sample access control list represented as a properties object follows. In this example, the user permits all operations from user "friend" at "neighbor", forbids all operations from any user at "bad", and allows all operations from all other users as long as they are signed.
<properties>
<entry key="friend@neighbor">send fetch subscribe</entry>
<entry key="notifier@neighbor">change end</entry>
<entry key="@bad"></entry>
<entry key="everybody">+send +fetch +subscribe
+change +end</entry>
</properties>
The SIMP protocol is built on the exchange of commands via streams. Commands of a particular form are used to request specific actions. The remainder of this document describes the actions associated with commands of a given form. This section introduces the notation used to make the association via a command synopsis.
A command synopsis consists of four parts. The path component gives the connection to which a command may be issued by a given class of programs. The operation component gives the operation used during the access control decision. This component is empty when no access decision is associated with the command. The syntax component gives the syntactic constraints on a properties object that determine if the command is of a particular form. The reply component gives the syntactic constraints of the various possible replies to a request. The reply component is empty when the command is not a request. A command synopsis template follows.
Path: path Operation: operation (optional) command pattern - reply pattern (optional) - reply pattern (optional)
The path notation describes which class of programs can issue a command. The two classes are client and server, abbreviated as C and S. There are two connections to which a command can be issued, a routing connection, and a notification connection, abbreviated R and N respectively. A path is a program class, and a connection separated by the symbol ->. Thus S->R means the command it describes may be issued by a server to a routing connection.
A pattern matching notation is used to present syntactic constraints on properties objects.
In a properties object, the value associated with a key is an arbitrary string, however, certain commands impose more structure on some values. For example, when a request is used to send an instant message, the "from" attribute is an IMA. A description of the value types used in the specification follows.
An unrestricted sequence of characters.
Every instant message address is syntactically an Internet email address as described in RFC 2822 [Email]. Each IMA has exactly one at-sign character (@) separating a user name and a domain name. The user name "notifier" is reserved for use by servers. A server has its own IMA so it can sign commands it originates.
A string that contains a properties object's external representation. The properties object can be extracted by giving the string to an XML parser.
An integer giving a duration in milliseconds.
A date has the following format:
yyyy-mm-dd hh:mm:ss GMT{+|-}hh:mm
where yyyy-mm-dd specifies the day with a four digit year, a two digit month (01-12), and a two digit day of the month. The local time is specified by two digits that give hour of the day (00-23), two digits that give the minutes in the hour (00-59), and two digits that give the seconds in a minute. The time zone is given as a signed offset from GMT, with two digits giving the hours away from GMT, and the remaining two digits giving fractions of an hour in minutes. An example of a date generated in Eastern Daylight Time is:
2001-06-26 07:28:56 GMT-04:00
A 32-bit signed integer.
One of the strings "online" or "offline".
A MIME type [MIME].
A version number of the form major.minor, where both major and minor are small unsigned integers with no leading zeros.
A status string is a 3 digit code code, followed by a single space, and then a reason phrase.
The policy for assigning response codes loosely follows the convention used in HTTP/1.1 [HTTP1.1, Section 6.1.1].
The individual values of the numeric status codes defined for SIMP, and the corresponding reason-phrase's, are presented below. The reason phrases must not be replaced by local equivalents.
status = 200 [Section 5.1.1] OK
| 201 [Section 5.1.2] Indeterminant
| 400 [Section 5.2.1] Bad Request
| 401 [Section 5.2.2] Request Too Large
| 402 [Section 5.2.3] Request Time Out
| 410 [Section 5.2.4] Not Found
| 411 [Section 5.2.5] Unauthorized
| 412 [Section 5.2.6] Forbidden
| 413 [Section 5.2.7] Unsupported Media Type
| 414 [Section 5.2.8] Not Available
| 500 [Section 5.3.1] Bad Reply
| 501 [Section 5.3.2] Reply Too Large
| 502 [Section 5.3.3] Reply Time Out
| 503 [Section 5.3.4] Internal Error
| 504 [Section 5.3.5] Busy
| 505 [Section 5.3.6] Version Not Supported
For each form of command, a set of attributes must be defined, and the value associated with each attribute must satisfy some syntactic constraints. Consider a properties object constrained as follows, the "action" attribute must be "fetch", the "to" and "from" attributes must each be an IMA, and the "date" attribute must be a date. These constraints on the object are shown with the pattern:
fetch(ima to, ima from, date date)
Some entries are optional and identified by surrounding brackets. For example, in the send command, the "reply to" attribute need not be defined, but when it is, it must be an IMA.
send(ima to, ima from, [ima reply to],
date date, mime type, string body)
Given a pattern, a command is well-formed if it defines the various attributes given by the pattern, and the value associated with each attribute meets the syntactic constraints given by the value type of the attribute in the pattern.
Some requests are subject to access control. An operation will be associated with each class of controlled requests. A request subject to access control must define the "to" and "from" attributes, and their values must be IMAs. An access decision is made at the contact place of the recipient of the request. If the object is signed, the signature is validated. The access control list of the recipient is used to make the decision using the given operation and the algorithm presented in [Section 3.9].
Note that a reply can be signed, but the validity of the signature will only be checked by a client.
This section describes values for the status attribute, which is part of every response, except a successful login request [Section 8.1].
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
SEND the instant message reached its destination; FETCH a fetch request reached a presence information server and was handled successfully, see [Section 6.2] for details; and SUBSCRIBE a subscription request reached a presence information server and was handled successfully, see [Section 6.3] for details; and NOTIFY the presence information reached its destination.
The server delegated the handling of the request to a service that will not provide a future authoritative response indication to the server.
The request could not be understood by the server due to malformed syntax. The client should not repeat the request without modifications.
The server is refusing to process a request because the request content is larger than the server is willing or able to process.
The client did not produce a request within the time that the server was prepared to wait. The client may repeat the request without modifications at any later time.
The server has not found anything matching the IMA. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
The request requires user authentication. A server might reply with this status code when the IMA requires that requests of the given method be signed. The request may be repeated if it is signed. If the server does not wish to make this information available to the client, the status code 410 (Not Found) can be used instead.
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request should not be repeated. If the server does not wish to make this information available to the client, the status code 410 (Not Found) can be used instead.
The server is refusing to service the request because the content of the request is in a format not supported by the requested resource for the requested method.
The server is refusing to service the request because a resource is currently unavailable. For example, an inbox is unavailable if it is closed, and a presence entity that has been assigned no presence information is unavailable.
The server received an erroneous response from another server while attempting to complete the request.
The server generated or received a reply that is larger than the server is willing or able to send to the client.
The server did not receive a timely response from another server while attempting to complete the request.
The server encountered an unexpected condition which prevented it from fulfilling the request.
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.
The server does not support, or refuses to support, the SIMP protocol version that was used in the request message.
A client can issue these requests via its notification connection or via any routing connection. Servers can route the requests using a routing connection.
In each request, the "to" attribute is the recipient, the "from" attribute is the originator of the message, and the "date" attribute is the time at which the request was created.
Path: C->N, C->R
Operation: send
send(ima to, ima from, [ima reply to],
date date, mime type, string body)
- reply(status status)
The send request sends an instant message to the recipient. The "type" attribute is the MIME type of the body of the message. If present, the "reply to" attribute specifies the IMA to be preferred when replying to the originator. The properties object displayed in [Figure 1] is a well-formed send request.
Path: C->N, C->R Operation: fetch fetch(ima to, ima from, date date) - reply(status status)
The fetch request seeks the current presence information associated with the user given by the "to" attribute. When the request succeeds, the server sends the information in a "note change" [Section 7.1] request.
Path: C->N, C->R Operation: subscribe subscribe(ima to, ima from, date date, time duration, [string opaque]) - reply(status status, [time duration])
The subscribe request asks that the originator of the message be informed of changes in the presence information associated with the user given by the "to" attribute. The duration of the requested subscription is also a parameter of the request. If the requested duration is negative, the maximum allowed duration is requested.
If the opaque string matches the one used in a previous request with the same "to" and "from" attribute, the old subscription is replaced by a new one. If the duration is zero, the subscription is canceled. When the opaque string is missing, the subscription replaces any existing old subscription that also has no opaque string.
A successful reply includes the duration of the subscription granted. When the request succeeds, the server sends the current presence information in a "note change" [Section 7.1] request if the duration in the reply is positive.
Path: C->N, C->R inquire(ima to, ima from, date date) - reply(status status, [string message])
The inquire request seeks information about the server providing the contact place named by the IMA to. The information is returned in the message attribute when the request is successful.
Path: C->N, C->R who(ima to, ima from, date date) - reply(status status, [string message])
The who request seeks the list of online users at the server providing the contact place named by the IMA to. The information is returned as a space separated list of IMAs in the message attribute when the request is successful. A user is allowed to access online information about another user only if that user is allowed to fetch their presence information.
The following messages originate from the contact place of the user supplying presence information. If HOST is the domain name associated with the contact place, the originator's IMA for these commands is notifier@HOST. Servers have their own IMA so that they can sign commands they originate. Requests that can be signed include a "date" attribute giving the time at which the request was created.
Path: S->R, S->N
Operation: change
note change(ima to, ima from, ima regarding, date date,
state state, [date on since], properties message)
- reply(status status)
This request is generated if the user given by the "to" attribute has a subscription to presence notifications from the user given by the "regarding" attribute, and the presence information has been changed, or in response to a fetch or subscribe request. If there is no reply to this request or the request is otherwise not successful, the subscription can be dropped by the server.
Path: S->R, S->N
Operation: end
note subscription end(ima to, ima from, ima regarding,
date date, state state, [date on since],
properties message)
- reply(status status)
The subscriber given by the "to" attribute is notified that the subscription to presence notifications for the user given by the "regarding" attribute has been ended prematurely. A user may receive this command if the server providing the presence information is being shut down in an orderly fashion or if the owner of the presence information dropped the subscription.
Path: S->N note subscription(ima subscriber)
This command informs the owner of some presence information that the user given by the "subscriber" attribute has subscribed to receive presence notifications.
When a notification connection is opened to a user's contact place, this command is used to notify the user of the current set of subscribers.
Path: S->N note subscription lapse(ima subscriber)
This command informs the owner of some presence information that the user given by the "subscriber" attribute is no longer subscribed to receive presence notifications.
Path: S->N note bump()
This command informs a client that another client has connected to the server using the same user name, so any client that receives the note bump command should not attempt to reconnect to the server automatically.
With the exception of the login request, the remaining requests and commands are issued by a client through a notification connection after user authentication.
Path: C->R
login(string user)
- challenge(string nonce, string opaque, string algorithm,
version min version, version max version, ima to,
[int port])
- reply(status status)
The login protocol is loosely based on HTTP digest authentication [HTTP-Auth]. When the client receives the challenge, the client constructs a string consisting of the user name, the password, and the nonce, each separated by the colon character. A digest of the string is formed using the given algorithm which by default is MD5. A Base64 encoding [Base64] of the digest is the authorization string supplied in the connect request, along with the opaque string.
In the login protocol, a nonce and an opaque value are strings with no interesting internal structure from the point of view of outside observers of the exchange.
A server advertises support for a range of protocol versions with the "min version" and "max version" attributes.
The to attribute contains the instant message address of the user's contact place.
If the port attribute is missing, the connect request must be issued on the connection used to make the login request.
The status attribute is present only when the request is unsuccessful.
Path: C->N connect(string authorization, string opaque, version version) - reply(status status, [properties self])
If the reply to the login request does not specify a port, the connection used to send the login request becomes a notification connection, otherwise, a client opens a notification connection to the server using the port returned in the login request. The next request on a notification connection must be the connect request. It supplies the authorization described above, the opaque string from the login reply, and a version number. The "version" attribute is the version number of the protocol to be used by the client. This number should be within the range of numbers advertised by the server. A successful reply to the connect request includes the user's profile.
A client logs out by closing its notification connection.
Path: C->N get profile() - reply(status status, [properties self])
This request returns the user's profile when the request is successful.
Path: C->N set profile(properties self) - reply(status)
This request sets the user's profile.
Path: C->N get acl() - reply(status status, [properties self])
This request returns the user's access control list. The access control list is represented as a properties object, as described in [Section 3.9].
Path: C->N set acl(properties self) - reply(status status)
This request sets the user's access control list. The access control list is represented as a properties object, as described in [Section 3.9].
Path: C->N drop subscription(ima subscriber) - reply(status status)
This request drops the subscription of the user given by the "subscriber" attribute.
The authenticity of some commands can be established using digital signatures.
encapsulate(ima to, properties contents, string signature,
string algorithm, string certificate)
The encapsulate command acts as an envelope for a digitally signed command. Any command can be signed if it includes a "from" attribute, giving the IMA of the originator of the command. The "to" attribute is the recipient of the signed command. The "contents" attribute is the XML representation of the signed command. The "signature" attribute is the Base64 encoding of the digital signature of the signed command when represented as an array of UTF-8 encoded bytes. The "algorithm" attribute is the name of the algorithm used to generate the signature, which by default is SHA-1/DSA. The "certificate" attribute contains the Base64 encoding of a DER encoded X.509 Version 3 Certificate [X.509V3]. The certificate must contain a URI that embeds the originator's IMA as one of the certificate's Subject Alternative Names. The scheme of the URI must be "simp". The certificate attribute may also contain intermediate certificates that make up a complete certificate chain other than the trust anchor. Chains are checked using the PKIX certification path validation algorithm.
The SIMP 2.0 Protocol has been implemented and released with an open source license. It is available at the SIMP Home Page.
Both the server and the client have been implemented in Java. They run on machines with a Java 2 Standard Edition 1.4 runtime environment or newer. The result is an instant messaging system that is both distributed and easy to distribute.
The [Basis] document provided valuable ideas adopted by this protocol, however, a unique aspect of this protocol is the layering of specific forms of requests on top of a generic layer designed to exchange only one type of data structure. This layering is reflected in the code by separate and fairly independent modules for each layer. The layering also greatly eases the effort required to modify the protocol and add new features.
Security is based on the following assumptions. Servers other than a user's home server are not trusted. Digital signatures provide the only means for the authentication of requests that are delivered to a server via the routing connection. A certificate authority issues certificates that contain a URI that embeds the IMA as one of the certificate's Subject Alternative Names. The scheme of the URI must be "simp". The authority issues a certificate with a given IMA only to the user of the contact place named by the IMA.
Via the use of access control lists, a user's home server makes security decisions on behalf of the user. An access control list specifies which requests are permitted by the originator of the request.
Each request that is subject to access control has a "from" attribute that gives the IMA of the originator of the request. A signed request encapsulates the request and includes a certificate with an embedded IMA. A server or a client making an access control decision can be sure a request is signed by the originator by comparing the embedded IMA with the one in the "from" attribute of the request.
Note that in security sensitive environments, servers should sign note change requests. The signing of note change requests protects clients from being spoofed.
The protocol allows unsigned requests, but provides no mechanism to verify the authenticity of these requests.
Jay A. Carlson conceived this task and served as our link to the IMPP Working Group. In conjunction with the author, this protocol was implemented and debugged by Galen B. Williamson and Sasha P. Caskey.
Jeffrey L. Kurtz provided valuable feedback on an early draft of this document.
This effort was performed under the Collaborative Services Project and funded by The MITRE Corporation's Technology Program. The project is led by Roderick J. Holland.
The response to a login request contains the user's instant message address and no longer contains a host for redirection.
The opaque string in a subscription request is now optional.
This version of the protocol adds the who request, and certificate chains that are checked using the PKIX certification path validation algorithm.
This version of the protocol changes way in which content is framed on a stream. Each frame starts with a length and a tag, followed by a properties object. This change makes it easy for the server to peek at the first object and decide how to process the rest of them. In this way, a single port can be used for both router connections and notification connections.
Presence information is always returned in a note change request, so that it can always be signed.
The status message associated with a reply is drawn from a fixed set.
The login request has been changed so that the connection on which the login request is made can become a notification connection.
The protocol transfers a profile or an ACL as an encoded properties object.
The server uses the note bump command to tell a client its notification connection is closing because another client connected using the same user name.
This version of the protocol specifies the use of X.509V3's Subject Alternative Names for digital signatures, and drops the description of the divert command, as it was never implemented.
This version of the protocol changes the format of a date, and makes sure that every request that can be signed is dated.
This version of the protocol changes the message attribute in a description from an unstructured string into a properties object.
This version of the protocol adds support for digital signatures.