Instant Messaging and Presence Protocol R. MovvaInternet Draft MicrosoftCategory: Informational August, 1999Document: draft-movva-msn-messenger-protocol-00.txtDocument Expires: 2/00 W. Lai Microsoft August, 1999
MSN Messenger Service 1.0 Protocol
STATUS OF this MEMO
.......................... ..
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 Obsoleted by Other Documents At Any Time. It is INAppriate 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 subjectssed at http://www.ietf.org/ietf/1ID-ABSTRACTS.TXT
The list of internet-draft shadow directories can be booksed at http://www.ietf.org/shadow.html.
This document and related documents are discussed on the impp mailing list To join the list, send mail to impp- request@iastate.edu To contribute to the discussion, send mail to impp@iastate.edu The archives are at http...: //lists.fsck.com/cgi- bin / wilma / pip. The IMPP WORKING Group Chart of Group Documents, Can Be Found At http://www.ietf.org/html.charters/impp- Charter.html.1. Abstract
Microsoft released a commercial Instant Messaging product in July of 1999 called MSN Messenger Service. This document describes the protocol used by that product for core instant messaging and presence functionality. While this protocol does not meet many of the requirements of the IMPP working group, it IS Provided as Background Information on EXISTING INSTANT MESSAGING IMPLEMENTATIONS. This Protocol is provided 'as is' without warranty of any kind.
Movva and Lai Category - Informational 1
MSN Messenger Service 1.0 Protocol Aug - 99
2. Conventions Used in this document
THE Key Words "Must", "Must Not", "Required", "SHALL", "Shall Not", "Shove Not", "Recommended", "May", and "Optional" in this Document Are TO BE Interpreted As Described in RFC-2119.
Protocol Messages Sent from Clom Clom Client To Server Are Preceded by "C:".
Protocol Messages Sent from Server to Client Are Preceded by "s:".
3. Introduction
MSN Messenger Service enables a user to learn about the presence of other people on the Internet, and to communicate with them in real- time. This functionality is commonly referred to as "Instant Messaging" (IM) .This document describes the syntax and semantics Of the MSN Messenger Protocol, The Communication Protocol Running Between Msn Messenger Service 1.0 Clients and Servers. Among The Core Services That The Msn Messenger Servers Provide To Clients Are:
- Authenticated user logon -. Adding and deleting members of the user's contact list -. Changing the user's on-line state -. Receipt of asynchronous, real-time, on-line state change notifications from members of the user's contact list -. Delivering lightweight, real-time messages to other users -. Receipt of asynchronous, real-time messages from other users -. Configuring the user's access permissions, to restrict the ability of other users to view the user's on-line state or send messages to the User.
Additional Background:
1. Some features extraneous to core instant messaging functionality contained within the MSN Messenger Service 1.0 protocol are beyond the scope of this document. Examples include client version management and directory functionality.
2. The purpose of this document is to provide the members of the IMPP working group with a reference implementation of a "monolithic" IM system. That is, a system designed for massive scale, but not yet capable of communication with servers other than those associated with this specific service. Since any standard in this area will of necessity be a "distributed" design that explicitly enables server- to-server and service-to-service communication, this document will serve primarily as a reference and example of one implementer's Choices at Scale.Movva and Lai Category - Informational 2
MSN Messenger Service 1.0 Protocol Aug - 99
3. This document reflects the protocol used in the 1.0 release of MSN Messenger clients and servers, deployed on the Internet in July of 1999. However, the service is in production and rapidly growing, which almost certainly will necessitate changes to the protocol as Microsoft .
4. MSN Messenger Server Component Overview
MSN Messenger Service clients make connections to several different kinds of servers They are separate components to facilitate running at scale -. Each component can be duplicated an arbitrary number of times, independently of each other, to enable large numbers of users.
4.1 Dispatch Server (DS)
The Dispatch Server is the initial point of connection between client and server. Its primary functions are protocol version negotiation, determination of which Notification Server (NS) is associated with the client making a connection (via an algorithm of the server's choosing), and referring The Client To The Proper NS.4.2 Notification Server (NS)
The Notification Server is the primary server component. The client and the Notification Server authenticate, synchronize user properties, and exchange asynchronous event notifications. The client's connection to the Notification Server occurs after the referral from the Dispatch Server is completed, and persists without interruption during The User's MSN Messenger Service Session.
Some of the events transmitted between a client and a Notification Server are: State changes (eg client is on-line, client is offline, client is idle), Switchboard Server invitation requests (see below), and application-specific notifications that are beyond (EG New E-mail Has arrived)
4.3 SwitchBoard Server (SS)
The Switchboard Server is the component through which clients can establish lightweight communication sessions without requiring a direct network connection between clients. The common usage of the Switchboard Server is to provide instant messaging sessions. When a client wishes to communicate with another client, it sends a Message to ITS Notification Server, Which Then Refers The Client To A Switchboard Server. Once The Ss Connection Is Established, The "Destination" Client Receives a Notification from Its NS to Connect To The Same Ss.
Movva and Lai Category - INFORMATIONAL 3MSN Messenger Service 1.0 Protocol Aug - 99
5. Protocol Conventions
5.1 Connection Type
The MSN Messenger Protocol currently works over TCP / IP. The MSN Messenger server components support connections over port numbers 1863, which is the registered port number assigned by the IANA (http://www.isi.edu/in-notes/iana/ Assignments / Port-Numbers.
5.2 CommanD Syntax
MSN Messenger Protocol command syntax is ASCII and single line- based. Commands begin with a case-sensitive, three-letter command type, followed by zero or more parameters, and terminated by CRLF. Parameters are separated by one or more whitespace characters and can not contain whitespace characters. Parameters that contain spaces or extended (non 7-bit ASCII) characters should be encoded using URL-style encoding (eg "% 20" for space). Some commands accept un- encoded binary data. In these cases, the LENGTH OF THE DATA IS Transmitted As Part of The Command, And The Data IS Transmitted Immediately Following a CRLF of the Command.
5.3 Asynchronous Requests
Commands issued from the client to the server that result in a reply are known as requests. Requests are entirely asynchronous. The client can submit several requests in sequence without waiting for the server response after submitting each request. The server is required to deliver a response or an error for each request received, but it is not required to deliver the responses in the same order as the requests were received. The client can determine the request associated with a particular response by examining the Transaction ID parameter (described below).
5.4 User Handles
MSN Messenger Protocol uses User Handles for identifying users. A user handle (also known as "account name" and "logon name") is a text representation of the user's identity that is both unique and persistent. The user handle is syntactically equivalent to an e-mail address, and as such is subject to the same restrictions for character set, as described in RFC-822. Most notable among these restrictions are the limitation to Latin alphanumeric characters and a few symbols. The maximum acceptable length of the user handle is 129 bytes.Implementation note: In the initial release of the client and server, user handles are Hotmail account names All user handles must contain the "@ hotmail.com" domain name, and user handles that do not contain a domain name are. NOT VALID.
5.5 Custom User Names
Movva and Lai Category - Informational 4
MSN Messenger Service 1.0 Protocol Aug - 99
A custom user name (also known as "custom name" and "friendly name") is a user's representation of the "friendly" textual name associated with a user handle. (Eg "Auntie Em" instead of em123@hotmail.com). Custom user names are neither unique nor persistent, and can contain any valid Unicode characters. Custom user names are represented in UTF-8 as described in RFC-2044 and URL-encoded as described in RFC- 1738 when transmitted between the client and server. The Maximum Acceptable Length of the Encode Custom User Name IMPLEMENTATION.
5.6 Transaction Identifiers
The Transaction Identifier (aka Transaction ID) is a numeric string representing a number between 0 and.. (2 ^ 32 - 1) It is a value that a client includes with any command that it issues to the server In the current version of the protocol, the transaction identifier is used to associate server responses with client-issued commands. The server treats the transaction ID as an opaque number and does not assume any relationship between successive TransactionIDs or any particular starting Transaction ID. It is the client's responsibility to guarantee the uniqueness of the Transaction IDs for the purpose of disambiguating the commands and / or responses. (A future version of the protocol could enable the client to track the status or cancel a particular transaction using the transaction ID.)
When the server sends the response to a command to the client, it must include in the response the transaction ID that the client sent to the server when the client originally issued the command. In cases where a server sends a command to a client that requires a transaction ID but is not in response to a specific client command, it will use 0 as the transaction ID. in cases where a server sends multiple responses to a single client request, the server will use the same transaction ID in each response.
5.7 User List Types
Some of the protocol commists area.ed to the manipulate lists of users. The Following Types of User Lists Aresu Supported by The Protocol:
Forward List (FL) - The List of Users for Whom A Given User Wants To Receive State Change Notifications. The Forward List is what is most user's "Contact List."
Reverse List (RL) - The list of users who have registered an interest in seeing this user's state change notifications.Allow List (AL) - The list of users who the user has explicitly allowed to see state change notifications and establish client-to- Client sessions via a switchboard server.
Movva and Lai Category - Informational 5
MSN Messenger Service 1.0 Protocol Aug - 99
Block List (BL) - The List of Users WHO The User Has Explicitly Prevented from Seeing State Change Notifieds and Establishing Client-to-Client Sessions Via A Switchboard Server.
6. Command Summary Table
Command from to description ====================================================== ==================== Ack Switchboard Client sends a posital. -------------------- ---------------------------------------------- ADD Client Notification Adds to the User's FL, Al, Notification Client and BL. Notifies The Client of Asynchronous Additions to a User's List. ------------------------------------------------------------------------------------------------ ----------------------------------------- Ans Client Switchboard ACCEPTS A Request for A Switchboard Server session. ----------------------------------- -------------------- BLP Client Notification Changes The User '
Signing, WHICH DETERMINESHOTS -------------------------------------------------------------------- ---------------------------------------- BYE SWITCHBOARD Client Notifies a Client That A User IS No longer in the session. -------------------------------------------- ---------------------- Cal Client Switchboard Initiates A Switchboard Server Session. ------------------ ------------------------------------------------ CHG Client Notification Sends a Client State Change Notification Client To The Server. Echoes The Success of Client's State Change Request. --------------------------------- ---------------------- Fln Notification Client Notifies The Client When Uses in The Fl Go Off- Line. ------------ -------------------------------------------------- ----- GTC Client Notification Changes The User '
Sprmpt Notification Client Setting, Which Determines How The Client Reacts To Certain rl changes. --------------------------------- --------------------------------- Inf Client Dispatch, Requests Set of Support Notification Authentication Protocol Dispatch, Client from THE Server. NOTIFICATION Provides The Set ofmovva and Lai Category - InformationAl 6
MSN Messenger Service 1.0 Protocol Aug - 99
Supported Authentication Protocols to The Client. ------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------ ILN Notification Client Notifies The Client of The Initial Online State of A User In The Fl, While Either Logging On OR Add a User To the fl. -------------------------------------------------------------------------------- --------------------- Iro Switchboard Client Provides The Initial Roster Information for New Users Joining The Session. ---------------- -------------------------------------------------- --- Joi Switchboard Client Notifies a Client That A User is now in the session. ------------------ -------------------------------------------------- - LST Client Notification Retrieves The Server's Notification Client Version of The User '
S FL, RL, Al, OR BL. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------- Msg Client Switchboard Sends a message to the members of the current session. --------- -------------------------------------------------- -------- MSG Notification, Client Delivers a Message from a Server-Side Component. ----------------------- ------------------------------------------- Nak Switchboard Client Sends a negative Message Delivery Acknowledge. ------------------------------------------------------------------------------------------------------------ --------------------- NLN Notification Client Notifies The Client When Uses in The Fl Go ON-L ine or when their on-line state changes. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------- -------------------------------------------------- ---- Rem Client Notification Removes from The User's FL, Notification Client Al, And Bl. Notifies The Client of Asynchronous Removals from a user '
S List. ------------------------------------------------ -------------------- RNG NOTIFICATION Client Notifies The Client of a Request by Another Client To Establish A Session Via A Switchboard Server. --------- -------------------------------------------------- -------- Syn Client Notification Initiate Property Synchronization. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------- Movva and Lai Category - Informational 7
MSN Messenger Service 1.0 Protocol Aug - 99
USR All Authenticates Client with Server, Possibly in Multiple Passes. -------------------------------------- ---------------------------- Ver Client Dispatch Negotiate Dialect Between Client and Server. ------- -------------------------------------------------- --------- XFR Client Notification Requests A Switchboard Notification Client Server for Use in Establishing a session. ------------------------- ----------------------------------------- XFR Dispatch Client Notification of Login-NS To Notification Client The Client or Notification To Move To A Different NS. ========= ============================================================================================================================================================================================================= ============ 7. Presence and State Protocol Details
This Is A Detailed List of Protocol Commands Associated with Presence FunctionAns Associated by Clients. Commands Associated With Instant Messages Are Discussed In Section 8 Below.
7.1 Protocol Versioning
After the client connects to a dispatch server by opening a TCP socket to port 1863, the client and server agree on a particular protocol version before they proceed The Client-Server protocol version handshake involves the following command exchange:. C: VER TrID dialect- Name {Dialect-name ...} S: Ver Trid Dialect-Name
The Client CAN Provide Multiple Dialect Names in Preferred Order. The Diact-name Parameter Returned by The Server Is The Version Server Is Designating for this connection
The Current Protocol Diagect-name supported by Messenger Servers is "MSNP2". The Diact Names Are Not Case-Sensitive.
The string "0" is a reserved Diagect Name and is buy to indeicate a failure response. E.g .:
S: Ver Trid 0 {DIALECT-NAME ...}
7.2 Server Policy Information
The Client Next Queries The Server for Variable "Policy" Information. In this version of the protocol, the only policy
Movva and Lai Category - Informational 8
MSN Messenger Service 1.0 Protocol Aug - 99
Information returned by the server is the authentication package in us.
C: INF TRID S: INF TRID SP {, sp ...}
SP Identifies A Security Package - The name of the sasl mechanism to use for authentication. "MD5" is buy by the notification server, "cki" by the switchboard server.
7.3 Authentication
The Client Needs to Authenticate Itself After Protocol Version Handshake and Identifying The Security Packages Supported on The Server. The Following Are The Client Server Interacts Involved.
C: USR TrID SP I {AuthInitiateInfo} S: USR TrID SP S {AuthChallengeInfo} C: USR TrID SP S {AuthResponseInfo} S: USR TrID OK UserHandle FriendlyNameThe SP parameter is the name of the security package ( "MD5") The. next parameter is a sequence value, which must be I to (I) nitiate the authentication process and S for all (S) ubsequent messages. If authentication fails on the server, the client can start the authentication process again.
For the MD5 security package: -.. The AuthInitiateInfo parameter provided by the client must be the User handle - The AuthChallengeInfo parameter returned by the server contains a challenge string - The AuthResponseInfo contains the binary response as a hexadecimal string, which the MD5 hash of The Challenge and The User Password Strings Concatenated Together.
The Final Response from the Server Contains, In Addition To The User Handle, The Current "Friendly Name" Associated with the user handle. This is a "custom user name" as described Above.
7.4 REFERRAL
There Are Three Cases in Which Clients Are Referred from One Server To Another:
1. The initial "Dispatch Server" refers the client to the Notification Server to which it is assigned. 2. Asynchronous referral by the Notification Server to reassign the client to a different Notification Server if that server is overloaded or undergoing maintenance. 3. During Switchboard Session Establishment, The Assigned Notification Server Refers The Client To A Particular Switchboard Server for Use. This is discussed BELOW.
Movva and Lai Category - Informational 9
MSN Messenger Service 1.0 Protocol Aug - 99In the current implementation the Dispatch Server uses the user handle provided in the initial USR command above to assign the user in question to a Notification Server Alternate implementations might not require referral at this stage..
If Received, Referral is of the form:
S: XFR Trid REFERTYPE Address [: portno]
. ReferralType is either "NS" or "SB" and defines the type of referral to a Notification Server or Switchboard Server Address is a valid DNS name or IP address to a referred server, with optional port # suffixed as ": PortNo".
IF this Command is Received from The Server, The Client Should Attempt To Log in To The Server Provided.
In The Case of "NS" Referrars During Logon, The Server Automatically Closes The Client Connection After Sending This Xfr Response So That The Client Can Connect To The New IP Address.
IF Sent Asynchronously, The Client Is Responsible for Closing The Connection.
After A "NS" Referral, The Client Will NOT Receive Any More Messages from the "OLD" NS, And Also Must Not send any commands to the "old" ns after receiving an xfr.
7.5 Client User Property Synchronization
Several of The User Properties Used by the Messenger Application Are Stored on The Server. This is Done for Two Reasons:
1) So that users can "roam", ie log in from different locations and still have the appropriate data, such as their contact lists and privacy settings. 2) If changes occur to a user's Reverse List while that user was offline (the user WAS Added to another user's list, The Client Can Be Updated with this information.
For performance reasons it is useful to cache these properties on the client, so that bandwidth usage is minimized in the typical case where the user is not roaming and there were no Reverse List changes.These requirements are met by the SYN command - synchronization.
Once a client logs in successfully, it uses the SYN command to ensure it has the latest version of the server-stored properties These properties include:. Forward List, Reverse List, Block List, Allow List, GTC setting (privacy setting when someone adds This user to their forward list), and BLP Setting (The User's Privacy Mode).
Movva and Lai Category - Informational 10
MSN Messenger Service 1.0 Protocol Aug - 99
The Syn Command IS:
C: SYN Trid Ser # S: SYN TRID SER #
The Ser # parameter sent by the client is the version of the properties currently cached on the client. The server responds with the current server version of the properties. If the server has a newer version, the server will immediately follow the SYN reply by updating the client with the latest version of the user properties. These updates are done as described below, and are done without the client explicitly initiating a LST, GTC or BLP command. Note that the server will update all server-stored properties to the client, Regardless of how much entries have call.
The following "List Retrieval and Property Management" section describes the format of the user properties sent by the server After the SYN reply from the server, the user property updates will be sent from the server in this sequence:. GTC, BLP, LST FL LST Al, LST BL, LST RL.
All the user protection updates will share the same trid as the syn command and reply.7.6 list retrieval and proteys management
Synchronizing can result in a batch of user properties and lists getting sent by the server to the client. However, the client application can also initiate a request to retrieve the server- stored lists and properties. The following are the privacy property and list retrieval commands ..................... ..
List Command
By Issuing The Lst Command, The Client CAN Explicitly Request That A List Be Sent. The Server Will Respond with a Series of Lst Response for Each Item in The Requested List.
C: LST Trid List S: Lst Trid List Ser # item # TTLITEMS UserHandle CustomUsername
- List is Fl / RL / Al / Bl for Forward List, Reverse List, Allow List, And Block List, Respectiveness. - The item # parameter Contains The index of the item sets The index of the item design. (EG ITEM 1 of N, 2 of N, ETC.) - The TTLITEMS Parameter Contains The Total Number of items in this list. - UserHandle Is The User Handle for this List item. - CustomUserName Is The Friendly Name for this List item.
Movva and Lai Category - INFORMATIONAL 11
MSN Messenger Service 1.0 Protocol Aug - 99
IF The List is Empty, The Response Will BE:
S: LST Trid List Ser # 0 0
Reverse List Prompting
The Client Can change Its Persistent Setting for When to Prompt The User In Rection To An Reverse List Change. This is Accomplished Via The GTC Command:
C: GTC Trid [A | N] S: GTC Trid Ser # [A | N]
The Value of the A / N Parameter Determines How The Client Should Behave When It Discovers That A User IN ITS RL, But IS Not in Its Al or Bl. (Note That This Occurs When A User's List, But Has Not Been Explicitly ALLOWED or Blocked: a - prompt the user as to whather the new user in the rl shop be added to the al or the bl n - automatically address the new user in the rl to the al
The A / N Parameter Is Not Interpreted by The Server, Merely Stored.
The server will respond with the current setting if the change was successful. Otherwise, it will return an error with the matching TrID. If the client tries to change the setting to the same value as the current setting, the server will respond with an error Message.
The default setting is a will.
Privacy mode
The Client Can Change How The Server Handles Instant Messages from Users Via the BLP Command:
C: BLP Trid [Al | BL] S: BLP Trid Ser # [Al | BL]
The AL / BL parameter determines how the server should treat messages (MSG and RNG) from users. If the current setting is AL, messages from users who are not in BL will be delivered. If the current setting is BL, only messages from people Who is in the al will be delivered.
The server will respond with the current setting if the change was successful. Otherwise, it will return an error with the matching TrID. If the client tries to change the setting to the same value as the current setting, the server will respond with an error Message.
Movva and Lai Category - Informational 12
MSN Messenger Service 1.0 Protocol Aug - 99
The default setting is al when a new user connects to the server for the first time.7.7 client stats
After the client is automated and synchronized, the client establishes it................................................. ..
C: Chg Trid State S: Chg Trid State
WHEN The State Is Changed, The Server Will Echo The Settings Back to Client. The State Shall Not Be Considered Changed Until The Response Is Received from The Server.
Note That The Server CAN Send A State Change Message To The Client At Any Time. If The Server Changes The State WITHOUT A Request from The Client, The Trid Parameter Will BE 0.
States Are Denoted by a string of three character: The predefined stats:
NLN - Make the client Online (after logging in) and send and receive notifications about buddies FLN -.. Make the client Offline If the client is already online, offline notifications will be sent to users on the RL No message activity is allowed.. In this state, the client can only synchronize the lists as described above HDN -.. Make the client Hidden / Invisible If the client is already online, offline notifications will be sent to users on the RL The client will appear as Offline to others. But Can Receive Online / Offline Notifications from Other Users, And Can Also Synchronize The Lists. Clients Cannot Receive Any Instant Messages In this state.
All Other States of NLN (ONLINE). The Other States Currently Supported Are: Bsy - Busy. IDL - iDLE. BRB - BE Right Back. Awy - Away from Computer. PHN - On The Phone. LUN - Out to Lunch.
7.8 List Modifications
The protocol supports generic commands to add and remove users from various lists. This is used by clients to enable "Adding" contacts to the list of folks being watched, or for the "Block" and "Allow" features that define how users chooses to Interact with one annother.movva and lai category - InformationAl 13
MSN Messenger Service 1.0 Protocol Aug - 99
However, these generic commands have different semantics based on the list being modified For example, only the server can add or remove entries from the Reverse List -. Since it is an indirect consequence of the user having been added to another user's Forward List.
The Add and Remmists:
C: add trid list Userhandle CustomUsername S: Add Trid List Ser # UserHandle Customusername
C: Rem Trid List UserHandle S: Rem Trid List Ser # userHandle
Valid Values for List in Client Initiated Adds and Removes Are Fl / Al / BL.
All Client Initiated Adds And Removes Will Be Echoed by The Server With New Serial Number That Should Be Persisted by The Client Along With The List Modification. IF NOT SUCCESSFUL, An Error Will Result.
The protocol also supports the concept of an ADD or REM that the client did not initiate. Server generated ADDs and REMs can have LIST values of FL / AL / BL / RL. This is common with RL changes, which are never initiated by the client .......................... ..
Asynchronous ADDs and REMs to the FL, AL, and BL can happen when the server allows an authenticated user to make list changes from another environment, such as a web site. In all of these cases, the server will send the ADD or REM command With the Trid Parameter Equal to 0.7.9 Notification Messages
The Client Receives Asynchronous Notifications WHENEVER A Contact On The User's Forward List Changes Its State. The Notifications Aref:
S: NLN Substate UserHandle FriendlyName S: ILN Trid Substate UserHandle FriendlyName S: Fln UserHandle
NLN Indicates That A User Has Come Online. - Substate Can Be Any Three-Letter Code (See "Client State" Above). - UserHandle and FriendlyName Are The Handle and Names Associated with the user coming online.
Iln is similar to the nln message, and is recection from the server in response to an chg or add command from the client:
Movva and Lai Category - Informational 14
MSN Messenger Service 1.0 Protocol Aug - 99
1. Immediately after the client logon and sends its first CHG command to the NS In this case several ILNs may be received -.. One for each Forward List contact that is currently online 2. After the client sends an "ADD TrID FL UserHandle CustomUserName "to the ns" (EG ILN for the New Contact if That Contact Is Currently Online)
In Both Cases, Trid in the '' s..............
Fln Means That The Specified User is now Offline.
7.10 Connection Close
The Client Issues The Following Command To Logoff from The NS:
C: Out S: Out {statuscode}
The server will reply with an OUT to the client before it initiates a disconnect, with an optional StatusCode.The StatusCode can be "OTH", which indicates that a client with the same user handle and password has logged on to the server from another location OR "SSD" Meaning The Server IS Being Shut Down for Maintenance.
The Server Will Drop The Connection After Sending The OUT.
7.11 ERROR INFORMATION
Error Messages from the Server Are Of The Format:
S: Eee {Trid} {(Error-Info) {param ...}}
eee is a 3 digit decimal number indicating the error code. Error- info contains the description of the error in a text string localized to the server's locale. The optional parameters provide indication of the client command causing the error. TrID is the Transaction ID of The Client Command That Caused This Error. Any Server Generated Errors Will Not Have Transaction IDS.
ERR_SYNTAX_ERROR 200 ERR_INVALID_PARAMETER 201 ERR_INVALID_USER 205 ERR_FQDN_MISSING 206 ERR_ALREADY_LOGIN 207 ERR_INVALID_USERNAME 208 ERR_INVALID_FRIENDLY_NAME 209 ERR_LIST_FULL 210 ERR_ALREADY_THERE 215
Movva and Lai Category - Informational 15
MSN Messenger Service 1.0 Protocol Aug - 99
ERR_NOT_ON_LIST 216 ERR_AALREADY_IN_THE_MODE 218 err_already_in_opposite_list 219 err_switchboard_failed 280 err_notify_xfr_failed 281
ERR_REQUIRED_FIELDS_MISSING 300 ERR_NOT_LOGGED_IN 302 ERR_INTERNAL_SERVER 500 ERR_DB_SERVER 501 ERR_FILE_OPERATION 510 ERR_MEMORY_ALLOC 520 ERR_SERVER_BUSY 600 ERR_SERVER_UNAVAILABLE 601 ERR_PEER_NS_DOWN 602 ERR_DB_CONNECT 603 ERR_SERVER_GOING_DOWN 604 ERR_CREATE_CONNECTION 707 ERR_BLOCKING_WRITE 711 ERR_SESSION_OVERLOAD 712 ERR_USER_TOO_ACTIVE 713 ERR_TOO_MANY_SESSIONS 714 ERR_NOT_EXPECTED 715 ERR_BAD_FRIEND_FILE 717 ERR_AUTHENTICATION_FAILED 911 ERR_NOT_ALLOWED_WHEN_OFFLINE 913 ERR_NOT_ACCEPTING_NE W_USERS 9208. Session based instant messaging protocol details
MSN Messenger Service utilizes a lightweight, session-based messaging scheme. In order for two clients to exchange instant messages, they must first establish a common session via a Switchboard Server. They can invite additional clients to join the established session.
8.1 Referral To Switchboard
This Process Begins with a "Calling" Client Requesting a Referral from ITS Notification Server to A Switchboard Server:
C: XFR Trid SB S: XFR Trid SB Address SP AuthchallengeInfo
- SB is the type of referral being requested or granted -. Address is the DNS name or IP address of a Switchboard Server that has been assigned, and that the client should connect to -. SP is the Security Package being used In this version. Of the protocol it is "cki" Only. - Authchallengeinfo is a cookie That The Client Needs to present to the switchboard server for authentication.movva and lai category - InformationAl 16
MSN Messenger Service 1.0 Protocol Aug - 99
8.2 Switchboard Connections and Authentication
After the XFR reply is received, the client makes a TCP / IP connection to the Switchboard server using port 1863. Note that a lack of version negotiation in the switchboard connection is a limitation of the current implementation.
The Client First Needs to Authenticates with The Switchboard Server:
C: USR Trid UserHandle AuthResponseinfo S: USR Trid Ok UserHandle FriendlyName
- AuthResponseInfo is the cookie for CKI security package returned by the Notification Server in the XFR -. UserHandle and FriendlyName are the Switchboard's echoes of the user handle and friendly name of the user.
8.3 Inviting Uses to a Switchboard Session
Any User In A Switchboard Session CAN Invite Other Users to join the session. The Cal Command is SENT To The Switchboard Server for this purpose:
C: Cal Trid UserHandle S: Cal Trid Status SessionID
The Messenger servers verify that the calling user has permissions to contact the called user, with consideration given to the called user's privacy settings and its online state. If instant messaging with this user is not allowed, the server responds to the calling user with an error . If it is allowed, the Switchboard server causes a RNG command to be sent to the called client (see below), and returns a CAL echo to the calling client The CAL echo has these parameters: -. Status is a predefined status code - In this Implementation IT Must Be "Ringing". - sessionid is the ascii representation of a Decimal Number That Unique Identifies this session on the switchboard server.
8.4 Getting Invited to A Switchboard Session
The other side of the session establishment is the behavior of the called client. The called client receives a RNG from its Notification Server and is expected to connect to the Switchboard Server and respond with an ANS.
The Cliant Receives A RNG from The Notification Server As Follows:
S: RNG Sessionid SwitchboardServeraddRess SP AuthchallengeInfo CallinguserHandle CallingUserfriendlyname
- sessionid is a nameic ascii session ID.
Movva and Lai Category - Informational 17
MSN Messenger Service 1.0 Protocol Aug - 99
- SwitchboardServerAddress is a DNS name or IP Address - SP is the security package in use In this implementation only "CKI" is supported -.. AuthChallengeInfo is the cookie to be passed back to the switchboard to gain entrance to the session -. CallingUserHandle is . - CALLINGUSERFRIENDLYNAME IS The Custom User Name of the Caller.
To join the session, the called client connects to the Switchboard Server and carries out the following exchange to join the session: C: ANS TrID LocalUserHandle AuthResponseInfo SessionID S: IRO TrID Participant # TotalParticipants UserHandle FriendlyName S: ANS TrID OK
The IRO commands relay to the newly joined client roster information about the current session Each IRO command message from the Switchboard contains one participant in the session -.. Participant # contains the index of the participant described in this IRO command (eg 1 of N, 2 of n). - TotalParticipants Contains The Total Number of Participants Currently in The session.
....................... ...CRIPLILE, TEACE.
If no one is in the session when the user joins (an unexpected error condition), the server skips directly to "ANS TrID OK" command. All the responses from the server related to the issued ANS command will contain the same TrID as the original Client Ans Request.
8.5 session participant changes
WHEN A New User Join Switchboard Session, The Server Sends The Following Command To All Participating Clients, Including The Client Joining The Session:
S: Joi CalleeUserHandle CalleUserfriendlyName
- CalleeUserHandle Is The User Handle of The New Particles. - CalleeUserFriendlyname is The customer name of the new participant.
IF a client's connection with the switchboard server is droping for Any Reason, The Server Sends The Following Command To The Remaining Clients in The session:
S: Bye CalleeuserHandle
- CalleeUserHandle Is The User Handle of the Participant That Left The session.movva and Lai Category - InformationAl 18
MSN Messenger Service 1.0 Protocol Aug - 99
Privacy Note: If the client moved a contact to the BL while Switchboard sessions are active, it is the client's responsibility to leave any session that should now be blocked The servers only enforce privacy permissions when inviting users to a session Further, the servers.. only enforce privacy permission with respect to the calling user, and not the other participants in a Switchboard session. Therefore, in a multipoint session, it is possible for a user to participate in a session with someone whom he has blocked, if a third party Is Performing the invitation.
8.6 Leaving A Switchboard Session
WHEN a Client Wishes To Disconnect from The session, IT Sends The Following Command and Waits for the Switchboard To Close The Connection:
C: OUT
8.7 Instant Messages
Sending an instant message
Once a Client-to-Client Session Has Been Established Via the Switchboard Server, Sending An Instant Message to the Participants of The Session IS DONE As Follows:
C: MSG Trid [U | N | a] Length / R / NMESSAGE S: NAK TRID S: ACK TRID
U, N, and A correspond to the three delivery acknowledgement modes:. Unacknowledged, Negative-Acknowledgement-Only, and Acknowledgement Depending on the value of this parameter, either nothing, NAK, or ACK will be sent back by the Switchboard Server to the CLIENT.
For unacknowledged mode, The Switchboard Server Does NOT RESPOND To The Sending Client with The Success OR Failure Of Message Delivery.
For Negative-Acknowledgement-Only mode, the Switchboard Server responds to the send client only if the message could not be delivered to the recipient client.Acknowledgement mode is not currently implemented.
LENGTH is The Length of The Message Parameter in bytes, Whereas Message Is The Actual Message As Described Below.
8.8 Receiving an Instant Message
A Client Can Receive A System-Generated Message from the Notification Server, or it can received an instant message from
Movva and Lai Category - Informational 19
MSN Messenger Service 1.0 Protocol Aug - 99
Another Client Via A Switchboard Server. The Message IS Received in The Following Format:
S: MSG UserHandle FriendlyName Length / R / NMessage
............. ..
Message is a mime encoded stream, using a standard mime header as defined by RFC-1521 and RFC-822.
Message is constructed as:
MIME-HEADER / R / NMIME-HEADER / R / N / R / NMESSAGEDATA
MIME-HEADER IS Constructed AS:
String ":" String (E.G. "Content-Type: Text / Plain")
The Content-Type Mime Headers That The Current Client Will Use and Recognize Are:
"Text / Plain; Charset = UTF-8" "Text / Plain"
IF "charset = UTF-8" APPEARS AT THE End of The Content-Type, The Message Data IS UTF-8 Encoded.
NOTE: The Switchboard Server Does Not Interpret The Contents of the Message.
9. Author's Addresses
Ramu Movva Microsoft Corporation One Microsoft Way Redmond Wa 98052 Ramum@microsoft.com
William Lai Microsoft Corporation One Microsoft Way Redmond, Wa 98052 WLAI@microsoft.com
