Re: ircd i18n, suggested protocol extension

[Per von Zweigbergk <cannon@xxxxxxxxx>]

On Wed, Nov 15, 2000 at 02:32:10PM +0100, Kurt Roeckx wrote:
> Sending a ping before the client is connected is a violation of
> the RFC.  It can easely break a client.

True, but now, being a practical type person, many IRC server
software, like that of Undernet already does send a PING before
connected. This IMHO is a great thing protecting against floodbots
from borken FTP servers or any other exploits that require a client
only being able to write on a socket. So, IRC clients in use now
support PING before connect.

> There just isn't any "clean" way of doing it that I can think of.
> The best thing so far is that a client sends some command to the
> server before it registers.  But then you can have the client
> waiting for the answer of the server, before it continue's, if
> the server doesn't know about it.

That's why I proposed sending it just before a PING command. Here
are some examples. C is client, S is server.

C: USER jdoe host host :John Doe
C: NICK DowJohn
S: LANG         /* This could be some numeric. Might be better. */
S: PING :somerandomnumber

Here the server waits for a PONG.

IRC clients would generally just ignore the LANG request, which could
be a numeric, and instead just respond to the PING.

But an extended IRC client would recognise the LANG request and
respond to it, and because it programmatically came before the PING
request, it won't be properly connected yes, so no Non-english text
will have had the chance to send any non-english text yet.

Then, the IRC client, regardless of whether it is an extended client
or not would just respond to the PONG.

If the LANG was not received by the server, then it would just default
to English.

Oh, also. Without checking the RFC right now, does it actually
prohibit a PING command in the handshaking sequence before the MOTD?

> For numeric reply's, we can probably support all possible
> language.  But don't expect us to allow all possible nicknames
> for instance.  We can't change much about how the protocol is
> defined.

No, I never said that we should allow foreign nicknames. Some IRC
servers allow long nick names, but that technically breaks the RFC
and even some current IRC clients that truncate the nicknames.

A side note:

Ironically though, the reason for }, {, and \ to be the lowercase
variants of ], [ and | is because of IRC's Finnish origin.

In the dark ages of 7-bit SE-ASCII, }{\][| corresponded to åäöÅÄÖ.
These letters were used in the Finnish and Swedish language.


* end of personal reply, starting general comments added on *

I received some constructive comments from pht on #c on IRCnet, pointing
out that the IRC server isn't the right place to i18nize. He pointed
out that the IRC protocol is defined as a numeric, some arguments, and
then some explanatory "garbage" text. This text is just there to speed
up the development of "half-baked" IRC clients.

I reply that that most modern IRC clients are half-baked in that aspect. I
see this as a good thing. Centralising i18n is always a good thing.

He always pointed out that menus and so and such don't get translated
with this approach. This is true, but likewise, if I translate IRC client
menu's, the responses won't change either.

He then argues that the IRC client writer should handle the numerics
and translate them himself. This is a good point, but with the
impurities in the IRC protocol, with that particular numeric which
could mean four(!) different things depending on what network you're
on, it would be too fragile. And then every IRC client writer would
have to duplicate those particular efforts. That isn't good either.
Lots of wasted time that could be better used.

-- 
Per von Zweigbergk <pvz@xxxxxxxx>
IRC: pv2b (IRCNet or QuakeNet)

War does not determine who's right, war determines who's left.