ircv3 / ircv3-specifications

IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
http://ircv3.net/
776 stars 78 forks source link

Message intents #24

Closed HelixSpiral closed 10 years ago

HelixSpiral commented 10 years ago

During the transition period, the IRC server SHOULD perform this translation until a point in time is reached where translation is no longer necessary.

I felt the need to point out that this should state it MUST perform this translation. not SHOULD perform it. Also IRCv3 should NOT be changing the way things currently work. This will break older clients years down the road.

It's entirely fine to create opt-in things to do stuff differently, but there should be no 'transition period' moving from the old way to the new way. The old way must always work.

kaniini commented 10 years ago

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.

Elizafox commented 10 years ago

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

awilfox commented 10 years ago

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.