Well, I wasn't trying to recommend the exact ports I stated, that was more of a recommendation than an actual port number proposal. As far as port number concerns go, we'd have the standard listening range, two for hostmasking (With/without SSL), and then two for oper hostmasking (With/without SSL). So with hostmasking on a port plus SSL, we'd be adding three new port requirements for the full feature spread, instead of a straight doubling across the board. Three additional ports for a new world of flexibility while connecting isn't that bad, and makes implementation easier and probably less prone to bugs.
On Wed, Oct 21, 2009 at 7:30 PM, James Hess <mysidia@gmail.com> wrote:
On Wed, Oct 21, 2009 at 6:07 PM, Vin King <vin.king@gmail.com> wrote:
> They want hostmasking? Connect on 6667
> They don't? Connect on 7000
It seems a reasonable strategy.. add a an option to indicate masking
status for the connection class associated with the I:line however, a
standard port number shouldn't be used, otherwise users might
activate masking accidentally.
Designate an additional port for all servers to indicate masking preference.
port 6667 outbound is commonly specifically firewalled, even by some
ISPs and may be unavailable to significantly many IRC users (mainly
because infected PC workstations commonly attempt to use port 6667
to get to botnet control channels).
Wouldn't want to deny those people the use of masking.
On the other hand, using a port number to select options like this
is not very scalable. It doubles the number of ports required for
any port-specific protocols such as SSL.
I don't see running out of IRC port numbers as likely to be an issue, however.
As long as masking is the only connect-time option that will ever be controlled
by port number, it (should?) be fine
--
-J