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. 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 () 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 . The syntax of the PASS command is PASS . 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 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 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 .. 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 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 (.). 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. . 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 (.). 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:+. 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 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