Difference between revisions of "Protocols/MSNP/Messages"

From NINA Wiki
Jump to navigation Jump to search
m (1 revision imported)
Line 1: Line 1:
 +
{{Protocols/MSNP}}
 +
 
= Messages =
 
= Messages =
 
The client receives MSG commands from NS and SB. This is a payload command, and the payload itself has a formatting. This formatting is explained throughout this Wiki, but the information is not up-to-date and easily found. Therefore I thought I should make this page :) It's far from complete; I'm hoping someone else will add to this page.
 
The client receives MSG commands from NS and SB. This is a payload command, and the payload itself has a formatting. This formatting is explained throughout this Wiki, but the information is not up-to-date and easily found. Therefore I thought I should make this page :) It's far from complete; I'm hoping someone else will add to this page.

Revision as of 13:58, 15 May 2022

MSNP Protocol
IntroductionTermsClients
Reference
Error ListCommandsRelying Party SuiteSpotlife
Services
XMPPHTTP GatewayTabsActivities
Documentation
Development ToolsMSNP Grid
PolygamyURLs used by MSN
Documents
Protocol Versions
Version 21
Version 18
Version 16
Version 15
Version 14
Version 13
Version 12
Version 11
Version 9
Version 8
Version 2
MSNC
IntroductionP2PObject DescriptorDisplay PicturesFile Transfer
Scenarios
Microsoft Messenger for Mac
MSNP on WebTV (MSNTV)

Messages

The client receives MSG commands from NS and SB. This is a payload command, and the payload itself has a formatting. This formatting is explained throughout this Wiki, but the information is not up-to-date and easily found. Therefore I thought I should make this page :) It's far from complete; I'm hoping someone else will add to this page.

Only the payload of MSG messages is discussed here. For the format of the MSG command itself you should check the relevant page.

Generic

Every MSG payload appears like this:

<header1>: <param1>
<header2>: <param2>
...
<body>

So every message has a header and a body. The two are separated by an empty line (a line with only \r\n). Headers have the format:

NAME: VALUE

So the name and value are separated by a double-colon and a space.

Messages can have various headers, but two are always included:

MIME-Version: 1.0
Content-Type: <content-type>

The MIME-Version is always 1.0. The Content-Type is the way by which you can differentiate the type of message.

Messages sent by the Notification Server

Profile message

This message is sent by the NS after it has sent the SBS command. Its Content-Type header is:

Content-Type: text/x-msmsgsprofile; charset=UTF-8

It has a large number of headers and no body. Consult the page Protocols/MSNP/MSNP8/Messages#Profile_Messages for further information.

Initial Mail Data message

NOTE: In which version of the protocol did it appear?

This message is sent by the NS after the client has sent the ADL command, the last (?) command in the logon sequence. Its Content-Type header is:

Content-Type: text/x-msmsgsinitialmdatanotification; charset=UTF-8

Messages sent by the Switchboard

Typing message

This message is sent when a buddy is typing a message. MSNP clients can give their user a notification about this, so that they see that a new chat message is due. The message has three headers in total, and no body. Its Content-Type header is:

Content-Type: text/x-msmsgscontrol

The interesting header is TypingUser, it's value is the passport of the user that is typing a message.

Note that clients can choose whether to notify buddies that they are typing a message. Also, when a buddy types an initial message, no switchboard connection is already set up, and the TypingMessage will not be sent.

Example

MIME-Version: 1.0
Content-Type: text/x-msmsgscontrol
TypingUser: typingbuddy@hotmail.com

Text message

This message is sent when a buddy sends you a chat message. It's the Raison d'Etre for MSNP to exist ;)

Its Content-Type header is:

Content-Type: text/plain; charset=UTF-8

The body of the message is the message itself. The header X-MMS-IM-Format specifies the layout of the message. It has several name/value pairs, in the format:

P1=VALUE; P2=VALUE; P3=VALUE

(The name is always two-characters, the value url encoded, the pairs separated by semi-colon and space, no trailing semi-colon.)

Currently, only FN, EF and CO are known.

FN

Specifies the font name. Values observed are:

Andale Mono, Arial, Arial Black, Bitstream Charter, Charter, Century Schoolbook L, Clean, ClearlyU, ClearlyU Alternate Glyphs, ClearlyU PUA, Comic Sans MS, Courier, Courier 10 Pitch, Courier New, DejaVu Sans Ultra-Light, DejaVu Sans Mono, DejaVu Serif Semi-Condensed, Dingbats, Fixed, Georgia, Helvetica, Impact Condensed, Lucida, Lucida Bright, Lucida Sans Ultra-Light Oblique, LucidaTypewriter, Monospace, New Century Schoolbook, Newspaper, Nimbus Mono L, Nimbus Roman No9 L, Nimbus Sans L Condensed, Sans, Serif, Standard Symbols L, Terminal, Times, Times New Roman, Trebuchet MS, URW Bookman L, URW Chancery L Italic, URW Gothic L, URW Palladio L, Verdana, Webdings.

EF

Extra font styling. Text can be bold, italiced, underlined, or strike-trough. EF=B means only bold. EF=BIUS means bold, italic, underline, strike-trough. The order (B, I, U, S) matters!!

CO

The font color. It is hexadecimal, in the format BBGGRR (so RGB encoded, but the red, green and blue are reversed).

Example

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
User-Agent: pidgin/2.3.1
X-MMS-IM-Format: FN=MS%20Sans%20Serif; EF=; CO=0; PF=0; RL=0
This is a message

Client capabilities message

This message is sent once for every buddy that is connected to the switchboard, and it defines the capabilities of the client. Its Content-Type header is:

Content-Type: text/x-clientcaps

Currently, only two headers are observed. The Client-Name header says what client the buddy is running. Chat-Logging is unknown but probably indicates whether the client is logging this chat.

Example

MIME-Version: 1.0
Content-Type: text/x-clientcaps
Client-Name: Purple/2.3.1
Chat-Logging: Y