Valhalla Legends Forums Archive | MSN Client/Bot Development | Proposal: Standard client name/feature identification message

SkywingThis is also posted on's MSN Messenger Protocol Discussion Forum.

Many clients support extended features such as encryption.  I'd like to make it easier for clients to identify themselves and what kinds of features they support, beyond just a User-Agent field in every message (which is both a waste of bandwidth and doesn't provide any information about client capabilities).

I propose defining a new Content-Type for this purpose: text/x-clientcaps.  This message would be sent whenever a) joining a conversion, or b) seeing another client join the current conversation.

In particular, clients would be able to exchange their name and version information with this, but more importantly, they would be able to signal compliance with extensions.  This would allow clients to know whether somebody else they're chatting with is compatible with certain extensions without having to know about the specific names and versions of clients which support it.

Some features which might benefit from this:

- Encryption, obviously.  Clients could tell right away whether they're able to establish secure communication with eachother, perhaps even exchanging public keys ahead of time.
- Logging-aware clients.  Some people have voiced concerns about clients which log chat.  This would enable "nice" clients to give fair warning to others that the conversation is being logged.
- File transfer "in the other direction".  For instance, somebody behind a poorly configured NAT might not be able to listen on any ports, so they could arrange for all file transfers to start with the other party listening.

Why text/x-msmsgsinvite isn't suitable for these kinds of things:
Capabilities information would need to be re-sent every time somebody new joined the conversation.
Traditionally, the invitation command has been reserved for interactions started by the user.  As such, many clients provide a notification whenever any kind of invitation is displayed, even if it's not supported.  We don't want to annoy users on legacy clients by having lots of "a request to start an application which was not recognized was declined" type messages appear every time somebody joins the conversation.

Currently defined attributes/fields for x-clientcaps:
I need some input as to what features people are going to be supporting, so post away with respect to this.
- Client-Name: Client-Name-String/Client-Version-Major.Client-Version-Minor.  For instance, Client-Name: BinaryChat/1.00.
- Chat-Logging: Logging-Option.  Y- Nonsecure logging is enabled, S- Secure (log is encrypted or something of this sort) logging is enabled, N - The conversation is not being logged by this client.

Clients which support this message:
I'm already going forward and implementing this with my own client, so that it'll be able to intelligently know when it can use extensions without annoying users on other clients.  However, it'd be nice if other clients supported this.  Presently, nobody has yet signed on, and I've just put this idea forth.
- BinaryChat (Skywing's MSN client).
April 13, 2003, 03:27 PM
TheMinisteredSounds like a good proposal, all you need to do is get a couple clients to support it.  Then perhaps, people like  Olivier Goffart might decide to join in and support you.April 19, 2003, 03:45 PM
SphtMy messenger client, Cat, supports this now.October 23, 2003, 09:03 PM
AdronComment on this...

Microsofts client supports automatic logging and file transfer in the "other" direction. So, the only thing this message can currently indicate is the version of the software on the other end, and if it doesn't support logging. In the absence of this message you have to assume that logging is supported, to a secure or nonsecure storage depending on configuration, and that reverse connections through nat are supported.

October 25, 2003, 06:47 AM
SphtHow about a File-Transfer: Transfer-Option attribute/field (feel free to suggest a different attribute/field name)? For instance, File-Transfer: Y if client supports file transfer and File-Transfer: N if not. Or is there already a way of finding this out in advanced?October 25, 2003, 09:34 PM
UndeferenceRFC Editor
If you want to propose a new MIME type, you have to specify it as a standard to be accepted by the Internet Society.
August 09, 2004, 07:06 AM
SPY-3any chance i can get the source code for connecting to msn? April 16, 2005, 04:17 AM
WarriorNo.April 16, 2005, 08:00 AM
Joe[x86]Well, isn't writing these clients against MS's copywrite of the protocol? If so, I think drawing attention to ourselves by doing this isn't too bright. If not, I support this.April 17, 2005, 06:04 PM
BlazeThey released there draft protocol to the public, it doesn't sound like they are fighting people making clients.April 17, 2005, 06:05 PM
Joe[x86]Oh, awesome.April 17, 2005, 07:05 PM
Mesiah / haiseMDoes MSN Messenger use UTF-8 specific settings, or any likewise features? If not, I think it would be worth throwing in a capability block... Your idea is a good one and pretty simple to understand, I'd say stretch the limits to show how many more features are possible to other developers...December 24, 2005, 01:21 PM
Joe[x86]That's what I love about programming. If you can imagine it, you can do it.December 29, 2005, 07:55 AM
Mesiah / haiseMThat's right baby Smiley Thats what got me so into programming. I was first introducted to bots a while ago, then moved onto hex editing. Then my friend showed me how he made a trojan in vb so easily, and it was then i realized it's potential. Any amazing program I've ever used, I've always said... Wow if only i could do this... I could make it do this, and that, it would be so much better if it did this.. And the idea's just never stopped coming. Its a good feeling to think something up and persue it.December 29, 2005, 03:35 PM
Joe[x86]And thus object-oriented programming was born! Hello world!December 29, 2005, 09:45 PM