On Oct 20, 2009, at 6:31 AM, James Hess wrote:
Mask "staticness" is not really a valid assumption within the scope of the IRC protocol, and not required for ChanServ access lists or scripting to work, with proper awareness of whatever masking scheme. Client A cannot ever actually be sure Client B's address won't change even in the absence of masking (Client B could reconnect at any time unbeknownst to client A).. hence every message in the IRC protocol contains a nick!user@host prefix when delivered to other IRC users.
The reason a full prefix is delivered is to allow stateless clients to function; it enabled /ignore, predates SILENCE, and provides some identification information in the absence of channel context. The assumed immutability of a client's host during a session can be seen historically in channel interactions (notably joins and bans) and options like the host target of a PRIVMSG. The assumption has been continued since then with things like clients caching hosts within a channel context, and servers providing extensions like UHNAMES to assist them. It isn't required for all things to "work", but it is an assumption that has been encoded into the behavior of both servers and clients from the beginning. I have yet to see anyone make an argument for why trying to change that is desirable; it just seems to be a side effect of the way hostmasking and internal vhosts were first done that people have mostly put up with despite the problems.
In fact, IRCD does not provide adequate banning tools for this scenario, you cannot ban a /19, a /20, or even a /22 from a channel with a single ban.
I do consider CIDR masks to be a desired feature when real hosts are used; some networks have implemented it.
Auto line breaks are not really that basic... most clients don't split messages in a way the user did not, and most clients simply limit message length at a point.
I suppose I should have said "simple" instead, but it's not *that* rare. A few clients have it built-in, and there are scripts available for some others.
Clients aren't actually required to be told their own hostname, at any point during registration with an IRC server. The only way a client can possibly know its own address is if it asks for it, with a command such as /USERHOST <itsownnickname>
Yes, or a WHOIS on itself, or by messaging itself. Many clients do all of the above and anything else they can think of in order to work around DCC+NAT+masking problems.
It is not within the IRC protocol that a user needs to know its mask.
It is desired by modern stateful clients, though.
Forcing mask status to be fixed upon connect (unless forcing all users to use masking), is a bit troublesome.
The main problem is IRC clients don't provide a way for the user to interact with the server in a general way _until_ the registration with IRC is done.
It's not really possible to simply add an option to the USER line for "request masking", and have it actually be usable by IRC users
A good point. -- Quension