Bug 109750

Summary: Annoying behavior of special characters in nicknames
Product: [Applications] konversation Reporter: Fedot Praslov <fedot.p>
Component: generalAssignee: Konversation Developers <konversation-devel>
Status: RESOLVED INTENTIONAL    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:

Description Fedot Praslov 2005-07-28 08:00:08 UTC
Version:           0.18 #3016 (using KDE 3.4.1, Arch Linux)
Compiler:          gcc version 3.4.3
OS:                Linux (i686) release 2.6.10-ARCH

Using of special character 0x000A (maybe isn't single character with trouble) in nickname produce crazy thing. When user with nickname containing this character send message in a channel, "private messages" from that user appear to the active tab, doesn't matter which tab it was (private dialog with another user or other channel).

More, adding this user to ignore list doesn't help much, still these messages appears.

The messages looks like this:
[22:42] [•] v!akrav@85.65.168.237 PRIVMSG #rusisrael ...
[22:55] [williamsia!pm1@192.117.97.99] PRIVMSG #rusisrael asd
Comment 1 Ismail Donmez 2005-07-28 08:10:27 UTC
This is some patched russian irc server I guess? I would like to know the server details if its not private.
Comment 2 Fedot Praslov 2005-07-28 08:31:00 UTC
Yes, it's ircd-RU!(Bahamut-1.4.35)-1.0(07)-02). What the details do you want to know?
Comment 3 Ismail Donmez 2005-07-28 09:10:16 UTC
Ok I will look into this.
Comment 4 argonel 2005-07-29 17:20:31 UTC
Sorry, but this is not something we can nor should fix. 0x000A is a linefeed, and has been used in this role since at least 1963. Please see RFC#20, dated October 16,1969, page 7. <http://www.ietf.org/rfc/rfc20.txt>

Unix-style operating systems (now including MacOs) use LF as the primary message seperator. This practise is still valid with Unicode. Since there are *lots* of available characters in Unicode, there is no need to redefine the use of 0x000A. 

Please also note that both RFC1459 and RFC2812 reserve the use of LF as a message terminator. Any IRCD that does accept only CR (or indeed only LF) for message termination is tolerant, not normative.

I suggest that you file a bug report with those that have modified the behavior of the IRCD.