View Issue Details

IDProjectCategoryView StatusLast Update
0003724unrealircdpublic2013-05-07 07:33
ReporterMagicalTuxAssigned Tonenolod 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
Platformamd64OSLinuxOS Version2.6.26
Product Version3.2.7 
Target VersionFixed in Version3.4-alpha1 
Summary0003724: MOTD line width limited to 80 bytes
DescriptionAn text file limited to 80 char width is something you would expect from most files, however with the growing use of UTF-8 and other languages, we have some problems here because of the 80 bytes per line limit.

For example a line written in Japanese on an UTF-8 server will require 3 bytes per char, which means we can only 26 chars per line.

Worst case if you want to add colors/bold to make things visible (still, those are not part of the standard, just widely supported client-side addons, so I won't speak about this here).

RFC 2812 asks for a MOTD to be "with each line no longer than 80 characters", this doesn't mean "80 bytes", which can be interpreted as "you can add stuff like bold, it'll be more than 80 bytes, but at least it will be 80 characters long".

I guess most clients (if not all) do support receiving MOTD message with lines containing more than 80 bytes of data, and changing this in UnrealIRCd isn't really a big deal (changes in read_file_ex).
I changed it to 255 (+1 for line break) in order to support Japanese (maximum line width in bytes is 240 bytes for a 80 chars line), however this means I could be a bad admin and break the RFC by creating a bogus MOTD.

I'll just post it here as an idea, it all depends on how you interpret RFC (I guess the RFC writers didn't expect to see IRC networks using multibytes charsets)

Quoting RFC 2812 about charset:

   No specific character set is specified. The protocol is based on a
   set of codes which are composed of eight (8) bits, making up an
   octet. Each message may be composed of any number of these octets;
   however, some octet values are used for control codes, which act as
   message delimiters.

   Regardless of being an 8-bit protocol, the delimiters and keywords
   are such that protocol is mostly usable from US-ASCII terminal and a
   telnet connection.

So:
 * Using UTF-8 is not forbidden by RFC 2812
 * In UTF-8, a character may be 1 byte, and up to 6 bytes (may be extended to 8 at some point)
 * RFC2812 says a MOTD line must not be over 80 "characters"

This lead me to think that with the growing usage of UTF-8, a MOTD line should not be limited to 80 bytes. There are more and more people using UTF-8 on IRC. This doesn't thange anything for people in USA or other English-speaking countries, however for people in other countries (Japan, France, Russia, etc) this means you can't put 80 chars in a MOTD.
TagsNo tags attached.
3rd party modules

Activities

Stealth

2008-08-27 16:13

reporter   ~0015383

Last I checked, we are not 2812 compliant, just 1459

MagicalTux

2008-09-05 09:18

reporter   ~0015400

I checked RFC 1459. It says about charset :

   No specific character set is specified. The protocol is based on a a
   set of codes which are composed of eight (8) bits, making up an
   octet. Each message may be composed of any number of these octets;
   however, some octet values are used for control codes which act as
   message delimiters.

   Regardless of being an 8-bit protocol, the delimiters and keywords
   are such that protocol is mostly usable from USASCII terminal and a
   telnet connection.

About MOTD :

 - When responding to the MOTD message and the MOTD file
   is found, the file is displayed line by line, with
   each line no longer than 80 characters, using
   RPL_MOTD format replies. These should be surrounded
   by a RPL_MOTDSTART (before the RPL_MOTDs) and an
   RPL_ENDOFMOTD (after).

The problem is exactly the same.

nenolod

2013-05-07 07:33

reporter   ~0017530

http://hg.unrealircd.org/hg/unreal/rev/3e63a457fa18

Issue History

Date Modified Username Field Change
2008-08-27 04:17 MagicalTux New Issue
2008-08-27 16:13 Stealth Note Added: 0015383
2008-09-05 09:18 MagicalTux Note Added: 0015400
2013-05-07 07:33 nenolod Note Added: 0017530
2013-05-07 07:33 nenolod Status new => resolved
2013-05-07 07:33 nenolod Fixed in Version => 3.4-alpha1
2013-05-07 07:33 nenolod Resolution open => fixed
2013-05-07 07:33 nenolod Assigned To => nenolod