It's not that we don't read RFCs, it's that your RFCs mean nothing in this context.
The RFC's don't have to deal with delimiters on URL boundaries-- the RFC can get away with specifying all characters allowed in a URL because it's assumed the entire input is the URL.
This is not the case on IRC. On IRC, Messages (rightly) contain informal formatting and input where URLs may or may not be separated by whitespace boundaries. In many cases, URLs end with NON-whitespace boundaries. There is no way around this, and it's completely unreasonable to claim that it is a "user's fault" for not doing this.
Let me break your example with a quick and easy counter:
Instead of writing
http://example.com/blah[FOO], someone on IRC writes "Generating status [20req/s for http://example.com/blah]"
Note the "]" at the end of the URL. It is clear to any human that ] is not part of the URL. There are many equivalent cases with {}, |, etc.-- mIRC should separate URLs by punctuation, because punctuation *should* delimit a URL in the context of an IRC conversation. Even a "." or "," at the end of a URL should not be considered part of the link, even though those characters are
allowed as per the RFC. It's therefore just
NOT possible for mIRC to pass a URL verbatim to the ending whitespace.
I should point out that it
would be possible for mIRC to improve heuristics for [] and only delimit URLs when they are found at the
end of the input (like . works now), but that still only give you "http://example.com/foo[FOO", omitting the final ]. You could theoretically scan for opening and closing parentheses, but it wouldn't be a reliable check.
FYI, even this forum behaves in the same way. If you could guarantee formal delimitation for the beginning and end of the URL, you could pass it in verbatim. If you're detecting the boundaries based on heuristics, you can't.
