[Konversation-devel] [Bug 130588] New: Ambiguous meaning of 320 numerical causing erroneous WHOIS display

[Eike Hein]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=130588         
           Summary: Ambiguous meaning of 320 numerical causing erroneous
                    WHOIS display
           Product: konversation
           Version: unspecified
          Platform: unspecified
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: konversation-devel kde org
        ReportedBy: sho eikehein com


Version:           SVN (using KDE KDE 3.5.3)
Installed from:    000

The meaning of the 320 protocol numerical is ambiguous, which can cause erroneous WHOIS data to be displayed to users. At least one server (Dancer, Freenode network) uses it to indicate whether a user has identified with services, while at least one other server (UnrealIRCD) uses it to indicate a "Secure Connection" (most likely SSL).

Example Dancer RAW log:
:kornbluth.freenode.net 320 Sho_ Hurga :is identified to services

Example UnrealIRCD RAW log:
:panther.furnet.org 320 Hurga Hurga :is a Secure Connection


It should be noted that UnrealIRCD uses the 307 numerical to indicate whether a user has identified for the nick they're using (note the semantic difference between this and Dancer's 320). Example RAW log:
:panther.furnet.org 307 Hurga Hurga :is a registered nick


The numerical catalogue website http://www.alien.net.au/irc/irc2numerics.html calls the 307 numerical "RPL_WHOISREGNICK", consistent with the UnrealIRC RAW log. The 320 numerical is known as "RPL_WHOISSPECIAL", with the meaning of special left undefined.


We have the following options going forward:

(a) Stop trying to make IRC nice for non-English speakers and merely display what the server sends us instead of using our own messages. This appears to be X-Chat's solution. 

(b) Decide to only support one of the competing meanings.

(c) Toggle between two translatable messages based on keywords in the server message, relying on the stability of their strings.

(d) Considering our history of special exceptions for UnrealIRCD, attempt to find reliable ways to tell whether we're on UnrealIRCD and switch into a special mode from thereon, to display the appropriate message.


All of these options are undesirable, but such is the life of an IRC client developer. (c) would be the quick and ugly fix, (d) the more elaborate and clean one - but (d) would also represent the epic decision to give in and recognize IRC as a fragmented protocol in the source base.