I'm surprised not one person here has bothered to quote original and subsequent RFCs to justify the situation. Am I the only one here who reads RFCs? :-) Let's delve into those. Please read EVERYTHING I have written before responding -- because the final conclusion (opinion) may be different than what you think I'm eluding to in my earlier paragraphs.

First and foremost there was RFC 1738, which states clearly:

Quote:
... Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`".

All unsafe characters must always be encoded within a URL. ...


Encoded means turned into their percentage-encoded equivalents. For example, [ needs to become %5b (0x5b hexadecimal), ] needs to become %5d (0x5d hexadecimal), and so on. The list of unsafe characters MUST be encoded: it isn't optional, it's MANDATORY. But let's continue.

Secondly, RFC 3986 expands on this fact. This is outlined clearly on Wikipedia as well. You can read the Wikipedia article sections on unsafe characters to see for yousrelf.

Now let's talk about RFC 2732 and RFC 3513 (both which are older than RFC 3986, I'll point out) -- which introduces IPv6 support into URLs. Bracket characters (e.g. [ and ]) are permitted in a URL, but only within the FQDN/address area ("URI syntax"). Such an example URL would be:

http://[1080::8:800:200c:417a]/foo

This fact is also covered within RFC 3986. Pay very, very close attention to the last line:

Quote:
A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]").

This is the only place where square bracket characters are allowed in the URI syntax.


Now here is a very important point:

Web browsers such as Firefox, Chrome, etc. permit you to enter URLs like http://foobar.com/blah[ilikerice] because behind the scenes they are actually turning this into http://foobar.com/blah%5bilikerice%5d. They don't show you this in the URL bar, but they're doing it behind the scenes; thus, from your perspective, they let you violate RFC. But if you were to look at the actual HTTP GET or POST requests (using Wireshark or Firebug) you would see them encoded. Some browsers (Firefox for example) even let you enter spaces into the URL field -- and it turns them into %20 (like it should) when sending them to the server.

If users on IRC (that includes bots/etc.) are not complying with RFC standards, that's their own fault -- they should be. If IRC servers which generate URLs themselves (internally) and spit them out non-encoded, that is ALSO their fault. Shame on both.

...but what should mIRC itself be doing, since all it technically does is launch a browser instance with a provided URL/string?

mIRC should actually be passing the URL string to the browser literally. So truly, if a user puts in http://foobar.com/blah[ilikerice] then mIRC should pass http://foobar.com/blah[ilikerice] to the browser.

As it stands right now (mIRC 7.25), mIRC appears to terminate the passed string early, e.g. http://foobar.com/blah[ilikerice] gets passed to the browser as http://foobar.com/blah -- and that is indeed an mIRC bug, if you ask me. mIRC should simply let the browser's URL and URI parser decide what to do with the encoding of the string passed to it. The end-of-URL delimiter should be either space (literal ASCII space or the Unicode-equivalent) or end-of-string. Pretty simple, and less overall work for Khaled if you ask me. :-)