Message intents about ircv3-specifications HOT 3 CLOSED

Why exactly should, 10 years from now, we be compatible with clients from 1992? To this extent, I think that a transition period is appropriate.

from ircv3-specifications.

The SMTP spec says that 7-bit char is the standard. Yes there is 8BITMIME but you'd do well to assume it works with 8-bit chars, because many SMTP just work with 8-bit char these days and do not even support 7-bit char crud, attitude being "anyone who still uses those machines should have upgraded 15 years ago."

Find me a 7-bit char machine and I'll find you a piece of junk that you should take to the trash.

Likewise, if and when the tags spec is adopted, find me a client in 10, 15 years that still only supports CTCP, and I'll show you a client that should belong in the trash too.

Supporting obsolete warts and misfeatures for the sake of backwards compatibility for all of eternity is not workable. It encourages people to do the wrong thing and to never adopt the standard.

Reference: http://www.catb.org/jargon/html/F/flag-day.html

from ircv3-specifications.

May I just add that if you really want your retrocomputing fix, and you want to chat with people using ircII 2.8.12 on Red Hat Linux 5.0, you can always write yourself a small proxy that does the translations and connect using that. This is how people use ancient browsers on the modern Internet (see jwz's HTTP 1.0 proxy Perl script), and it would be trivial to write something similar for IRC 2<->3.

The protocol itself should always have forward momentum, and trying to support old clients full of misfeatures and security holes for the sake of "compatibility" will do nothing but hold back necessary improvements.

from ircv3-specifications.