Starting with MSNP8, a new value is included with ILN, NLN, and CHG messages. We still don't understand some of the exact details about this value, but it seems to be some kind of client ID structure. This page documents what we know so far and some of the theories that have been rejected. The main discussion of this topic is going on in thread 5153.
Note: Understanding the client ID structure requires some knowledge of binary. Since this structure is still somewhat under active research, the binary and hexadecimal representation is discussed in places. If you just want to implement the thing, skip the discussion.
Here is an example MSNP8 NLN message:
NLN 96 NLN example@passport.com example%20friendlyname 268435492
Here, "268435492" is the client ID structure. Although it is transmitted as a single decimal number, it represents a structure made up of four sections. Each section is one byte in length, so you can't make them out by looking at the decimal number. If you convert the number to hexadecimal, the sections are much easier to spot - for example, "268435492" is "0x10000024" in hexadecimal. The values of the sections are "0x10", "0x00", "0x00", and "0x24" respectively.
The first section is believed to represent the client version, the next two sections seem to be reserved for future use, and the final section advertises some of the capabilities of the client.
The value of this byte is hardcoded into the official client, and seems to be increased in every version of MSN Messenger, but not in Windows Messenger. Our working hypothesis is that this is some kind of client version information, from which clients can deduce things like the type of file transfer the client supports.
You can extract the client version from the client ID by "modulo dividing" the client ID number by 16777216 (that is, dividing it then throwing away the remainder). Here is a list of client versions we've observed (the numbers in brackets are the version numbers in hexadecimal):
Every single bit in this section has its own meaning - in other words, this section is a "bitfield". Unlike the client version section, the value of this section can change whenever the client sends a new status message - for example, the official client may advertise support for video conversations whenever a webcam is plugged into the machine it's on.
You can extract individual capabilities from the client ID by bitwise ANDing the client ID with the value of the capability. If the result is zero, the client doesn't support the capability at present, otherwise the client does support the capability. Here is a list of capabilities, and what we know about them (the numbers in brackets are the version numbers in hexadecimal):
"Ink" is a technology from Microsoft that allows you to handwrite on a screen. It's available in tablet PCs, recent versions of Microsoft's Platform SDK, and in Microsoft's next version of Windows code-named "Longhorn".
A developer who worked on putting ink functionality into MSN Messenger has a page talking about his work.
Nothing in this structure represents the native language of the MSN Messenger client, the OS version or the native OS language.
Installing Messenger Plus does not alter the structure in any way.
Build numbers of clients (e.g. the 0602 in version 6.0.0602) are not represented.
Enabling emoticons, custom emoticons, "show my display picture", and "show display picture from others in instant message conversations" have no effect on the bitmask.
Enabling the auto-idle and auto-busy features has no effect.
P2P support isn't directly represented. The official client uses the version number to guess at whether P2P file transfer is supported, but not whether other P2p things like custom emoticons are supported.