200 character channel name limit

[Joan Sarah Touzet]

One thing that is always forgotten about in these discussions is DBCS
(Double Byte Character Set) and CJKV (Chinese Japanese Korean and
Vietnamese) text processing.  For people in these languages, the RFC
means they effectively have 4-character nicknames and 100-character
topics.  These are somewhat reasonable defaults, though one might argue
that 15-character nicknames (c.f. NICKLEN=30) are more worldly.  If we
EFIGS users (English, French, Italian, German and Spanish) get twice as
many characters out of the effort, that's not such a bad thing.  

Remember that IRC started as a global effort; just because EFNet now
doesn't have a lot of CJKV users doesn't mean that ircd-hybrid's
defaults shouldn't be reasonable for all languages, based on the
original RFC.

I argue that IRC still exists not because it's the perfect solution, but
because the RFC is still being followed.  If you want to deviate to some
other standard, go right ahead -- we fully support you with
configure-time options.  If you want to try and get a new RFC out there,
then you can try to build some cross-network agreements.  I will support
your efforts to get more communication in the IRC administration
community, and participate in them, but I cannot lead such efforts at
this time.  Be forewarned that this is a /lot/ of work.

-Joan

P.S.  You'll also start hearing this argument soon: storage and
bandwidth are far cheaper now than it was in 1989, so arguing on that
stance alone doesn't hold much water.


Thus spake Rachel Llorenna (rachies at gmail.com):
> You're absolutely right. So, why doesn't ircd-hybrid adopt
> 30-character NICKLENs by default? You could argue, I suppose, that
> it'd be breaking RFC's, but limits are a bad thing, according to your
> argument. However, when you propose that there should be "no such
> limitations imposed on the individuals of a network" on an ideal
> network, you also note that there need to be some sort of limits,
> since you specify that they must be "within reason."
> 
> Obviously, since you and I are different people, "withtin reason"
> means a completely differen t thing. As I mentioned, my opinion is
> that a 200-character limit is too high and therefore unreasonable, but
> you suggest that it is indeed within reason.
> 
> But of course, who needs nicknames at all, when a sufficiently
> sophisticated client could simply convert between account id's and
> user-friendly names for the user, removing the need for nicknames
> completely. In fact, I believe Dianora is working on a proposal for
> such an implementation. I really don't think it'd be that great to
> have virtually unlimited values for everything: look at all the people
> on DALnet with really_long_annoying_nicknames, etc.
> 
> And as mentioned, it does make a database technician's work slightly
> more difficult.
> 
> 
> On Sun, 6 Mar 2005 01:47:06 -0500 (EST), Paul-Andrew Joseph Miseiko
> <esoteric at teardrop.ca> wrote:
> > Based on that logic we might as well limit those 255 character file names
> > to 63 because only a few people actually use legitimate file names of said
> > length and we prefer to be selfishly restrictive based our own ideals.
> > 
> > Alas the world does not revolve around a single individual and
> > specifications define a set of requirements to hopefully satisfy a range
> > of individuals.  The argument "there is no need to support ridiculous
> > values" is highly relative.
> > 
> > In an ideal world there would be no such limitations imposed on the
> > individuals of a network, within reason.  The definition would be highly
> > dynamic.  The problem with such configurations is that assigning dynamic
> > memory is an annoying efficiency issue to programmers.
> > 
> > As for the jab at the 512 character limit imposed by the RFC, I personally
> > don't see people typing over 100 character lines on a consistent basis,
> > and even then most *good* IRC clients (like Icarus) are intelligent enough
> > to break up the line into sections according to the RFC imposed limit not
> > impacting the user at all.
> > 
> > --
> > ln -s /etc/passwd ~/.core; ping localhost &; killall -11 ping
> > --
> > Paul-Andrew Joseph Miseiko
> > 
> > On Sat, 5 Mar 2005, Rachel Llorenna wrote:
> > 
> > > While I fully understand that we would want to follow traditions and
> > > RFC specifications as much as possible, I'm not sure it's terribly
> > > useful to have such a high limit, when few people actually
> > > legitimately use channels of that length. It certainly makes making a
> > > MySQL table that much more difficult, since it has to be a (huge)
> > > VARCHAR column.
> > >
> > > It only has its minor bit of geek appeal and nothing more; I'm sure
> > > even Wohali wouldn't be using that channel for normal
> > > conversation/etc, although I do not know that for a fact. After all,
> > > would it not effectively reduce the length of messages, as per the 512
> > > character limit imposed by RFC 1459?
> > >
> > > It's as scary and useless as having excessively long (30 characters?!
> > > *pokes Unreal IRCd/Bahamut*) nicknames, though I suppose it doesn't
> > > affect ircd developers.
> > >
> > >
> > > On Sat, 5 Mar 2005 16:37:18 -0500, Joan Sarah Touzet <joant at ieee.org> wrote:
> > >> Hi Rachel,
> > >>
> > >> I think the answer is "tradition."  There's no specifically good reason,
> > >> and if you prefer a different limit on your network, then go for it.
> > >>
> > >> EFNet presently has a 200 character limit; do a /whois Wohali to see a
> > >> channel that makes use of all 200 characters.
> > >>
> > >> -Joan
> > >>
> > >> Thus spake Rachel Llorenna (rachies at gmail.com):
> > >>> Why exactly did the developers feel it necessary to set the channel
> > >>> name length limit to 200 characters, when realistically, few people
> > >>> exceed 20 characters for channel names (and that's being generous)?
> > >>> --
> > >>> Regards,
> > >>>
> > >>> Rachel Llorenna (frequency)
> > >>
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rachel Llorenna (frequency)
> > >
> > >
> > 
> > 
> 
> 
> -- 
> Regards,
> 
> Rachel Llorenna (frequency)