356683 - client should not assume long nickname support when trying to automatically change nicknames.

Status: RESOLVED WONTFIX

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Stephanie Daugherty [:sdaugherty]]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.7) Gecko/20060830 Firefox/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.7) Gecko/20060830 Firefox/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2)

The RFC1459 limit on nickname length is 9 characters. While most IRCDs can support more, or can be configured to support more, it should never be assumed that they do. When automatically changing nickname at connect, due to the configured primary and alternate names being taken, the client keeps appending a _ suffix to the nickname, which, on a network with a low nickname length limit, will never result in a valid name.

 

Reproducible: Always

Steps to Reproduce:
1. Attempt to connect a network with your primary and alternate nickname already in use, and set to nicknames that are at the supported limit for that network.
2. Client repeatedly attempts to change nicks by appending _ suffixes until eventually disconnected by the server.


Actual Results:  
See above.

Expected Results:  
Client should have used an algorithm for determining an alternate nickname that is  less likely to exceed server limits, or should consult per-server configuration data for the network's limitations.

Comment 1

[:Gijs (he/him)]

Could you please:
* give an example of a public irc server running software that doesn't support this
* give an example of an algorithm which might be used instead of appending underscores

I don't think you can actually ask a server about its nick length limits (typically sent in a 005 reply) before you're logged on, so asking about capabilities wouldn't be an option.

Comment 2

[James Ross]

One (lame) IRC client I've seen rotated the characters, so:
  123456789
became:
  912345678

I think that sucks. If we do this, it should be something a little more sane, like prefixing "_" instead of suffixing them IMO.

Comment 3

[:Gijs (he/him)]

How does prefixing help? The length will still increase, right?

Comment 4

[James Ross]

If we know the limit, we can prefix and cut, if we don't know the limit we are screwed /whatever/ we do.

Comment 5

[Stephanie Daugherty [:sdaugherty]]

9 characters is still the limit for EFnet, and I think IRCNet and (possibly) Undernet as well. Newer networks and smaller networks are more likely to have longer limits, but 9 characters is what RFC1459 specifies, so it's the least common denominator...

Comment 6

[Stephanie Daugherty [:sdaugherty]]

just checked undernet, seems to limit to 12 characters.

Comment 7

[Stephanie Daugherty [:sdaugherty]]

and IRCnet's at 15 now. That leaves efnet as the only major network still at 9, probably a few smaller ones that still observe that limit also.

Comment 8

[:Gijs (he/him)]

OK, but is there any way to tell this limit before successfully connecting (which, afaik, means it accepted your nickname) and getting the 005 message?

If there isn't, I'd really prefer this bug to be wontfixed, because it seems rather silly to try to limit *all* nicknames to 9 characters, when most networks accept more.

Comment 9

[Stephanie Daugherty [:sdaugherty]]

    (In reply to comment #1 and  #8)
    > * give an example of an algorithm which might be used instead of appending
    > underscores

    For the first 5 iterations, assume NICKLEN is equal to the larger of 9 characters or the desired nickname.

    After 5 iterations, assume NICKLEN is equal to 9 (worst case), and begin trying truncated versions of the nickname.

    Each of these methods cam be tried, iterating though each method a maximum of 5 times.

    1) Each iteration, suffix _ if possible, adding one _ at a time until the assumed NICKLEN is reached. Once NICKLEN is reached, make no further attempts with this method.

    2 )Each iteration after suffixing fails, repeat the same method with _ as a prefix. (Starting from the original nick)

    3) Remove one vowel at a time from the nick until no vowels remain or the nick would be less than 4 characters long.

    4) Iterate through varients of the original nick (truncated to 9 characters if more than 5 total alternatives have been tried), replacing one character with _, and rotating through the nickname each iteration, (ie, foo, fo_, f_o, _oo) 

    5) Iterate through varients of the original nick, rotated by one letter each time.

    6) attempt random 9 character alphanumeric nicknames, starting with a letter.


    I doubt that all these methods would need to be employed, but having at least 2 of them, one of which is random, would increase the chances of a sucessful connection without human intervention.

As far as needing to limit all nicknames to 9 characters, we shouldn't have to. Assume it's at least as long as the chosen nickname and/or alternate nickname, but after X tries, attempt to truncate it to 9 in case the client's connecting to a network with a smaller limit.

Comment 10

[James Ross]

(In reply to comment #9)
> 3) Remove one vowel at a time from the nick until no vowels remain or the
> nick would be less than 4 characters long.

This one, at least, would not be internationally suitable.

I think after N (5 by default?) attempts at suffixing "_", the only choice is to try removing a single character from the end of the nick each iteration (possibly keeping a single "_" suffixed for this).

I'm tending towards the option to give up, and just leave the "Nickname not acceptable; use /nick to try another" message on screen and wait. Sometimes it just doesn't make sense to try and force our way through unknown limitations.

Comment 11

[:Gijs (he/him)]

Bug's valid in any case, even though I don't have a lot of clues on how to solve it.

Comment 12

[Mitchell Field [:Mitch]]

The patch checked-in for bug 428811 limits the number of retries, and displays the "nick in use, pick a new one" message after the limit has been hit. It's been said before that there is no way to simply check the nickname character limit for a particular server, before the user is logged-on, so should this be considered WONTFIX?

Comment 13

[:Gijs (he/him)]

(In reply to comment #12)
> The patch checked-in for bug 428811 limits the number of retries, and displays
> the "nick in use, pick a new one" message after the limit has been hit. It's
> been said before that there is no way to simply check the nickname character
> limit for a particular server, before the user is logged-on, so should this be
> considered WONTFIX?
> 

Yeah, I think so, actually. The limit is 3 by default if you don't have a nick list, I think - which would be fine, IMHO. Silver?

Comment 14

[James Ross]

Yeah, fine. CANTFIXSENSIBLY.