Forums Feature Suggestions ident RFC

I was reading up on the RFC for the ident protocol, RFC 1413, the protocol specifies this:

"Unless "OTHER" is specified as the operating system type, the server is expected to return the "normal" user identification of the owner of this connection. "Normal" in this context may be taken to mean a string of characters which uniquely identifies the connection owner such as a user identifier assigned by the system administrator and used by such user as a mail identifier, or as the "user" part of a user/password pair used to gain access to system resources." (found on RFC1341 page 3)

In the context for the mIRC connection to an IRC server, when the server requests that an ident be sent, mIRC simply sends its configured ident username, which is completely seperate from the userid on the system and completely unauthorative as the user him/herself can set it anyway he or she wishes.

Thus, under the RFC, shouldn't mIRC either specify the operating system to be Win32 (as defined in RFC1340 page 86/87) and then ask the Windows operating system for the username that user is working under and then reply with THAT to the server. Or, reply with the OS specified as OTHER to let the server know that this is NOT a userid that can be trusted as the standard specified?

I realize that ident is hardly used for real identification purposes,
but why not follow the standard?

Hmm, I wonder if it's not preferable for mIRC to lie in this case? EFnet's Chanfix bot will only op people who can identify themselves via Ident, for instance.

If mIRC was standards complient, we wouldn't have colors, bold, or underlined text either. Being standards complient sometimes isn't the most important thing.

Not to mention fast DCC sends, and possibly passive mode DCC as well.

At any rate, the so-called RFCs can only loosely be defined as "standards" as far as I can see. Sure, they're a good starting point if you want to see how something works, but they're not exactly famous for being strictly adhered to.

yea,

*points to the many discrepencies in the IRC RFC*