Internet DRAFT - draft-dpage-qimp
draft-dpage-qimp
D. Page
Internet Draft infotechniques.com
Document: draft-dpage-qimp-00.txt October 2000
Category: Informational
Quick Instant Messaging Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or rendered obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Index
Index........................................................1
Abstract.....................................................2
Conventions used in this document............................2
Client to Server communications..............................3
Login...................................................3
Password Modification...................................4
Offline Message Format..................................4
The Offline Message.....................................5
Request Buddy List......................................6
Upload Buddy List.......................................6
Determining Buddy IP address............................7
Sending Offline Messages................................7
Logout..................................................8
Server to Client communications..............................9
Updating the Buddy List.................................9
Heartbeat...............................................10
Client to Client (Peer to Peer)..............................10
Instant Message Send....................................10
File Transfer...........................................12
Instruction Reference........................................13
Page Informational - Expiration April 2001 1
Quick Instant Messaging Protocol October 2000
Formal Syntax................................................14
Security Considerations......................................15
References...................................................15
Acknowledgements.............................................15
Author's address and copyright...............................15
1. Abstract
This memo describes a protocol that allows users from different
instant messaging service providers to send and receive messages and
files in real time over a TCP/IP based network via a common
protocol.
This memo does not discuss the implementation of server, client or
administration software.
2. Conventions used in this document
In examples, "C:", "B:" and "S:" indicate lines sent by the client,
buddy and server respectively.
The following abbreviations are also used in this memo:
IM Instant Message
IMS Instant Messaging Server
IMSP Instant Messaging Service Provider
File Receiver A remote client who accepts a file transfer
User A person who has an account on a IMS
Buddy A user with who a client corresponds on a
regular basis.
Buddy List A list of users with corresponding IM addresses
and eventually IP addresses
Mail Drop Storage space for offline messages on an IMS
Status Message A message that is either + (positive) or
(negative). a - status message is an error.
Status Command A Status Message followed by information that
must be parsed.
Status Command=Status Message+varible value
Page Informational - Expiration April 2001 2
Quick Instant Messaging Protocol October 2000
Timeout A length of time if after which there is no
activity, a connection can be cut.
<CRLF> Character Return-Line Feed character
combination. (CR = ASCII 13, LF = ASCII 10)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Client to Server communication
This section is the technical explanation of the connection process
that is presented above. All arguments to instructions must be
separated by a space.
All server messages in response to a client demand must respond with
a status message which is either positive (+) or negative (-),
EXCEPT with a username. After a user command, the server must
respond with a +, and wait for the pass command.
Login
If the authentication stage fails, the server must then send a - or
a + code with a message. The server may close the connection after
a - response, but it is recommended that the server allow 3 retries
before closing the connection.
A message is permitted after the password has been entered but there
must be no indication to a client in case of a valid or invalid
username. Permitted messages are "-Invalid username or password", or
"+Session opened", or "-Server not ready", for example.
The IM Client opens a connection to an IM server on TCP port 5194.
Once the session is established, the server will respond with a
positive or negative message (+ or - prefix). The server may send 1
line of information, terminating with a Character return-Line Feed
(<CRLF>) instruction. This string must contain at least the type of
IMS server and version. Further information is optional.
S:+infotechniques.com Quick Instant Messaging Server 0.99
Once the + message has been parsed by the client, the client can
enter the authentication stage. In the authentication stage, the
client must enter the USER and the PASS command.
The syntax of the USER command is USER <username>. The syntax of the
PASS command is PASS <password>.
When the username is parsed correctly, the IMS must respond with a +
Page Informational - Expiration April 2001 3
Quick Instant Messaging Protocol October 2000
status message, even if the username is invalid. Only after the
password has been entered can the server respond with a + (the login
has been successful or - (Bad username and/or password) message.
C:user joeuser
S:+
C:pass abcdef123456
S:+Session Opened
In case of failure (bad password or username)
C:user joeuser
S:+
C:pass 123456
S:-Invalid username or password.
The server may disconnect, or may allow a retry. It is recommended
that the server allow 3 retries before closing the connection, but
the client must check that the connection has not been closed by the
server, and reopen a connection before restarting the
authentication.
As mentioned above, the server must not make a distinction between
an invalid username and an invalid password.
Password Modification
The Password modification command syntax is CHANGEPW oldpassword
newpassword newpassword:
C:changepw abcdef123456 123456 123456
S:+Password Changed
The server must enforce password policy. If an illegal password is
entered, the message must represent the error
S:-Password too short
or
S-New password identical to old password
Offline Message Format
Offline Messages are plain ASCII text messages, that include the
Extended ASCII characters (128 through 255), therefore the client
must support 8 bit ASCII characters.
The format of offline messages is as follows:
To: Receiver name
Page Informational - Expiration April 2001 4
Quick Instant Messaging Protocol October 2000
From: sendename <sender username>
This is an offline message.
The offline message
An offline message is comparable to e-mail, as it is a message sent
to a user who is not on line at the time of the emission of the
message.
When a client is online, the mail drop is locked, and can only be
accessed by the client (reception of offline messages). The client's
mail drop can only be used when the client is not declared online by
the server (HEARTBEAT timeout or after an authenticated LOGOUT
command).
The client requests his offline messages with the LOM command (List
Offline Messages). When the client requests his offline messages,
the server must not respond with a status message, but with a status
command, and if the status command is positive, the status command
must include the numerical value of the number of messages on the
server. Please note again that the status command is a status
message immediately followed by a variable (in this case the number
of offline messages). There must be no separation between the status
message and the variable.
C:lom
S:+4
To retrieve the offline messages, the client must send a RETR
command followed by the message to receive.
To delete a message, a client can send a DELE command, followed by
the message number to erase.
It is recommended that the client delete all messages that are
included in the offline messages box on the server after retrieving
them. Once a message has been sent, the server must respond with a +
or - message, depending on the transmission state of the message.
C:lom
S:+1
C:retr 1
S:To: joeuser
From: johnpublic <John Public>
This is an Offline Message
S:+Ok
C:DELE 1
S+Ok
Offline messages may have a reception acknowledgement system, but
this is dependant on the server. The server may send an offline (or
online) message back to the source informing the client of the
reception. Such a function is highly recommended, but would be
Page Informational - Expiration April 2001 5
Quick Instant Messaging Protocol October 2000
server based, and totally transparent to this protocol.
Request Buddy List
A client requests his buddy list with the RBL command. The server
will respond with a text and tab separated list of buddy names and
buddy addresses:
C:RBL
S:Joe Userjoeuser@instantmessaging.com
Robert User robuser@instantmessaging.com
Sue Publicspublic@infotechniques.com
S:+Ok
Once the list has been received, the client must contact each domain
and request the validity and availability of the user. The client
must parse each line in the buddy list to separate the addresses
from the buddy names. In the case of joeuser@instantmessaging.com:
joeuser is the buddyname, who has an IM account at
instantmessaging.com
Upload Buddy List
A client can add buddies to his buddy list with the UBL command.
Before an update of the list, the client must execute an RBL. If no
RBL has been requested, the server must refuse the modification of
the Buddy List.
The format is a text and tab file, composed of the name of the
buddy, followed by a tab, then the Instant Messaging Address
(buddyname@domain), example:
Joe User joeuser@instantmessaging.com
John Public jpublic@im.infotechniques.com
The client must re-authorize himself to the IMS when the buddy list
is updated, so the client must connect to his IMS, send the UBL
command, followed by the USER / PASS combination if the server
answers with a + status command.
The client must then send the buddy list information as 8 bit ASCII
text, followed by <CRLF>.<CRLF>. The server must answer with a +
status command if the upload was successful, and then close the
connection.
S:+infotechniques.com Quick Instant Messaging Server 0.99
C:UBL
S:+
C:USER joeuser
S:+
C:PASS 123456
Page Informational - Expiration April 2001 6
Quick Instant Messaging Protocol October 2000
S:+
C: Joe User j oeuser@instantmessaging.com
John Publicjpublic@im.infotechniques.com
.
S:+
Disconnection.
Determining Buddy IP address
The client must connect to the server that contains the Buddies IM
account, on TCP port 5194 Once the session is established, the
server will respond with a positive or negative message (+ or -
prefix). The server may send 1 line of information, terminating with
a Character Return-Line Feed <CRLF> string. This string must
contain at least the type of IMS server and version. Further
information is optional.
The client must then request user status with the US command. The
IMS will enter update mode, and answer with a + status message.
The client must identify himself with the FROM command, followed by
the client's IM address (user@domain), so that the server can later
inform the client that a buddy has requested his address (to update
the buddy list for example).
Once the server has given a + status message, the client can request
the status of the user with the TO command followed by the contact's
username (pseudo without the @domain extension):
S:+Welcome to instantmessaging.com
C:US
S:+
C:FROM joeuser@instantmessaging.com
S:+OK
C:TO robuser
S:+123.123.123.1
Then the server will drop the connection.
If the user is not online, or is not a valid user, the server will
display an error message:
S:-User not on line or invalid user name
Then the server will drop the connection
Sending Offline Messages
Page Informational - Expiration April 2001 7
Quick Instant Messaging Protocol October 2000
When a user want's to send an offline message, the server must
accept the request, even though the user may not exist. An offline
message must not be more than 512 bytes, and must not contain
attachments.
When a client whishes to send an offline message to user, the remote
client must open a connection to TCP port 5194, and use the OM
(Offline Message) command. The syntax of this command is OM. If the
server is available to accept offline messages, a positive status
message is sent. The server then waits for the client to identify
himself. This is accomplished with the FROM command. The syntax for
the FROM command is FROM source_IMaddress.
If the server is able to parse messages from this user, it will
respond with a + message, and waits for the user to enter the
maildrop name, with the TO command. The syntax is TO
maildrop_IMAddress.
The server must respond with a + message, and enter edit mode. the
message must be ended with a Character Return-Line Feed-.-Character
Return-Line Feed sequence (<CRLF>.<CRLF>).
When this sequence is received, the server must consider that the
offline message has been terminated, and must respond with a
positive status message. When the client receives the + message, it
can close the connection.
It is then the server's job to place the message into the
appropriate maildrop.
Example:
S:+Welcome to instantmessaging.com
C:OM
S:+
C:FROM joeuser@instantmessaging.com
S:+
C:TO robuser
S:+Ok to send offline message. <CRLF>.<CRLF> to end.
C:This is an offline message test
over
several
lines
.
S:+
The server then must disconnect.
Logout
Page Informational - Expiration April 2001 8
Quick Instant Messaging Protocol October 2000
When a client wishes to logout of the IMS, the client must connect
to his IMS, and execute a LOGOUT pseudonym
The IP address of the machine requesting the LOGOUT should be
compared to the declared IP address of the client.
If the logout is authenticated, the server must not give out the
clients IP address to buddies, and must store any Offline Messages
in the user's mail box.
4. Server to Client communication
Updating the Buddy List
When a client connects to the IMS, the not all the clients Buddies
may be connected. The server must have a method of contacting the
client when a buddy has connected.
As IMS are not linked in any way between themselves, the buddy list
can only be updated by the client on a user defined basis.
The client must connect to a IMS, and request the status of a member
of the Buddy List with the US command (defined above).
If another user requests the status of an online client, the server
must execute an UPDATE to the client only if the username of the
remote user who requested the user status is contained in the buddy
list of the corresponding user.
Generally the client will communicate to a server to update the
server with information, but when a client is connected, the server
needs to update the Buddy List on the client when a buddy connects.
Server to client communications happen on TCP port 5196.
When a user has connected to the IMS, and executed a US command, the
server must log the command, username, and the user's IP address
(see US command). The server must then connect to the client's IP
address on TCP port 5196. If the client is available, and can accept
commands, it will answer with a simple + status message. The server
will execute the UPDATE command. The client will respond with a +
status message.
The server will respond to a positive status message with a USER
command. The server will send the user's address (pseudo@domain). If
the address is received correctly, the client will respond with a +
status message, otherwise a - message will be sent. The server must
repeat 3 times this sequence if there is a problem, and then it must
drop the connection if a third error (-) message is detected.
C:+Ready to UPDATE
S:UPDATE
C:+
S:USER joeuser@instantmessaging.com
C:-Not ready
Page Informational - Expiration April 2001 9
Quick Instant Messaging Protocol October 2000
S:USER joeuser@instantmessaging.com
C:+
Server releases the IP connection.
The client must then request the status of the user joeuser at the
domain instantmessaging.com (see US command). If the user is
available.
Heartbeat
Every 10 minutes, the server must run a HEARTBEAT. This is simply a
a connection to the clientĘs IP address defined at the login, to
verify that the client is still online.
The intervals between heartbeat connections is defined by the IMS.
The IMS must connect to the IP address that is supplied by the
client at login, on the TCP port 5196. If the connection is
successful, the server can consider that the client is still online,
and can drop the connection. If the connection attempt fails or
times out, the server must consider that the connection has been
closed. The server must now enter a user-disconnected mode, accept
offline messages, and no longer distribute the client IP address to
other buddies requesting it.
5. Client to Client (Peer to Peer communication)
Instant Message Send
When a client wants to send an instant message, the client must
resolve the IP address of the message receiver, either by looking in
the buddy list locally, or by connecting to the receiver's IMS, and
running a US command.
Instant Messages have the same sending format as Offline Messages.
The client must connect to the receivers IP address on TCP port
5194, and use the IM (Instant Message) command.
When a client whishes to send an offline message to user, the remote
client must open a connection to TCP port 5194, and If the receiver
is available to accept an IM, a positive status message is sent. The
receiver then waits for the client to identify himself. This is
accomplished with the FROM command. The syntax for the FROM command
is FROM source_IMaddress.
If the receiver is able to parse messages from this user, it will
respond with a + message, and enters edit mode. the message must be
ended with a Character Return-Line Feed-.-Character Return-Line Feed
Page Informational - Expiration April 2001 10
Quick Instant Messaging Protocol October 2000
sequence (<CRLF>.<CRLF>).
When this sequence is received, the receiver must consider that the
Instant Message has been terminated, and must answer with a positive
status message (+). When the client receives the + message, it can
close the connection.
Example:
C = Client
R = Message Receiver
R:+
C:IM
R:+
C:FROM joeuser@instantmessaging.com
R:+<CRLF>.<CRLF> to end.
C:This is an Instant Message test
.
R:+
The client then must disconnect.
At times, a client will transmit an instant message to a buddy who
will not be online. This is caused by 2 possible factors :
- The client has cached a copy of the clientĘs IP address, and
is cannot be informed of a LOGOUT, which is only transmitted
to the server.
- The buddy has crashed or is a victim of a network outage and
both the client and the buddyĘs IMS are not informed of the
deconnection of the buddy
In this case, the client may implement the NA (No Answer) command.
The syntax is NA buddyname.
When a client issues a NA buddyname to a IMS, the server must
consider that the requested buddy is no longer online, or reachable
via the clientĘs portion of the network, and will enter Offline
Message reception mode. The client must then execute the OM command
and then send an Offline Message.
Once the Offline Message has been sent, the server must try a
heartbeat connection.
If the heartbeat connection fails, the server must consider that the
user is no longer online, and enter offline mode, and accept Offline
Messages, and must no longer communicate the userĘs IP address.
S:+
C:NA joeuser
S:+
C:OM
. . .
Page Informational - Expiration April 2001 11
Quick Instant Messaging Protocol October 2000
S+
Disconnection.
File Transfer
Client to Client data transfers can include Real Time file
transfers.
The client must connect to a receiver's IP address on TCP port 5198.
The file receiver must respond with a + status message to inform the
client that it is ready to accept file transfer commands.
When the client receives the + status message, the client must
inform the file receiver of the file name and size. This is carried
out with the FILE and SIZE commands.
The FILE command syntax is FILE filename. If the file receiver can
interpret the request, it must respond with a + status message. The
client can then issue the SIZE command. The syntax is SIZE filesize.
The file receiver must answer with a + status request if the request
has been correctly received.
When the client is ready to send the file, it must send a RTS (Ready
To Send) command. The file receiver must validate this request. If
the request is followed by a + status message, the client must
assume that the file transfer has been authorized by the file
receiver, and must start sending the file. The file receiver will
enter file reception mode.
The file send format is 8 bit ASCII.
When the file receiver has received a quantity of bytes that
corresponds to the number of bytes that was declared in the SIZE
command, the file receiver will exit the file reception mode, and
re-enter command mode, and respond with a + status message.
When the client receives the + status message, it will send the 32
bit CRC of the file with the CRC (Cyclic Redundancy Check) command.
If the CRC of the file sent corresponds to the CRC of the file
received, the file receiver will respond with a + status message,
and close the connection. If the CRC does not correspond, the file
may be sent again. The above connection procedure must be
renegotiated.
If after the file receiver has received a number of bytes equal to
the number of bytes defined in the SIZE command, but the file
receiver does not receive a CRC command (the client is still sending
data to the file receiver), the file receiver must drop the
connection. The file receiver must consider that the file may be
corrupt.
If the client has sent the file, and send a CRC command, and the
Page Informational - Expiration April 2001 12
Quick Instant Messaging Protocol October 2000
file recipient does not respond, the client must consider that the
file recipient is no longer capable of receiving the file, and must
renegotiate a connection to send the file.
In case of a timeout by the client or file receiver, the connection
must be dropped.
Example:
R:+
C:FILE document.doc
R:+
C:SIZE 12565
R:+
C:RTS
R+
C:data of the file sent here.........
.....................................
--
.....................................
.........
R:+
C:CRC 15GH
R:+Good Copy
Disconnection.
6. Instruction Reference
+ Positive Status Message. Operation complete
- Negative Status Message. Operation failed
USER Username entry command.
Syntax: USER username
PASS Password entry command.
Syntax: PASS password
LOM List Offline Messages. Returns a status command +x,
Where x is an integer number between 0 and 65536 (2^16)
OM Create an Offline Message
TO Person who is destined to receive an Instant Message.
Syntax: TO buddyname@hostdomain.
CRC Transmit a 32 bit Cyclic Redundancy Check on a file to
verify integrity after a file transfer.
Syntax: CRC 32bitCRCvalue
FILE Transmit the name of a file that will be transmitted.
Page Informational - Expiration April 2001 13
Quick Instant Messaging Protocol October 2000
Syntax: FILE filename.extension.
SIZE Transmit the size of the file that will be transmitted.
Syntax: SIZE filesizeinbytes
NA Not Available - Used when a client tries to communicate
to a buddy who has suddenly gone offline.
Syntax: NA username
IM Send Instant Message
UPDATE Update the buddy list on a client as a known buddy has
requested the clients status. The server will send the
buddy name to the client with his IP address.
FROM Indicates in an instant message the origin of an
Offline or Instant Message.
Syntax: FROM buddyname@domain.
TO Indicates in an Offline or Instant Message the reciever
of the message.
Syntax: TO buddyname
US User Status. Indicates if a buddy is on or offline.
Returns an error if the user is disconnected, or the IP
address of the buddy if his online.
Syntax: US buddyname.
RBL Request Buddy List. Demands the Buddy List, stored on
the server.
UBL Upload Buddy List. After modification of a buddy list
locally, the list can be uploaded to the server, after
re-authorization (USER / PASS combination)
DELE Delete an Offline Message stored in the userĘs
Maildrop.
Syntax: DELE messagenumber.
CHANGEPW Change Password. Modifies the userĘs access password to
the IMS.
Syntax: CHANGEPW oldpassword newpassword newpassword.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [1].
All commands that pass an argument are separated by a space
character.
A status command is a status message with an argument or message.
There must not be a separating character between the status message
Page Informational - Expiration April 2001 14
Quick Instant Messaging Protocol October 2000
character (+ or -) and the associated command.
All status messages and status commands extend over 1 (one) line
only, and must be terminated by a Character Return - Line Feed
<CRLF> character.
Please note that in most cases, text after the status message is
optional, except when more information is needed to comprehend an
error.
+ must always indicate a success.
- must always indicate a failure or error.
8. Security Considerations
To reduce problems with UCE, this protocol has been designed not to
reveal users on a server if they are not online. A server will
silently fail any request for a connection, user status request, or
offline message. The aim is to avoid a scan of a IM Server for names
that can be integrated into a commercial database.
The system must allow a positive answer to a Status Request if the
user is online, but only one message must be used for the following
cases :
- User not online
- User does not exist on the server
The ideal status message for this case is "-".
9. References
1 Postel, J., "Simple Mail Transfer Protocol", RFC-821, August 1982
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
10. Acknowledgments
Microsoft Corporation, America On Line, and Yahoo! for the current
generation of IM software clients, despite the barriers erected to
stop intercommunication between them, and the inspiration that they
have me in designing this memo for the next generation of IM
clients.
11. Author's Addresses
Daniel Page
infotechniques.com
11 rue Henri Aguado
92230 Gennevilliers
France
Page Informational - Expiration April 2001 15
Quick Instant Messaging Protocol October 2000
Phone: +33 (0) 6 6370 3111
Email: daniel_page@yahoo.fr
Full Copyright Statement
Copyright (C) The Internet Society (date). 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 Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
The URL infotechniques.com is a domain belonging to the author. The
domain instantmessaging.com is used only as an example, and does not
exist on the Internet to the best knowledge of the author at the
time of writing.
Page Informational - Expiration April 2001 16
