Outdated IRC RFC
Moderator: Supporters
Outdated IRC RFC
Don't you think client-side RFCs are obsolete ?
I think so... There is a need to get a standard for IRC Services.
For instance, if someone wants to dev a client which handle Services, it's getting a headache.
- First, he has to support several Services available around the Internet.
- Second, he has to deal with string responses from notices, not to mention charset/locales complications....instead of numeric standards responses.
I think so... There is a need to get a standard for IRC Services.
For instance, if someone wants to dev a client which handle Services, it's getting a headache.
- First, he has to support several Services available around the Internet.
- Second, he has to deal with string responses from notices, not to mention charset/locales complications....instead of numeric standards responses.
What exactly does the client need to handle though? It's just the server sending out using IRC Server protocol
:NickServ NOTICE w00t :Target not identified
or what ever. I do think that using numerics could be useful, but more useful would be a more standard "base" featureset or something rather than each and every services package having vastly different features, or methods to use these features.
:NickServ NOTICE w00t :Target not identified
or what ever. I do think that using numerics could be useful, but more useful would be a more standard "base" featureset or something rather than each and every services package having vastly different features, or methods to use these features.
-ChatSpike IRC Network [http://www.chatspike.net]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]
Unless it had a blinking light saying, like "IM IDENTIFIED YAY" and waited for services to say "YOU'RE IDENTIFIED YAY" to light up or something
Ok ok, excuse the sarcasm
Ok ok, excuse the sarcasm
-ChatSpike IRC Network [http://www.chatspike.net]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]
I agree with both points, but why do we need standard replies to commands? Why does a _client_ __!@really@!__ need to know if a user is identified? If the topic was changed correctly?
usw usw etc.
usw usw etc.
-ChatSpike IRC Network [http://www.chatspike.net]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]
For asking nickserv password.
Check HTTP basic auth : you just type a couple login/pass.
You are not even required to be aware of Base64, neither HTTP headers.
Why non-geeks users should deal with commands ?
Many are using FTP, mails, or WWW clients and never learned any commands, unless they wanted to hack into the protocol or using command line based clients.
But IRC services require to deal with command line.
I think IRC clients could be more friendly for newbies, but coding friendly clients would only be possible if IRC services' were covered by RFCs.
Check HTTP basic auth : you just type a couple login/pass.
You are not even required to be aware of Base64, neither HTTP headers.
Why non-geeks users should deal with commands ?
Many are using FTP, mails, or WWW clients and never learned any commands, unless they wanted to hack into the protocol or using command line based clients.
But IRC services require to deal with command line.
I think IRC clients could be more friendly for newbies, but coding friendly clients would only be possible if IRC services' were covered by RFCs.
-
- Former UnrealIRCd head coder
- Posts: 811
- Joined: Sat Mar 06, 2004 8:47 pm
- Location: United States
- Contact:
What we are talking about here is NOT the communication between a user and a server, we are talking about the communication between a user and another user. The other user just happens to be automated. It would be like saying, there should be an RFC that states, "When a user asks you, 'how are you feeling today?' a valid response is 'fine', 'good', or 'bad.' Any other response should be deemed as unacceptable and therefore an 'I do not recognize that response' message should be sent followed by repeating the question until a valid response is read." You don't make standards for user text, you make standards for protocols. If you are suggesting standardized text, that will never fly.
First off, you will notice that none of the protocols you mentioned require standardized text. They use standardized codes, much like numerics on IRC. SMTP for example has a response code 354.
My mail server responds with:
354 Go ahead, make my day
my ISP's:
354 Go ahead punk, give it to me!
another:
354 Send away!
yet another:
354 Enter mail, end with a "." on a line by itself
There is no standardization of the text, just the code.
Second, how do you deal with translations? RFCs have finally realized that there is a sizable portion of the world that doesn't speak English. So if you say, "the identify message must be 'you must identify for your nickname'" why should a network of 100% Spanish speaking users have to follow that format? And if they can translate it, then whats the point of standardizing? First off, no two translations are exactly the same. So the RFC would have to list the "official" translations. But even so, there are hundreds of languages in the world! Maintaining such a list would be impossible! And, even if one were maintained, it doesn't solve the "there are different formats" problems because you still have several hundreds of formats, one for each language.
Finally to use your comparison.
You're right, you don't need to know how the HTTP WWW-Authenticate header works just to use a login/password. And you don't need to know how it works in IRC either. When you connect to an IRC server, do you ever send "PASS :mypassword"? No, your client hides that from you. Your client will ask you to enter a password, and it will send the PASS command.
Your comparison is flawed. The IRC protocol authentication can be done automatically, however, we aren't talking about protocol authentication, you are talking about implementation specific authentication. A correct comparison would be comparing nickserv to a login/password form that appears on a website (much like the ones on these forums). You'll notice, there is no standardization there either. Some require a login/password, others a login/email/password, some require a login/pin/password, etc. And even if they have the same fields, the field names in the HTML code are different. Some call it a "username" some a "login" some a "user" some a "user_name" some a "login_name", etc. There is no RFC that says "In a login form, two fields must exist, one for a username and one for a password. The username field will be named 'user_name' and the password file 'password'." So why should there be such a thing for IRC?
First off, you will notice that none of the protocols you mentioned require standardized text. They use standardized codes, much like numerics on IRC. SMTP for example has a response code 354.
My mail server responds with:
354 Go ahead, make my day
my ISP's:
354 Go ahead punk, give it to me!
another:
354 Send away!
yet another:
354 Enter mail, end with a "." on a line by itself
There is no standardization of the text, just the code.
Second, how do you deal with translations? RFCs have finally realized that there is a sizable portion of the world that doesn't speak English. So if you say, "the identify message must be 'you must identify for your nickname'" why should a network of 100% Spanish speaking users have to follow that format? And if they can translate it, then whats the point of standardizing? First off, no two translations are exactly the same. So the RFC would have to list the "official" translations. But even so, there are hundreds of languages in the world! Maintaining such a list would be impossible! And, even if one were maintained, it doesn't solve the "there are different formats" problems because you still have several hundreds of formats, one for each language.
Finally to use your comparison.
You're right, you don't need to know how the HTTP WWW-Authenticate header works just to use a login/password. And you don't need to know how it works in IRC either. When you connect to an IRC server, do you ever send "PASS :mypassword"? No, your client hides that from you. Your client will ask you to enter a password, and it will send the PASS command.
Your comparison is flawed. The IRC protocol authentication can be done automatically, however, we aren't talking about protocol authentication, you are talking about implementation specific authentication. A correct comparison would be comparing nickserv to a login/password form that appears on a website (much like the ones on these forums). You'll notice, there is no standardization there either. Some require a login/password, others a login/email/password, some require a login/pin/password, etc. And even if they have the same fields, the field names in the HTML code are different. Some call it a "username" some a "login" some a "user" some a "user_name" some a "login_name", etc. There is no RFC that says "In a login form, two fields must exist, one for a username and one for a password. The username field will be named 'user_name' and the password file 'password'." So why should there be such a thing for IRC?
-- codemastr
Yes, I agree with everything.
Anyway, that does not change my wish.
That's about friendly using of Internet standards.
Ok sorry, my comparison is not correct, but my feeling is that if Services were using server-to-server communication, it would be easier for clients coders.
With numerics responses, they could code clients which would handle nick authentication to any Services from any IRC server.
Why a specific implementation could not become a standard implementation when there is a need for most users ?
Why not ? After all, it means more freedom for common users.
Anyway, that does not change my wish.
That's about friendly using of Internet standards.
Ok sorry, my comparison is not correct, but my feeling is that if Services were using server-to-server communication, it would be easier for clients coders.
With numerics responses, they could code clients which would handle nick authentication to any Services from any IRC server.
Why a specific implementation could not become a standard implementation when there is a need for most users ?
Why not ? After all, it means more freedom for common users.
WoW | Fun Stuff EveryBody
FBSD-DEV Project
http://www.fbsd-dev.org
YatesDev Hosting
http://www.yatesdev.com
The Wrong Way
http://www.thewrongway.net
http://www.fbsd-dev.org
YatesDev Hosting
http://www.yatesdev.com
The Wrong Way
http://www.thewrongway.net