Dear MeiR_ct,

Originally Posted By: MeiR_ct
1. Clients are supposed to conform with servers, and not the other way around.


Prove it. IRC Servers have often conformed to clients, and IRC clients have often conformed to servers. Some servers explicitly disallow certain control codes in user information or channel names ever since colors were introduced *by IRC clients*. Other protocols have had similar push-and-pull (ever used HTTP recently? A lot of it was redefined by defacto usage) and server developers chose the pragmatic approach of implementing support for clients on many occasions. The world is not black and white, and IRCd developers should not choose this, of all fights, to harp on that argument.

Originally Posted By: MeiR_ct
2. mIRC is very popular without doubt, but it is not the only client there is.


You're right. This is why the change was made. Name another client that exclusively uses codepages? I know of none. mIRC added UTF-8 compatibility years ago specifically to be more compatible with Unicode clients, not less. 7.x is the same story. If anything, the only client mIRC is breaking compatibility with... is mIRC. The vast majority of the clients still using codepages are mIRC 6.x clients. Do you have data that offers different statistics?

Originally Posted By: MeiR_ct
I really welcome your step, but unfortunately it came too early.


It came as a surprise, but it certainly did not come "early". Unicode has been the standard encoding on the internet for many years now. Practically speaking, it's been *the* way to communicate on the web for at least the last 6. How are you qualifying "early"? When should codepage support be dropped? Note that this contradicts a claim you made below that "IRC commands should be sent in codepages."-- if you believe that statement, then Unicode should never come at all-- if this is your actual opinion, I don't think we're going to get anywhere.

Originally Posted By: MeiR_ct
About servers:
IRCds don't have (and probably will never have) UTF support for nicknames and channel names, or config directives.


A few IRC servers already do (I can name RusNet, off-hand). Although this already disproves your claim outright, let me elaborate: there is no reason why they can't. It's technically possible, and in fact solves the problem much more effectively than clients can, since servers can keep track of each user's codepages (and per channel) with server commands, they can also keep track of transcoding these encodings for clients so that the clients don't need to support any encoding besides their local one. This is something the client cannot do unless servers exposed a command to query the remote encoding for a specific user-- much more complicated (and still requires servers to do extra book-keeping anyway). Therefore implementing server-side encoding awareness to me seems like the ideal solution, something IRCd developers should start contemplating. Again, some already have. Therefore, it's possible, it's better, and there's no real reason why not, besides developer laziness, FUD, delegating responsibility ("the client should do it!") and crap about the RFC not explicitly saying it. Do you have an explicit reason why this is not possible?

Originally Posted By: MeiR_ct
Bottom line: IRC commands should be sent in codepages.


Says who? Are you the IRC god? IRC commands can (and are) sent in whatever encoding you want. How the data is interpreted is application defined-- in this case the IRCd can choose to handle it or not. Note that this is interpretation is as-per spec, if you're using one of the literalists using the RFC as your bible.

Originally Posted By: MeiR_ct
About clients:


You've made a lot of false claims about clients here, let's look at them:

Originally Posted By: MeiR_ct
It will take a lot of time and work for developers of other clients to catch up with mIRC


Every popular IRC client I know of already has UTF-8 support. More clients use UTF-8 now than codepages, if we're talking about this on a per-client basis (not usage per client). Every OSX client has zero codepage support, because OSX has zero codepage support (everything is Unicode). Every Java IRC client should also have builtin Unicode support, since Unicode is the standard encoding there too. Every popular Linux client I know of uses the system locale to get encoding support, which includes UTF-8. We've already discussed every IRC client for 2 operating systems and one entire language. It's safe to say that mIRC is the one catching up, not the other way around.

Originally Posted By: MeiR_ct
More than that, there're still considerable clients which don't have UTF support at all. That mainly includes bots (PHP\perl\etc.),


Bots, for the most part, don't need unicode support. They perform actions on set commands, which are (again for the most part) made up of purely ASCII characters. More importantly, those clients need to be updated anyway. Just as you argue that mIRC should support ENCODING XYZ where XYZ is a codepage, these bots should support ENCODING XYZ where XYZ is UTF-8.

Originally Posted By: MeiR_ct
browser-based clients (PJIRC, flash clients) or built-in client windows inside other applications (like SMIRC in eMule).


As I mentioned, Java uses Unicode, Flash probably uses the same. These clients should have no problem. Browser based (CGI/AJAX) clients are even easier, because UTF-8 is *THE* standard for web communication. PJIRC supports utf-8, and has for the last 6 years at least, so I don't know where you got this factoid from.

Originally Posted By: MeiR_ct
So even if we demand from users to switch to Unicode, some of them just won't be able, and obviously, no one can force the whole world to use mIRC.


Similarly, you can't force mIRC to support archaic encodings. This is a silly argument. Software moves forwards, not backwards. Nobody is forcing mIRC to be used, and I've mentioned a boatload of clients that support UTF-8 as well as, if not better than, mIRC. Use one of those, if you're having problems communicating with others on IRC. If not, this is a non-issue.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"