On Tue, Oct 20, 2009 at 5:09 AM, Trevor Talbot <quension@mac.com> wrote:
long as it's online. This is a pretty fundamental assumption that makes everything from pretty client displays to access lists and scripting work.
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.
Another property is that hosts have a hierarchy, where certain parts may change for dynamically-assigned addresses while other parts remain static based on ISP or geographical location; this of course is what makes wildcard masks in access lists etc work.
Sometimes they have a hierarchy, sometimes they do not. In some cases, IRCD may actually be working against IRC users, when it resolves IP addresses into a less useful form like abc12345.ipt.aol.com E.g. Sometimes the IPs might actually have a hierarchy that is distorted or lost when the resolved name is shown, for example, if a /19 of addresses is designated for each region. 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.
any time. This breaks the assumption above and affects things as basic as automatic line breaks in channel or private message text. (A client that knows its own host length can calculate the maximum length of message text it can send before one server along the chain will truncate it, and can do its own line splitting to compensate.)
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. The truncation is basically an existing flaw in the protocol. It rarely comes into play, as legitimate messages rarely come close to the limit. 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> It is not within the IRC protocol that a user needs to know its mask. However... it is possible to always show the client its true hostname (even when masked), or a 'padded' version designed to be longer than the masked version of their hostname, so as to satisfy any automatic line breaking procedure.
The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session.
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 -- -J