diff options
Diffstat (limited to 'irc_mod/Docs')
| -rw-r--r-- | irc_mod/Docs/IRC_Readme.txt | 47 | ||||
| -rw-r--r-- | irc_mod/Docs/IRC_Translate.txt | 335 | ||||
| -rw-r--r-- | irc_mod/Docs/IRC_license.txt | 340 | ||||
| -rw-r--r-- | irc_mod/Docs/rfc1459.txt | 3643 | ||||
| -rw-r--r-- | irc_mod/Docs/rfc2810.txt | 563 | ||||
| -rw-r--r-- | irc_mod/Docs/rfc2811.txt | 1067 | ||||
| -rw-r--r-- | irc_mod/Docs/rfc2812.txt | 3531 | ||||
| -rw-r--r-- | irc_mod/Docs/rfc2813.txt | 1459 |
8 files changed, 10985 insertions, 0 deletions
diff --git a/irc_mod/Docs/IRC_Readme.txt b/irc_mod/Docs/IRC_Readme.txt new file mode 100644 index 0000000..679365e --- /dev/null +++ b/irc_mod/Docs/IRC_Readme.txt @@ -0,0 +1,47 @@ +----------------------------oOo----------------------------
+ IRC Protocol Plugin v 0.6.3.5
+
+ Implementation of IRC RFC-1459, RFC-2812 for Miranda IM
+
+ Released 2003-03-03, last updated 2005-08-19
+-----------------------------------------------------------
+
+
+Important information
+-----------
+
+#1 Please visit the online resource for the IRC plugin at:
+ http://members.chello.se/matrix/ for more information on usage etc.
+
+#2 To install OpenSSL if you need it, go here:
+ http://members.chello.se/matrix/openssl/Win32OpenSSL-v0.9.7f.exe
+
+#3 This protocol is dependant on the Chat plugin, get it here:
+ http://www.miranda-im.org/download/details.php?action=viewfile&id=1309
+
+
+
+Changelog
+---------
+
+Please visit:
+http://www.miranda-im.org/download/details.php?action=viewlog&id=550
+
+
+
+Copyright and license
+---------------------
+
+Copyright (C) 2003-2005 Jörgen Persson
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
\ No newline at end of file diff --git a/irc_mod/Docs/IRC_Translate.txt b/irc_mod/Docs/IRC_Translate.txt new file mode 100644 index 0000000..b810326 --- /dev/null +++ b/irc_mod/Docs/IRC_Translate.txt @@ -0,0 +1,335 @@ +;-----------------------------------------------------------
+;
+; IRC Protocol Plugin v 0.7.0.9
+;
+; Implementation of IRC RFC-1459, RFC-2812 for Miranda IM
+;
+;
+; TRANSLATION TEMPLATE
+;
+;-----------------------------------------------------------
+
+
+; clist.cpp
+;[CTCP chat request from %s]
+
+; commandmonitor.cpp
+;[CTCP ERROR: Malformed CTCP command received from %s!%s@%s. Possible attempt to take control of your irc client registered]
+;[CTCP FINGER requested by %s]
+;[CTCP VERSION requested by %s]
+;[CTCP SOURCE requested by %s]
+;[CTCP USERINFO requested by %s]
+;[CTCP PING requested by %s]
+;[CTCP TIME requested by %s]
+;[DCC: Chat request from %s denied]
+;[DCC: File transfer request from %s denied]
+;[DCC: Reverse file transfer request from %s denied [No local IP]]
+;[DCC ERROR: Malformed CTCP request from %s [%s]]
+;[DCC: File transfer resume request from %s denied]
+;[CTCP %s requested by %s]
+;[CTCP PING reply from %s: %u sec(s)]
+;[CTCP %s reply from %s: %s]
+;[Downloading list (%u%%) - %u channels]
+;[Downloading list - %u channels]
+;[%s sets mode %s]
+;[Done: %u channels]
+;[(probably truncated by server)]
+;[User information]
+;[Change nickname]
+;[IRC error]
+;[Unknown]
+;[Please enter the hostmask (nick!user@host) \nNOTE! Contacts on your contact list are never ignored]
+;[Ignore]
+;[Please enter the reason]
+;[Ban'n Kick]
+;[Jerk]
+;[Offline]
+;[*Disconnected*]
+;[The usage of /AWAY in your perform buffer is restricted\n as IRC sends this command automatically.]
+
+; input.cpp
+;[Ignore system is enabled]
+;[Ignore system is disabled]
+;[%s on %s is now ignored (+%s)]
+;[%s is not ignored now]
+;[%s was not ignored]
+;[Outgoing commands are shown]
+;[Outgoing commands are not shown]
+;[The buddy check function is enabled]
+;[The buddy check function is disabled]
+;[The time interval for the buddy check function is now at default setting]
+;[The time interval for the buddy check function is now %u seconds]
+;[Channel Manager]
+;[This command is not recommended on a network of this size!\r\nIt will probably cause high CPU usage and/or high bandwidth\r\nusage for around %u to %u minute(s).\r\n\r\nDo you want to continue?]
+;[IRC warning]
+;[Aborted]
+;[CTCP %s request sent to %s]
+;[DCC ERROR: Unable to automatically resolve external IP]
+;[DCC CHAT request sent to %s]
+;[DCC ERROR: Unable to bind port]
+;[Input command]
+;[Please enter the reply]
+
+; main.cpp
+;[The IRC protocol could not be loaded as it is dependant on Miranda IM version %s or later.\n\nDo you want to download an update from the Miranda website now?]
+;[Information]
+
+; options.cpp
+;[Please complete all fields]
+;[<Resolved IP: ]
+;[<Automatic>]
+;[<Local IP: ]
+;[Click to set commands that will be performed for this event]
+;[Click to delete the commands for this event]
+;[Add a new network]
+;[Edit this network]
+;[Delete this network]
+;[Off]
+;[Auto]
+;[On]
+;[N/A]
+;[Do you want to delete\r\n%s]
+;[Delete server]
+;[Edit server]
+;[Network]
+;[%s DCC 'n CTCP]
+;[%s Advanced]
+;[Main]
+;[Add]
+;[Apply]
+;[Edit]
+;[Cancel]
+;[Channel list]
+;[Server window]
+;[Show channel]
+;[Join channel]
+;[Leave Channel]
+;[Incoming DCC Chat]
+
+; output.cpp
+;[WallOps from %s: ]
+;[%s is away]
+;[%s invites you to %s]
+;[These are online: ]
+;[CTCP %s reply sent to %s]
+;[CTCP %s reply sent to %s: %s]
+;[Notice to %s: ]
+
+; services.cpp
+;[&Quick connect]
+;[&Join a channel]
+;[&Change your nickname]
+;[Show the &list of available channels]
+;[&Show the server window]
+;[&Leave the channel]
+;[&User details]
+;[&Ignore]
+;[DCC ERROR: No valid files specified]
+;[DCC reversed file transfer request sent to %s [%s]]
+;[DCC file transfer request sent to %s [%s]]
+;[DCC ERROR: Unable to bind local port]
+;[%s (%s) is requesting a client-to-client chat connection.]
+;[Join channel]
+;[Please enter a channel to join]
+;[Quick connect]
+;[Please select IRC network and enter the password if needed]
+;[Change nick name]
+;[Please enter a unique nickname]
+;[Kick]
+;[Channel &settings]
+;[Show the server &window]
+;[&WhoIs info]
+;[&Control]
+;[&Op]
+;[&Deop]
+;[&Voice]
+;[D&evoice]
+;[&Kick]
+;[Ki&ck (reason)]
+;[&Ban]
+;[Ban'&n kick]
+;[Ban'n kick (&reason)]
+;[&On]
+;[O&ff]
+;[&Direct Connection]
+;[Request &Chat]
+;[Send &File]
+;[&Add User]
+;[&Leave channel]
+;[&Show channel]
+;[&Show server]
+;[&WhoIs info]
+;[&Message]
+;[Di&sconnect]
+;[&Unignore user]
+;[Ignore user]
+;[Nickname]
+;[Connecting to]
+;[This protocol is dependent on another plugin named \'Chat\'\nPlease download it from the Miranda IM website!]
+;[Please choose an IRC-network to go online. This network will be the default.]
+;[Default network]
+;[Connection can not be established! You have not completed all necessary fields (Nickname, User ID and Name).]
+;[The protocol is not online]
+;[The dcc chat connection is not active]
+;[%s server connection]
+;[%s client-to-client connections]
+;[IRC Error]
+;[The IRC protocol depends on another plugin called \'Chat\'\n\nDo you want to download it from the Miranda IM web site now?]
+;[Reconnecting to]
+;[&Add to ignore list]
+;[Give &Op]
+;[Take O&p]
+;[Give &Halfop]
+;[Take H&alfop]
+;[Give &Voice]
+;[Take V&oice]
+
+; windows.cpp
+;[Please wait...]
+;[Channel]
+;[Mode]
+;[Topic]
+;[The \"Nick\" field must contain at least four characters, and also match the default nickname (incl. wildcards) for this contact.\n\nThe \"Nick\" field is not case-sensitive but \"User\" and \"Address\" are.\r\n\r\nThe default nickname for this contact is]
+;[Settings could not be saved!\n\nThe \"Nick\" field must contain at least four characters including wildcards,\n and it must also match the default nickname for this contact.]
+;[Add ban/invite/exception]
+;[Edit selected ban/invite/exception]
+;[Delete selected ban/invite/exception]
+;[Set this topic for the channel]
+;[Set these modes for the channel]
+;[Remove ban?]
+;[Remove invite?]
+;[Remove exception?]
+;[Edit ban]
+;[Edit invite?]
+;[Edit exception?]
+;[Please enter the hostmask (nick!user@host)]
+;[Add ban]
+;[Add invite]
+;[Add exception]
+;[You have not applied all changes!\n\nApply before exiting?]
+
+; IRC.rc
+;[&Add]
+;[&Edit]
+;[&Del]
+;[Enable]
+;[only while connecting]
+;[Update online statuses for users]
+;[Update statuses in channel nicklist]
+;[Don't check if more than (users):]
+;[Keep connection alive]
+;[Force visible (-i)]
+;[Rejoin channel if kicked]
+;[Disable tray balloon on error]
+;[Rejoin channels on reconnect]
+;[Internet address]
+;[Use server window]
+;[Show server window on startup]
+;[Automatically join on invite]
+;[Show addresses]
+;[&Set]
+;[SSL]
+;[Bans]
+;[Invites]
+;[Excepts]
+;[(*) blank to set this mask for all networks]
+;[Perform on event:]
+;[Only Ops set topic]
+;[No external messages]
+;[Invite only]
+;[Moderated]
+;[Key:]
+;[User limit:]
+;[Private]
+;[Secret]
+;[Hidden]
+;[Enable incoming requests]
+;[Normal]
+;[Send-ahead]
+;[Attempt reverse DCC (good if firewalled)]
+;[none]
+;[everyone on the contact list]
+;[everyone]
+;[everyone not on the contact list]
+;[Disconnect DCC chats when disconnecting from server]
+;[Manually set external IP:]
+;[Get IP address from server]
+;[&Refresh]
+;[&Close]
+;[&OK]
+;[&Join]
+;[C&onnect]
+;[&Deny]
+;[Ping]
+;[Version]
+;[Time]
+;[Userinfo]
+;[&Query]
+;[&Cancel]
+;[&Save]
+;[&Clear all]
+;[&Accept]
+;[Port range]
+;[Nick]
+;[User ID (Ident)]
+;[Full name (e-mail)]
+;[Password]
+;[Server name]
+;[Alternative nick]
+;[System]
+;[Port]
+;[Wait (s)]
+;[Retry count]
+;[Fear the monkeys!!!]
+;[Check every (s):]
+;[Name]
+;[Address]
+;[Channels]
+;[Auth]
+;[Server]
+;[User]
+;[Away Info]
+;[Other]
+;[The server returned the following information. Please note that this information might be misleading and/or falsified]
+;[Quit message]
+;[Use the options to set modes for this channel. You are usually required to be op. or higher to modify.]
+;[for choosing the IRC protocol for Miranda IM. Please enter your nickname and real name]
+;[Thank You...]
+;[Full name]
+;[Send mode:]
+;[Packet size (b):]
+;[Ident]
+;[User info - Required]
+;[Reconnect]
+;[CTCP information]
+;[Perform]
+;[Alias]
+;[Hostmask]
+;[User modes]
+;[Channel modes]
+;[Client-to-Client File Transfers]
+;[Auto-accept from:]
+;[Ignore chat requests from...]
+;[Client-to-Client Protocol]
+;[Client-to-Client Chats]
+;[Question]
+;[Add server]
+;[Channels on server]
+;[Miranda IRC]
+;[CTCP Chat Request]
+;[&Whois]
+;[Ki&ck (Reason)]
+;[Ban'&n Kick]
+;[Ban'n Kick (&Reason)]
+;[&Add contact]
+;[&Copy]
+;[Co&py All]
+;[Select &All]
+;[Leave channel]
+;[Clear log]
+;[Show/Hide server]
+;[Channel manager]
+;[Open in &new window]
+;[&Open in existing window]
+;[&Copy link]
+;[Scripting support]
diff --git a/irc_mod/Docs/IRC_license.txt b/irc_mod/Docs/IRC_license.txt new file mode 100644 index 0000000..7f11610 --- /dev/null +++ b/irc_mod/Docs/IRC_license.txt @@ -0,0 +1,340 @@ + GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+ GNU GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+ 1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+ 2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) You must cause the modified files to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ b) You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any
+ part thereof, to be licensed as a whole at no charge to all third
+ parties under the terms of this License.
+
+ c) If the modified program normally reads commands interactively
+ when run, you must cause it, when started running for such
+ interactive use in the most ordinary way, to print or display an
+ announcement including an appropriate copyright notice and a
+ notice that there is no warranty (or else, saying that you provide
+ a warranty) and that users may redistribute the program under
+ these conditions, and telling the user how to view a copy of this
+ License. (Exception: if the Program itself is interactive but
+ does not normally print such an announcement, your work based on
+ the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+ a) Accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of Sections
+ 1 and 2 above on a medium customarily used for software interchange; or,
+
+ b) Accompany it with a written offer, valid for at least three
+ years, to give any third party, for a charge no more than your
+ cost of physically performing source distribution, a complete
+ machine-readable copy of the corresponding source code, to be
+ distributed under the terms of Sections 1 and 2 above on a medium
+ customarily used for software interchange; or,
+
+ c) Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it. For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable. However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+ 4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+ 5. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Program or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+ 6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+ 7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all. For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+ 8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded. In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+ 9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+ 10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+ NO WARRANTY
+
+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+
+ How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) 19yy <name of author>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) 19yy name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ <signature of Ty Coon>, 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs. If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library. If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/irc_mod/Docs/rfc1459.txt b/irc_mod/Docs/rfc1459.txt new file mode 100644 index 0000000..09fbf34 --- /dev/null +++ b/irc_mod/Docs/rfc1459.txt @@ -0,0 +1,3643 @@ + + + + + + +Network Working Group J. Oikarinen +Request for Comments: 1459 D. Reed + May 1993 + + + Internet Relay Chat Protocol + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. Discussion and suggestions for improvement are requested. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + The IRC protocol was developed over the last 4 years since it was + first implemented as a means for users on a BBS to chat amongst + themselves. Now it supports a world-wide network of servers and + clients, and is stringing to cope with growth. Over the past 2 years, + the average number of users connected to the main IRC network has + grown by a factor of 10. + + The IRC protocol is a text-based protocol, with the simplest client + being any socket program capable of connecting to the server. + +Table of Contents + + 1. INTRODUCTION ............................................... 4 + 1.1 Servers ................................................ 4 + 1.2 Clients ................................................ 5 + 1.2.1 Operators .......................................... 5 + 1.3 Channels ................................................ 5 + 1.3.1 Channel Operators .................................... 6 + 2. THE IRC SPECIFICATION ....................................... 7 + 2.1 Overview ................................................ 7 + 2.2 Character codes ......................................... 7 + 2.3 Messages ................................................ 7 + 2.3.1 Message format in 'pseudo' BNF .................... 8 + 2.4 Numeric replies ......................................... 10 + 3. IRC Concepts ................................................ 10 + 3.1 One-to-one communication ................................ 10 + 3.2 One-to-many ............................................. 11 + 3.2.1 To a list .......................................... 11 + 3.2.2 To a group (channel) ............................... 11 + 3.2.3 To a host/server mask .............................. 12 + 3.3 One to all .............................................. 12 + + + +Oikarinen & Reed [Page 1] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 3.3.1 Client to Client ................................... 12 + 3.3.2 Clients to Server .................................. 12 + 3.3.3 Server to Server ................................... 12 + 4. MESSAGE DETAILS ............................................. 13 + 4.1 Connection Registration ................................. 13 + 4.1.1 Password message ................................... 14 + 4.1.2 Nickname message ................................... 14 + 4.1.3 User message ....................................... 15 + 4.1.4 Server message ..................................... 16 + 4.1.5 Operator message ................................... 17 + 4.1.6 Quit message ....................................... 17 + 4.1.7 Server Quit message ................................ 18 + 4.2 Channel operations ...................................... 19 + 4.2.1 Join message ....................................... 19 + 4.2.2 Part message ....................................... 20 + 4.2.3 Mode message ....................................... 21 + 4.2.3.1 Channel modes ................................. 21 + 4.2.3.2 User modes .................................... 22 + 4.2.4 Topic message ...................................... 23 + 4.2.5 Names message ...................................... 24 + 4.2.6 List message ....................................... 24 + 4.2.7 Invite message ..................................... 25 + 4.2.8 Kick message ....................................... 25 + 4.3 Server queries and commands ............................. 26 + 4.3.1 Version message .................................... 26 + 4.3.2 Stats message ...................................... 27 + 4.3.3 Links message ...................................... 28 + 4.3.4 Time message ....................................... 29 + 4.3.5 Connect message .................................... 29 + 4.3.6 Trace message ...................................... 30 + 4.3.7 Admin message ...................................... 31 + 4.3.8 Info message ....................................... 31 + 4.4 Sending messages ........................................ 32 + 4.4.1 Private messages ................................... 32 + 4.4.2 Notice messages .................................... 33 + 4.5 User-based queries ...................................... 33 + 4.5.1 Who query .......................................... 33 + 4.5.2 Whois query ........................................ 34 + 4.5.3 Whowas message ..................................... 35 + 4.6 Miscellaneous messages .................................. 35 + 4.6.1 Kill message ....................................... 36 + 4.6.2 Ping message ....................................... 37 + 4.6.3 Pong message ....................................... 37 + 4.6.4 Error message ...................................... 38 + 5. OPTIONAL MESSAGES ........................................... 38 + 5.1 Away message ............................................ 38 + 5.2 Rehash command .......................................... 39 + 5.3 Restart command ......................................... 39 + + + +Oikarinen & Reed [Page 2] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 5.4 Summon message .......................................... 40 + 5.5 Users message ........................................... 40 + 5.6 Operwall command ........................................ 41 + 5.7 Userhost message ........................................ 42 + 5.8 Ison message ............................................ 42 + 6. REPLIES ..................................................... 43 + 6.1 Error Replies ........................................... 43 + 6.2 Command responses ....................................... 48 + 6.3 Reserved numerics ....................................... 56 + 7. Client and server authentication ............................ 56 + 8. Current Implementations Details ............................. 56 + 8.1 Network protocol: TCP ................................... 57 + 8.1.1 Support of Unix sockets ............................ 57 + 8.2 Command Parsing ......................................... 57 + 8.3 Message delivery ........................................ 57 + 8.4 Connection 'Liveness' ................................... 58 + 8.5 Establishing a server-client connection ................. 58 + 8.6 Establishing a server-server connection ................. 58 + 8.6.1 State information exchange when connecting ......... 59 + 8.7 Terminating server-client connections ................... 59 + 8.8 Terminating server-server connections ................... 59 + 8.9 Tracking nickname changes ............................... 60 + 8.10 Flood control of clients ............................... 60 + 8.11 Non-blocking lookups ................................... 61 + 8.11.1 Hostname (DNS) lookups ............................ 61 + 8.11.2 Username (Ident) lookups .......................... 61 + 8.12 Configuration file ..................................... 61 + 8.12.1 Allowing clients to connect ....................... 62 + 8.12.2 Operators ......................................... 62 + 8.12.3 Allowing servers to connect ....................... 62 + 8.12.4 Administrivia ..................................... 63 + 8.13 Channel membership ..................................... 63 + 9. Current problems ............................................ 63 + 9.1 Scalability ............................................. 63 + 9.2 Labels .................................................. 63 + 9.2.1 Nicknames .......................................... 63 + 9.2.2 Channels ........................................... 64 + 9.2.3 Servers ............................................ 64 + 9.3 Algorithms .............................................. 64 + 10. Support and availability ................................... 64 + 11. Security Considerations .................................... 65 + 12. Authors' Addresses ......................................... 65 + + + + + + + + + +Oikarinen & Reed [Page 3] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +1. INTRODUCTION + + The IRC (Internet Relay Chat) protocol has been designed over a + number of years for use with text based conferencing. This document + describes the current IRC protocol. + + The IRC protocol has been developed on systems using the TCP/IP + network protocol, although there is no requirement that this remain + the only sphere in which it operates. + + IRC itself is a teleconferencing system, which (through the use of + the client-server model) is well-suited to running on many machines + in a distributed fashion. A typical setup involves a single process + (the server) forming a central point for clients (or other servers) + to connect to, performing the required message delivery/multiplexing + and other functions. + +1.1 Servers + + The server forms the backbone of IRC, providing a point to which + clients may connect to to talk to each other, and a point for other + servers to connect to, forming an IRC network. The only network + configuration allowed for IRC servers is that of a spanning tree [see + Fig. 1] where each server acts as a central node for the rest of the + net it sees. + + + [ Server 15 ] [ Server 13 ] [ Server 14] + / \ / + / \ / + [ Server 11 ] ------ [ Server 1 ] [ Server 12] + / \ / + / \ / + [ Server 2 ] [ Server 3 ] + / \ \ + / \ \ + [ Server 4 ] [ Server 5 ] [ Server 6 ] + / | \ / + / | \ / + / | \____ / + / | \ / + [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ] + + : + [ etc. ] + : + + [ Fig. 1. Format of IRC server network ] + + + +Oikarinen & Reed [Page 4] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +1.2 Clients + + A client is anything connecting to a server that is not another + server. Each client is distinguished from other clients by a unique + nickname having a maximum length of nine (9) characters. See the + protocol grammar rules for what may and may not be used in a + nickname. In addition to the nickname, all servers must have the + following information about all clients: the real name of the host + that the client is running on, the username of the client on that + host, and the server to which the client is connected. + +1.2.1 Operators + + To allow a reasonable amount of order to be kept within the IRC + network, a special class of clients (operators) is allowed to perform + general maintenance functions on the network. Although the powers + granted to an operator can be considered as 'dangerous', they are + nonetheless required. Operators should be able to perform basic + network tasks such as disconnecting and reconnecting servers as + needed to prevent long-term use of bad network routing. In + recognition of this need, the protocol discussed herein provides for + operators only to be able to perform such functions. See sections + 4.1.7 (SQUIT) and 4.3.5 (CONNECT). + + A more controversial power of operators is the ability to remove a + user from the connected network by 'force', i.e. operators are able + to close the connection between any client and server. The + justification for this is delicate since its abuse is both + destructive and annoying. For further details on this type of + action, see section 4.6.1 (KILL). + +1.3 Channels + + A channel is a named group of one or more clients which will all + receive messages addressed to that channel. The channel is created + implicitly when the first client joins it, and the channel ceases to + exist when the last client leaves it. While channel exists, any + client can reference the channel using the name of the channel. + + Channels names are strings (beginning with a '&' or '#' character) of + length up to 200 characters. Apart from the the requirement that the + first character being either '&' or '#'; the only restriction on a + channel name is that it may not contain any spaces (' '), a control G + (^G or ASCII 7), or a comma (',' which is used as a list item + separator by the protocol). + + There are two types of channels allowed by this protocol. One is a + distributed channel which is known to all the servers that are + + + +Oikarinen & Reed [Page 5] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + connected to the network. These channels are marked by the first + character being a only clients on the server where it exists may join + it. These are distinguished by a leading '&' character. On top of + these two types, there are the various channel modes available to + alter the characteristics of individual channels. See section 4.2.3 + (MODE command) for more details on this. + + To create a new channel or become part of an existing channel, a user + is required to JOIN the channel. If the channel doesn't exist prior + to joining, the channel is created and the creating user becomes a + channel operator. If the channel already exists, whether or not your + request to JOIN that channel is honoured depends on the current modes + of the channel. For example, if the channel is invite-only, (+i), + then you may only join if invited. As part of the protocol, a user + may be a part of several channels at once, but a limit of ten (10) + channels is recommended as being ample for both experienced and + novice users. See section 8.13 for more information on this. + + If the IRC network becomes disjoint because of a split between two + servers, the channel on each side is only composed of those clients + which are connected to servers on the respective sides of the split, + possibly ceasing to exist on one side of the split. When the split + is healed, the connecting servers announce to each other who they + think is in each channel and the mode of that channel. If the + channel exists on both sides, the JOINs and MODEs are interpreted in + an inclusive manner so that both sides of the new connection will + agree about which clients are in the channel and what modes the + channel has. + +1.3.1 Channel Operators + + The channel operator (also referred to as a "chop" or "chanop") on a + given channel is considered to 'own' that channel. In recognition of + this status, channel operators are endowed with certain powers which + enable them to keep control and some sort of sanity in their channel. + As an owner of a channel, a channel operator is not required to have + reasons for their actions, although if their actions are generally + antisocial or otherwise abusive, it might be reasonable to ask an IRC + operator to intervene, or for the usersjust leave and go elsewhere + and form their own channel. + + The commands which may only be used by channel operators are: + + KICK - Eject a client from the channel + MODE - Change the channel's mode + INVITE - Invite a client to an invite-only channel (mode +i) + TOPIC - Change the channel topic in a mode +t channel + + + + +Oikarinen & Reed [Page 6] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + A channel operator is identified by the '@' symbol next to their + nickname whenever it is associated with a channel (ie replies to the + NAMES, WHO and WHOIS commands). + +2. The IRC Specification + +2.1 Overview + + The protocol as described herein is for use both with server to + server and client to server connections. There are, however, more + restrictions on client connections (which are considered to be + untrustworthy) than on server connections. + +2.2 Character codes + + No specific character set is specified. The protocol is based on a a + set of codes which are composed of eight (8) bits, making up an + octet. Each message may be composed of any number of these octets; + however, some octet values are used for control codes which act as + message delimiters. + + Regardless of being an 8-bit protocol, the delimiters and keywords + are such that protocol is mostly usable from USASCII terminal and a + telnet connection. + + Because of IRC's scandanavian origin, the characters {}| are + considered to be the lower case equivalents of the characters []\, + respectively. This is a critical issue when determining the + equivalence of two nicknames. + +2.3 Messages + + Servers and clients send eachother messages which may or may not + generate a reply. If the message contains a valid command, as + described in later sections, the client should expect a reply as + specified but it is not advised to wait forever for the reply; client + to server and server to server communication is essentially + asynchronous in nature. + + Each IRC message may consist of up to three main parts: the prefix + (optional), the command, and the command parameters (of which there + may be up to 15). The prefix, command, and all parameters are + separated by one (or more) ASCII space character(s) (0x20). + + The presence of a prefix is indicated with a single leading ASCII + colon character (':', 0x3b), which must be the first character of the + message itself. There must be no gap (whitespace) between the colon + and the prefix. The prefix is used by servers to indicate the true + + + +Oikarinen & Reed [Page 7] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + origin of the message. If the prefix is missing from the message, it + is assumed to have originated from the connection from which it was + received. Clients should not use prefix when sending a message from + themselves; if they use a prefix, the only valid prefix is the + registered nickname associated with the client. If the source + identified by the prefix cannot be found from the server's internal + database, or if the source is registered from a different link than + from which the message arrived, the server must ignore the message + silently. + + The command must either be a valid IRC command or a three (3) digit + number represented in ASCII text. + + IRC messages are always lines of characters terminated with a CR-LF + (Carriage Return - Line Feed) pair, and these messages shall not + exceed 512 characters in length, counting all characters including + the trailing CR-LF. Thus, there are 510 characters maximum allowed + for the command and its parameters. There is no provision for + continuation message lines. See section 7 for more details about + current implementations. + +2.3.1 Message format in 'pseudo' BNF + + The protocol messages must be extracted from the contiguous stream of + octets. The current solution is to designate two characters, CR and + LF, as message separators. Empty messages are silently ignored, + which permits use of the sequence CR-LF between messages + without extra problems. + + The extracted message is parsed into the components <prefix>, + <command> and list of parameters matched either by <middle> or + <trailing> components. + + The BNF representation for this is: + + +<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf> +<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ] +<command> ::= <letter> { <letter> } | <number> <number> <number> +<SPACE> ::= ' ' { ' ' } +<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ] + +<middle> ::= <Any *non-empty* sequence of octets not including SPACE + or NUL or CR or LF, the first of which may not be ':'> +<trailing> ::= <Any, possibly *empty*, sequence of octets not including + NUL or CR or LF> + +<crlf> ::= CR LF + + + +Oikarinen & Reed [Page 8] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +NOTES: + + 1) <SPACE> is consists only of SPACE character(s) (0x20). + Specially notice that TABULATION, and all other control + characters are considered NON-WHITE-SPACE. + + 2) After extracting the parameter list, all parameters are equal, + whether matched by <middle> or <trailing>. <Trailing> is just + a syntactic trick to allow SPACE within parameter. + + 3) The fact that CR and LF cannot appear in parameter strings is + just artifact of the message framing. This might change later. + + 4) The NUL character is not special in message framing, and + basically could end up inside a parameter, but as it would + cause extra complexities in normal C string handling. Therefore + NUL is not allowed within messages. + + 5) The last parameter may be an empty string. + + 6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must + not be used in server to server communications and is only + intended for server to client messages in order to provide + clients with more useful information about who a message is + from without the need for additional queries. + + Most protocol messages specify additional semantics and syntax for + the extracted parameter strings dictated by their position in the + list. For example, many server commands will assume that the first + parameter after the command is the list of targets, which can be + described with: + + <target> ::= <to> [ "," <target> ] + <to> ::= <channel> | <user> '@' <servername> | <nick> | <mask> + <channel> ::= ('#' | '&') <chstring> + <servername> ::= <host> + <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames + <nick> ::= <letter> { <letter> | <number> | <special> } + <mask> ::= ('#' | '$') <chstring> + <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and + comma (',')> + + Other parameter syntaxes are: + + <user> ::= <nonwhite> { <nonwhite> } + <letter> ::= 'a' ... 'z' | 'A' ... 'Z' + <number> ::= '0' ... '9' + <special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' + + + +Oikarinen & Reed [Page 9] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR + (0xd), and LF (0xa)> + +2.4 Numeric replies + + Most of the messages sent to the server generate a reply of some + sort. The most common reply is the numeric reply, used for both + errors and normal replies. The numeric reply must be sent as one + message consisting of the sender prefix, the three digit numeric, and + the target of the reply. A numeric reply is not allowed to originate + from a client; any such messages received by a server are silently + dropped. In all other respects, a numeric reply is just like a normal + message, except that the keyword is made up of 3 numeric digits + rather than a string of letters. A list of different replies is + supplied in section 6. + +3. IRC Concepts. + + This section is devoted to describing the actual concepts behind the + organization of the IRC protocol and how the current + implementations deliver different classes of messages. + + + + 1--\ + A D---4 + 2--/ \ / + B----C + / \ + 3 E + + Servers: A, B, C, D, E Clients: 1, 2, 3, 4 + + [ Fig. 2. Sample small IRC network ] + +3.1 One-to-one communication + + Communication on a one-to-one basis is usually only performed by + clients, since most server-server traffic is not a result of servers + talking only to each other. To provide a secure means for clients to + talk to each other, it is required that all servers be able to send a + message in exactly one direction along the spanning tree in order to + reach any client. The path of a message being delivered is the + shortest path between any two points on the spanning tree. + + The following examples all refer to Figure 2 above. + + + + + +Oikarinen & Reed [Page 10] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +Example 1: + A message between clients 1 and 2 is only seen by server A, which + sends it straight to client 2. + +Example 2: + A message between clients 1 and 3 is seen by servers A & B, and + client 3. No other clients or servers are allowed see the message. + +Example 3: + A message between clients 2 and 4 is seen by servers A, B, C & D + and client 4 only. + +3.2 One-to-many + + The main goal of IRC is to provide a forum which allows easy and + efficient conferencing (one to many conversations). IRC offers + several means to achieve this, each serving its own purpose. + +3.2.1 To a list + + The least efficient style of one-to-many conversation is through + clients talking to a 'list' of users. How this is done is almost + self explanatory: the client gives a list of destinations to which + the message is to be delivered and the server breaks it up and + dispatches a separate copy of the message to each given destination. + This isn't as efficient as using a group since the destination list + is broken up and the dispatch sent without checking to make sure + duplicates aren't sent down each path. + +3.2.2 To a group (channel) + + In IRC the channel has a role equivalent to that of the multicast + group; their existence is dynamic (coming and going as people join + and leave channels) and the actual conversation carried out on a + channel is only sent to servers which are supporting users on a given + channel. If there are multiple users on a server in the same + channel, the message text is sent only once to that server and then + sent to each client on the channel. This action is then repeated for + each client-server combination until the original message has fanned + out and reached each member of the channel. + + The following examples all refer to Figure 2. + +Example 4: + Any channel with 1 client in it. Messages to the channel go to the + server and then nowhere else. + + + + + +Oikarinen & Reed [Page 11] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +Example 5: + 2 clients in a channel. All messages traverse a path as if they + were private messages between the two clients outside a channel. + +Example 6: + Clients 1, 2 and 3 in a channel. All messages to the channel are + sent to all clients and only those servers which must be traversed + by the message if it were a private message to a single client. If + client 1 sends a message, it goes back to client 2 and then via + server B to client 3. + +3.2.3 To a host/server mask + + To provide IRC operators with some mechanism to send messages to a + large body of related users, host and server mask messages are + provided. These messages are sent to users whose host or server + information match that of the mask. The messages are only sent to + locations where users are, in a fashion similar to that of channels. + +3.3 One-to-all + + The one-to-all type of message is better described as a broadcast + message, sent to all clients or servers or both. On a large network + of users and servers, a single message can result in a lot of traffic + being sent over the network in an effort to reach all of the desired + destinations. + + For some messages, there is no option but to broadcast it to all + servers so that the state information held by each server is + reasonably consistent between servers. + +3.3.1 Client-to-Client + + There is no class of message which, from a single message, results in + a message being sent to every other client. + +3.3.2 Client-to-Server + + Most of the commands which result in a change of state information + (such as channel membership, channel mode, user status, etc) must be + sent to all servers by default, and this distribution may not be + changed by the client. + +3.3.3 Server-to-Server. + + While most messages between servers are distributed to all 'other' + servers, this is only required for any message that affects either a + user, channel or server. Since these are the basic items found in + + + +Oikarinen & Reed [Page 12] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + IRC, nearly all messages originating from a server are broadcast to + all other connected servers. + +4. Message details + + On the following pages are descriptions of each message recognized by + the IRC server and client. All commands described in this section + must be implemented by any server for this protocol. + + Where the reply ERR_NOSUCHSERVER is listed, it means that the + <server> parameter could not be found. The server must not send any + other replies after this for that command. + + The server to which a client is connected is required to parse the + complete message, returning any appropriate errors. If the server + encounters a fatal error while parsing a message, an error must be + sent back to the client and the parsing terminated. A fatal error + may be considered to be incorrect command, a destination which is + otherwise unknown to the server (server, nick or channel names fit + this category), not enough parameters or incorrect privileges. + + If a full set of parameters is presented, then each must be checked + for validity and appropriate responses sent back to the client. In + the case of messages which use parameter lists using the comma as an + item separator, a reply must be sent for each item. + + In the examples below, some messages appear using the full format: + + :Name COMMAND parameter list + + Such examples represent a message from "Name" in transit between + servers, where it is essential to include the name of the original + sender of the message so remote servers may send back a reply along + the correct path. + +4.1 Connection Registration + + The commands described here are used to register a connection with an + IRC server as either a user or a server as well as correctly + disconnect. + + A "PASS" command is not required for either client or server + connection to be registered, but it must precede the server message + or the latter of the NICK/USER combination. It is strongly + recommended that all server connections have a password in order to + give some level of security to the actual connections. The + recommended order for a client to register is as follows: + + + + +Oikarinen & Reed [Page 13] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 1. Pass message + 2. Nick message + 3. User message + +4.1.1 Password message + + + Command: PASS + Parameters: <password> + + The PASS command is used to set a 'connection password'. The + password can and must be set before any attempt to register the + connection is made. Currently this requires that clients send a PASS + command before sending the NICK/USER combination and servers *must* + send a PASS command before any SERVER command. The password supplied + must match the one contained in the C/N lines (for servers) or I + lines (for clients). It is possible to send multiple PASS commands + before registering but only the last one sent is used for + verification and it may not be changed once registered. Numeric + Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + PASS secretpasswordhere + +4.1.2 Nick message + + Command: NICK + Parameters: <nickname> [ <hopcount> ] + + NICK message is used to give user a nickname or change the previous + one. The <hopcount> parameter is only used by servers to indicate + how far away a nick is from its home server. A local connection has + a hopcount of 0. If supplied by a client, it must be ignored. + + If a NICK message arrives at a server which already knows about an + identical nickname for another client, a nickname collision occurs. + As a result of a nickname collision, all instances of the nickname + are removed from the server's database, and a KILL command is issued + to remove the nickname from all other server's database. If the NICK + message causing the collision was a nickname change, then the + original (old) nick must be removed as well. + + If the server recieves an identical NICK from a client which is + directly connected, it may issue an ERR_NICKCOLLISION to the local + client, drop the NICK command, and not generate any kills. + + + +Oikarinen & Reed [Page 14] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME + ERR_NICKNAMEINUSE ERR_NICKCOLLISION + + Example: + + NICK Wiz ; Introducing new nick "Wiz". + + :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy. + +4.1.3 User message + + Command: USER + Parameters: <username> <hostname> <servername> <realname> + + The USER message is used at the beginning of connection to specify + the username, hostname, servername and realname of s new user. It is + also used in communication between servers to indicate new user + arriving on IRC, since only after both USER and NICK have been + received from a client does a user become registered. + + Between servers USER must to be prefixed with client's NICKname. + Note that hostname and servername are normally ignored by the IRC + server when the USER command comes from a directly connected client + (for security reasons), but they are used in server to server + communication. This means that a NICK must always be sent to a + remote server when a new user is being introduced to the rest of the + network before the accompanying USER is sent. + + It must be noted that realname parameter must be the last parameter, + because it may contain space characters and must be prefixed with a + colon (':') to make sure this is recognised as such. + + Since it is easy for a client to lie about its username by relying + solely on the USER message, the use of an "Identity Server" is + recommended. If the host which a user connects from has such a + server enabled the username is set to that as in the reply from the + "Identity Server". + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Examples: + + + USER guest tolmoon tolsun :Ronnie Reagan + + + +Oikarinen & Reed [Page 15] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + ; User registering themselves with a + username of "guest" and real name + "Ronnie Reagan". + + + :testnick USER guest tolmoon tolsun :Ronnie Reagan + ; message between servers with the + nickname for which the USER command + belongs to + +4.1.4 Server message + + Command: SERVER + Parameters: <servername> <hopcount> <info> + + The server message is used to tell a server that the other end of a + new connection is a server. This message is also used to pass server + data over whole net. When a new server is connected to net, + information about it be broadcast to the whole network. <hopcount> + is used to give all servers some internal information on how far away + all servers are. With a full server list, it would be possible to + construct a map of the entire server tree, but hostmasks prevent this + from being done. + + The SERVER message must only be accepted from either (a) a connection + which is yet to be registered and is attempting to register as a + server, or (b) an existing connection to another server, in which + case the SERVER message is introducing a new server behind that + server. + + Most errors that occur with the receipt of a SERVER command result in + the connection being terminated by the destination host (target + SERVER). Error replies are usually sent using the "ERROR" command + rather than the numeric since the ERROR command has several useful + properties which make it useful here. + + If a SERVER message is parsed and attempts to introduce a server + which is already known to the receiving server, the connection from + which that message must be closed (following the correct procedures), + since a duplicate route to a server has formed and the acyclic nature + of the IRC tree broken. + + Numeric Replies: + + ERR_ALREADYREGISTRED + + Example: + + + + +Oikarinen & Reed [Page 16] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server + ; New server test.oulu.fi introducing + itself and attempting to register. The + name in []'s is the hostname for the + host running test.oulu.fi. + + +:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server + ; Server tolsun.oulu.fi is our uplink + for csd.bu.edu which is 5 hops away. + +4.1.5 Oper + + Command: OPER + Parameters: <user> <password> + + OPER message is used by a normal user to obtain operator privileges. + The combination of <user> and <password> are required to gain + Operator privileges. + + If the client sending the OPER command supplies the correct password + for the given user, the server then informs the rest of the network + of the new operator by issuing a "MODE +o" for the clients nickname. + + The OPER message is client-server only. + + Numeric Replies: + + ERR_NEEDMOREPARAMS RPL_YOUREOPER + ERR_NOOPERHOST ERR_PASSWDMISMATCH + + Example: + + OPER foo bar ; Attempt to register as an operator + using a username of "foo" and "bar" as + the password. + +4.1.6 Quit + + Command: QUIT + Parameters: [<Quit message>] + + A client session is ended with a quit message. The server must close + the connection to a client which sends a QUIT message. If a "Quit + Message" is given, this will be sent instead of the default message, + the nickname. + + When netsplits (disconnecting of two servers) occur, the quit message + + + +Oikarinen & Reed [Page 17] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + is composed of the names of two servers involved, separated by a + space. The first name is that of the server which is still connected + and the second name is that of the server that has become + disconnected. + + If, for some other reason, a client connection is closed without the + client issuing a QUIT command (e.g. client dies and EOF occurs + on socket), the server is required to fill in the quit message with + some sort of message reflecting the nature of the event which + caused it to happen. + + Numeric Replies: + + None. + + Examples: + + QUIT :Gone to have lunch ; Preferred message format. + +4.1.7 Server quit message + + Command: SQUIT + Parameters: <server> <comment> + + The SQUIT message is needed to tell about quitting or dead servers. + If a server wishes to break the connection to another server it must + send a SQUIT message to the other server, using the the name of the + other server as the server parameter, which then closes its + connection to the quitting server. + + This command is also available operators to help keep a network of + IRC servers connected in an orderly fashion. Operators may also + issue an SQUIT message for a remote server connection. In this case, + the SQUIT must be parsed by each server inbetween the operator and + the remote server, updating the view of the network held by each + server as explained below. + + The <comment> should be supplied by all operators who execute a SQUIT + for a remote server (that is not connected to the server they are + currently on) so that other operators are aware for the reason of + this action. The <comment> is also filled in by servers which may + place an error or similar message here. + + Both of the servers which are on either side of the connection being + closed are required to to send out a SQUIT message (to all its other + server connections) for all other servers which are considered to be + behind that link. + + + + +Oikarinen & Reed [Page 18] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Similarly, a QUIT message must be sent to the other connected servers + rest of the network on behalf of all clients behind that link. In + addition to this, all channel members of a channel which lost a + member due to the split must be sent a QUIT message. + + If a server connection is terminated prematurely (e.g. the server on + the other end of the link died), the server which detects + this disconnection is required to inform the rest of the network + that the connection has closed and fill in the comment field + with something appropriate. + + Numeric replies: + + ERR_NOPRIVILEGES ERR_NOSUCHSERVER + + Example: + + SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has + been terminated because of "Bad Link". + + :Trillian SQUIT cm22.eng.umd.edu :Server out of control + ; message from Trillian to disconnect + "cm22.eng.umd.edu" from the net + because "Server out of control". + +4.2 Channel operations + + This group of messages is concerned with manipulating channels, their + properties (channel modes), and their contents (typically clients). + In implementing these, a number of race conditions are inevitable + when clients at opposing ends of a network send commands which will + ultimately clash. It is also required that servers keep a nickname + history to ensure that wherever a <nick> parameter is given, the + server check its history in case it has recently been changed. + +4.2.1 Join message + + Command: JOIN + Parameters: <channel>{,<channel>} [<key>{,<key>}] + + The JOIN command is used by client to start listening a specific + channel. Whether or not a client is allowed to join a channel is + checked only by the server the client is connected to; all other + servers automatically add the user to the channel when it is received + from other servers. The conditions which affect this are as follows: + + 1. the user must be invited if the channel is invite-only; + + + + +Oikarinen & Reed [Page 19] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 2. the user's nick/username/hostname must not match any + active bans; + + 3. the correct key (password) must be given if it is set. + + These are discussed in more detail under the MODE command (see + section 4.2.3 for more details). + + Once a user has joined a channel, they receive notice about all + commands their server receives which affect the channel. This + includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The + JOIN command needs to be broadcast to all servers so that each server + knows where to find the users who are on the channel. This allows + optimal delivery of PRIVMSG/NOTICE messages to the channel. + + If a JOIN is successful, the user is then sent the channel's topic + (using RPL_TOPIC) and the list of users who are on the channel (using + RPL_NAMREPLY), which must include the user joining. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN + ERR_INVITEONLYCHAN ERR_BADCHANNELKEY + ERR_CHANNELISFULL ERR_BADCHANMASK + ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS + RPL_TOPIC + + Examples: + + JOIN #foobar ; join channel #foobar. + + JOIN &foo fubar ; join channel &foo using key "fubar". + + JOIN #foo,&bar fubar ; join channel #foo using key "fubar" + and &bar using no key. + + JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar". + and channel #bar using key "foobar". + + JOIN #foo,#bar ; join channels #foo and #bar. + + :WiZ JOIN #Twilight_zone ; JOIN message from WiZ + +4.2.2 Part message + + Command: PART + Parameters: <channel>{,<channel>} + + + + +Oikarinen & Reed [Page 20] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The PART message causes the client sending the message to be removed + from the list of active users for all given channels listed in the + parameter string. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_NOTONCHANNEL + + Examples: + + PART #twilight_zone ; leave channel "#twilight_zone" + + PART #oz-ops,&group5 ; leave both channels "&group5" and + "#oz-ops". + +4.2.3 Mode message + + Command: MODE + + The MODE command is a dual-purpose command in IRC. It allows both + usernames and channels to have their mode changed. The rationale for + this choice is that one day nicknames will be obsolete and the + equivalent property will be the channel. + + When parsing MODE messages, it is recommended that the entire message + be parsed first and then the changes which resulted then passed on. + +4.2.3.1 Channel modes + + Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>] + [<ban mask>] + + The MODE command is provided so that channel operators may change the + characteristics of `their' channel. It is also required that servers + be able to change channel modes so that channel operators may be + created. + + The various modes available for channels are as follows: + + o - give/take channel operator privileges; + p - private channel flag; + s - secret channel flag; + i - invite-only channel flag; + t - topic settable by channel operator only flag; + n - no messages to channel from clients on the outside; + m - moderated channel; + l - set the user limit to channel; + + + +Oikarinen & Reed [Page 21] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + b - set a ban mask to keep users out; + v - give/take the ability to speak on a moderated channel; + k - set a channel key (password). + + When using the 'o' and 'b' options, a restriction on a total of three + per mode command has been imposed. That is, any combination of 'o' + and + +4.2.3.2 User modes + + Parameters: <nickname> {[+|-]|i|w|s|o} + + The user MODEs are typically changes which affect either how the + client is seen by others or what 'extra' messages the client is sent. + A user MODE command may only be accepted if both the sender of the + message and the nickname given as a parameter are both the same. + + The available modes are as follows: + + i - marks a users as invisible; + s - marks a user for receipt of server notices; + w - user receives wallops; + o - operator flag. + + Additional modes may be available later on. + + If a user attempts to make themselves an operator using the "+o" + flag, the attempt should be ignored. There is no restriction, + however, on anyone `deopping' themselves (using "-o"). Numeric + Replies: + + ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS + ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK + ERR_NOTONCHANNEL ERR_KEYSET + RPL_BANLIST RPL_ENDOFBANLIST + ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL + + ERR_USERSDONTMATCH RPL_UMODEIS + ERR_UMODEUNKNOWNFLAG + + Examples: + + Use of Channel Modes: + +MODE #Finnish +im ; Makes #Finnish channel moderated and + 'invite-only'. + +MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on + + + +Oikarinen & Reed [Page 22] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + channel #Finnish. + +MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish. + +MODE #Fins -s ; Removes 'secret' flag from channel + #Fins. + +MODE #42 +k oulu ; Set the channel key to "oulu". + +MODE #eu-opers +l 10 ; Set the limit for the number of users + on channel to 10. + +MODE &oulu +b ; list ban masks set for channel. + +MODE &oulu +b *!*@* ; prevent all users from joining. + +MODE &oulu +b *!*@*.edu ; prevent any user from a hostname + matching *.edu from joining. + + Use of user Modes: + +:MODE WiZ -w ; turns reception of WALLOPS messages + off for WiZ. + +:Angel MODE Angel +i ; Message from Angel to make themselves + invisible. + +MODE WiZ -o ; WiZ 'deopping' (removing operator + status). The plain reverse of this + command ("MODE WiZ +o") must not be + allowed from users since would bypass + the OPER command. + +4.2.4 Topic message + + Command: TOPIC + Parameters: <channel> [<topic>] + + The TOPIC message is used to change or view the topic of a channel. + The topic for channel <channel> is returned if there is no <topic> + given. If the <topic> parameter is present, the topic for that + channel will be changed, if the channel modes permit this action. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL + RPL_NOTOPIC RPL_TOPIC + ERR_CHANOPRIVSNEEDED + + + +Oikarinen & Reed [Page 23] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Examples: + + :Wiz TOPIC #test :New topic ;User Wiz setting the topic. + + TOPIC #test :another topic ;set the topic on #test to "another + topic". + + TOPIC #test ; check the topic for #test. + +4.2.5 Names message + + Command: NAMES + Parameters: [<channel>{,<channel>}] + + By using the NAMES command, a user can list all nicknames that are + visible to them on any channel that they can see. Channel names + which they can see are those which aren't private (+p) or secret (+s) + or those which they are actually on. The <channel> parameter + specifies which channel(s) to return information about if valid. + There is no error reply for bad channel names. + + If no <channel> parameter is given, a list of all channels and their + occupants is returned. At the end of this list, a list of users who + are visible but either not on any channel or not on a visible channel + are listed as being on `channel' "*". + + Numerics: + + RPL_NAMREPLY RPL_ENDOFNAMES + + Examples: + + NAMES #twilight_zone,#42 ; list visible users on #twilight_zone + and #42 if the channels are visible to + you. + + NAMES ; list all visible channels and users + +4.2.6 List message + + Command: LIST + Parameters: [<channel>{,<channel>} [<server>]] + + The list message is used to list channels and their topics. If the + <channel> parameter is used, only the status of that channel + is displayed. Private channels are listed (without their + topics) as channel "Prv" unless the client generating the query is + actually on that channel. Likewise, secret channels are not listed + + + +Oikarinen & Reed [Page 24] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + at all unless the client is a member of the channel in question. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_LISTSTART + RPL_LIST RPL_LISTEND + + Examples: + + LIST ; List all channels. + + LIST #twilight_zone,#42 ; List channels #twilight_zone and #42 + +4.2.7 Invite message + + Command: INVITE + Parameters: <nickname> <channel> + + The INVITE message is used to invite users to a channel. The + parameter <nickname> is the nickname of the person to be invited to + the target channel <channel>. There is no requirement that the + channel the target user is being invited to must exist or be a valid + channel. To invite a user to a channel which is invite only (MODE + +i), the client sending the invite must be recognised as being a + channel operator on the given channel. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHNICK + ERR_NOTONCHANNEL ERR_USERONCHANNEL + ERR_CHANOPRIVSNEEDED + RPL_INVITING RPL_AWAY + + Examples: + + :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel + #Dust + + INVITE Wiz #Twilight_Zone ; Command to invite WiZ to + #Twilight_zone + +4.2.8 Kick command + + Command: KICK + Parameters: <channel> <user> [<comment>] + + The KICK command can be used to forcibly remove a user from a + channel. It 'kicks them out' of the channel (forced PART). + + + +Oikarinen & Reed [Page 25] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Only a channel operator may kick another user out of a channel. + Each server that receives a KICK message checks that it is valid + (ie the sender is actually a channel operator) before removing + the victim from the channel. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED + ERR_NOTONCHANNEL + + Examples: + +KICK &Melbourne Matthew ; Kick Matthew from &Melbourne + +KICK #Finnish John :Speaking English + ; Kick John from #Finnish using + "Speaking English" as the reason + (comment). + +:WiZ KICK #Finnish John ; KICK message from WiZ to remove John + from channel #Finnish + +NOTE: + It is possible to extend the KICK command parameters to the +following: + +<channel>{,<channel>} <user>{,<user>} [<comment>] + +4.3 Server queries and commands + + The server query group of commands has been designed to return + information about any server which is connected to the network. All + servers connected must respond to these queries and respond + correctly. Any invalid response (or lack thereof) must be considered + a sign of a broken server and it must be disconnected/disabled as + soon as possible until the situation is remedied. + + In these queries, where a parameter appears as "<server>", it will + usually mean it can be a nickname or a server or a wildcard name of + some sort. For each parameter, however, only one query and set of + replies is to be generated. + +4.3.1 Version message + + Command: VERSION + Parameters: [<server>] + + + + +Oikarinen & Reed [Page 26] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The VERSION message is used to query the version of the server + program. An optional parameter <server> is used to query the version + of the server program which a client is not directly connected to. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_VERSION + + Examples: + + :Wiz VERSION *.se ; message from Wiz to check the version + of a server matching "*.se" + + VERSION tolsun.oulu.fi ; check the version of server + "tolsun.oulu.fi". + +4.3.2 Stats message + + Command: STATS + Parameters: [<query> [<server>]] + + The stats message is used to query statistics of certain server. If + <server> parameter is omitted, only the end of stats reply is sent + back. The implementation of this command is highly dependent on the + server which replies, although the server must be able to supply + information as described by the queries below (or similar). + + A query may be given by any single letter which is only checked by + the destination server (if given as the <server> parameter) and is + otherwise passed on by intermediate servers, ignored and unaltered. + The following queries are those found in the current IRC + implementation and provide a large portion of the setup information + for that server. Although these may not be supported in the same way + by other versions, all servers should be able to supply a valid reply + to a STATS query which is consistent with the reply formats currently + used and the purpose of the query. + + The currently supported queries are: + + c - returns a list of servers which the server may connect + to or allow connections from; + h - returns a list of servers which are either forced to be + treated as leaves or allowed to act as hubs; + i - returns a list of hosts which the server allows a client + to connect from; + k - returns a list of banned username/hostname combinations + for that server; + l - returns a list of the server's connections, showing how + + + +Oikarinen & Reed [Page 27] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + long each connection has been established and the traffic + over that connection in bytes and messages for each + direction; + m - returns a list of commands supported by the server and + the usage count for each if the usage count is non zero; + o - returns a list of hosts from which normal clients may + become operators; + y - show Y (Class) lines from server's configuration file; + u - returns a string showing how long the server has been up. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_STATSCLINE RPL_STATSNLINE + RPL_STATSILINE RPL_STATSKLINE + RPL_STATSQLINE RPL_STATSLLINE + RPL_STATSLINKINFO RPL_STATSUPTIME + RPL_STATSCOMMANDS RPL_STATSOLINE + RPL_STATSHLINE RPL_ENDOFSTATS + + Examples: + +STATS m ; check the command usage for the server + you are connected to + +:Wiz STATS c eff.org ; request by WiZ for C/N line + information from server eff.org + +4.3.3 Links message + + Command: LINKS + Parameters: [[<remote server>] <server mask>] + + With LINKS, a user can list all servers which are known by the server + answering the query. The returned list of servers must match the + mask, or if no mask is given, the full list is returned. + + If <remote server> is given in addition to <server mask>, the LINKS + command is forwarded to the first server found that matches that name + (if any), and that server is then required to answer the query. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_LINKS RPL_ENDOFLINKS + + Examples: + + + + +Oikarinen & Reed [Page 28] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +LINKS *.au ; list all servers which have a name + that matches *.au; + +:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first + server matching *.edu for a list of + servers matching *.bu.edu. + +4.3.4 Time message + + Command: TIME + Parameters: [<server>] + + The time message is used to query local time from the specified + server. If the server parameter is not given, the server handling the + command must reply to the query. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_TIME + + Examples: + + TIME tolsun.oulu.fi ; check the time on the server + "tolson.oulu.fi" + + Angel TIME *.au ; user angel checking the time on a + server matching "*.au" + +4.3.5 Connect message + + Command: CONNECT + Parameters: <target server> [<port> [<remote server>]] + + The CONNECT command can be used to force a server to try to establish + a new connection to another server immediately. CONNECT is a + privileged command and is to be available only to IRC Operators. If + a remote server is given then the CONNECT attempt is made by that + server to <target server> and <port>. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NOPRIVILEGES + ERR_NEEDMOREPARAMS + + Examples: + +CONNECT tolsun.oulu.fi ; Attempt to connect a server to + tolsun.oulu.fi + + + +Oikarinen & Reed [Page 29] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +:WiZ CONNECT eff.org 6667 csd.bu.edu + ; CONNECT attempt by WiZ to get servers + eff.org and csd.bu.edu connected on port + 6667. + +4.3.6 Trace message + + Command: TRACE + Parameters: [<server>] + + TRACE command is used to find the route to specific server. Each + server that processes this message must tell the sender about it by + sending a reply indicating it is a pass-through link, forming a chain + of replies similar to that gained from using "traceroute". After + sending this reply back, it must then send the TRACE message to the + next server until given server is reached. If the <server> parameter + is omitted, it is recommended that TRACE command send a message to + the sender telling which servers the current server has direct + connection to. + + If the destination given by "<server>" is an actual server, then the + destination server is required to report all servers and users which + are connected to it, although only operators are permitted to see + users present. If the destination given by <server> is a nickname, + they only a reply for that nickname is given. + + Numeric Replies: + + ERR_NOSUCHSERVER + + If the TRACE message is destined for another server, all intermediate + servers must return a RPL_TRACELINK reply to indicate that the TRACE + passed through it and where its going next. + + RPL_TRACELINK + A TRACE reply may be composed of any number of the following numeric + replies. + + RPL_TRACECONNECTING RPL_TRACEHANDSHAKE + RPL_TRACEUNKNOWN RPL_TRACEOPERATOR + RPL_TRACEUSER RPL_TRACESERVER + RPL_TRACESERVICE RPL_TRACENEWTYPE + RPL_TRACECLASS + + Examples: + +TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi + + + + +Oikarinen & Reed [Page 30] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust + +4.3.7 Admin command + + Command: ADMIN + Parameters: [<server>] + + The admin message is used to find the name of the administrator of + the given server, or current server if <server> parameter is omitted. + Each server must have the ability to forward ADMIN messages to other + servers. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_ADMINME RPL_ADMINLOC1 + RPL_ADMINLOC2 RPL_ADMINEMAIL + + Examples: + + ADMIN tolsun.oulu.fi ; request an ADMIN reply from + tolsun.oulu.fi + + :WiZ ADMIN *.edu ; ADMIN request from WiZ for first + server found to match *.edu. + +4.3.8 Info command + + Command: INFO + Parameters: [<server>] + + The INFO command is required to return information which describes + the server: its version, when it was compiled, the patchlevel, when + it was started, and any other miscellaneous information which may be + considered to be relevant. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_INFO RPL_ENDOFINFO + + Examples: + + INFO csd.bu.edu ; request an INFO reply from + csd.bu.edu + + :Avalon INFO *.fi ; INFO request from Avalon for first + server found to match *.fi. + + + +Oikarinen & Reed [Page 31] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + INFO Angel ; request info from the server that + Angel is connected to. + +4.4 Sending messages + + The main purpose of the IRC protocol is to provide a base for clients + to communicate with each other. PRIVMSG and NOTICE are the only + messages available which actually perform delivery of a text message + from one client to another - the rest just make it possible and try + to ensure it happens in a reliable and structured manner. + +4.4.1 Private messages + + Command: PRIVMSG + Parameters: <receiver>{,<receiver>} <text to be sent> + + PRIVMSG is used to send private messages between users. <receiver> + is the nickname of the receiver of the message. <receiver> can also + be a list of names or channels separated with commas. + + The <receiver> parameter may also me a host mask (#mask) or server + mask ($mask). In both cases the server will only send the PRIVMSG + to those who have a server or host matching the mask. The mask must + have at least 1 (one) "." in it and no wildcards following the + last ".". This requirement exists to prevent people sending messages + to "#*" or "$*", which would broadcast to all users; from + experience, this is abused more than used responsibly and properly. + Wildcards are the '*' and '?' characters. This extension to + the PRIVMSG command is only available to Operators. + + Numeric Replies: + + ERR_NORECIPIENT ERR_NOTEXTTOSEND + ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL + ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS + ERR_NOSUCHNICK + RPL_AWAY + + Examples: + +:Angel PRIVMSG Wiz :Hello are you receiving this message ? + ; Message from Angel to Wiz. + +PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ; + Message to Angel. + +PRIVMSG jto@tolsun.oulu.fi :Hello ! + ; Message to a client on server + + + +Oikarinen & Reed [Page 32] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + tolsun.oulu.fi with username of "jto". + +PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. + ; Message to everyone on a server which + has a name matching *.fi. + +PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions + ; Message to all users who come from a + host which has a name matching *.edu. + +4.4.2 Notice + + Command: NOTICE + Parameters: <nickname> <text> + + The NOTICE message is used similarly to PRIVMSG. The difference + between NOTICE and PRIVMSG is that automatic replies must never be + sent in response to a NOTICE message. This rule applies to servers + too - they must not send any error reply back to the client on + receipt of a notice. The object of this rule is to avoid loops + between a client automatically sending something in response to + something it received. This is typically used by automatons (clients + with either an AI or other interactive program controlling their + actions) which are always seen to be replying lest they end up in a + loop with another automaton. + + See PRIVMSG for more details on replies and examples. + +4.5 User based queries + + User queries are a group of commands which are primarily concerned + with finding details on a particular user or group users. When using + wildcards with any of these commands, if they match, they will only + return information on users who are 'visible' to you. The visibility + of a user is determined as a combination of the user's mode and the + common set of channels you are both on. + +4.5.1 Who query + + Command: WHO + Parameters: [<name> [<o>]] + + The WHO message is used by a client to generate a query which returns + a list of information which 'matches' the <name> parameter given by + the client. In the absence of the <name> parameter, all visible + (users who aren't invisible (user mode +i) and who don't have a + common channel with the requesting client) are listed. The same + result can be achieved by using a <name> of "0" or any wildcard which + + + +Oikarinen & Reed [Page 33] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + will end up matching every entry possible. + + The <name> passed to WHO is matched against users' host, server, real + name and nickname if the channel <name> cannot be found. + + If the "o" parameter is passed only operators are returned according + to the name mask supplied. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_WHOREPLY RPL_ENDOFWHO + + Examples: + + WHO *.fi ; List all users who match against + "*.fi". + + WHO jto* o ; List all users with a match against + "jto*" if they are an operator. + +4.5.2 Whois query + + Command: WHOIS + Parameters: [<server>] <nickmask>[,<nickmask>[,...]] + + This message is used to query information about particular user. The + server will answer this message with several numeric messages + indicating different statuses of each user which matches the nickmask + (if you are entitled to see them). If no wildcard is present in the + <nickmask>, any information about that nick which you are allowed to + see is presented. A comma (',') separated list of nicknames may be + given. + + The latter version sends the query to a specific server. It is + useful if you want to know how long the user in question has been + idle as only local server (ie. the server the user is directly + connected to) knows that information, while everything else is + globally known. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN + RPL_WHOISUSER RPL_WHOISCHANNELS + RPL_WHOISCHANNELS RPL_WHOISSERVER + RPL_AWAY RPL_WHOISOPERATOR + RPL_WHOISIDLE ERR_NOSUCHNICK + RPL_ENDOFWHOIS + + + +Oikarinen & Reed [Page 34] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Examples: + + WHOIS wiz ; return available user information + about nick WiZ + + WHOIS eff.org trillian ; ask server eff.org for user + information about trillian + +4.5.3 Whowas + + Command: WHOWAS + Parameters: <nickname> [<count> [<server>]] + + Whowas asks for information about a nickname which no longer exists. + This may either be due to a nickname change or the user leaving IRC. + In response to this query, the server searches through its nickname + history, looking for any nicks which are lexically the same (no wild + card matching here). The history is searched backward, returning the + most recent entry first. If there are multiple entries, up to + <count> replies will be returned (or all of them if no <count> + parameter is given). If a non-positive number is passed as being + <count>, then a full search is done. + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK + RPL_WHOWASUSER RPL_WHOISSERVER + RPL_ENDOFWHOWAS + + Examples: + + WHOWAS Wiz ; return all information in the nick + history about nick "WiZ"; + + WHOWAS Mermaid 9 ; return at most, the 9 most recent + entries in the nick history for + "Mermaid"; + + WHOWAS Trillian 1 *.edu ; return the most recent history for + "Trillian" from the first server found + to match "*.edu". + +4.6 Miscellaneous messages + + Messages in this category do not fit into any of the above categories + but are nonetheless still a part of and required by the protocol. + + + + + +Oikarinen & Reed [Page 35] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +4.6.1 Kill message + + Command: KILL + Parameters: <nickname> <comment> + + The KILL message is used to cause a client-server connection to be + closed by the server which has the actual connection. KILL is used + by servers when they encounter a duplicate entry in the list of valid + nicknames and is used to remove both entries. It is also available + to operators. + + Clients which have automatic reconnect algorithms effectively make + this command useless since the disconnection is only brief. It does + however break the flow of data and can be used to stop large amounts + of being abused, any user may elect to receive KILL messages + generated for others to keep an 'eye' on would be trouble spots. + + In an arena where nicknames are required to be globally unique at all + times, KILL messages are sent whenever 'duplicates' are detected + (that is an attempt to register two users with the same nickname) in + the hope that both of them will disappear and only 1 reappear. + + The comment given must reflect the actual reason for the KILL. For + server-generated KILLs it usually is made up of details concerning + the origins of the two conflicting nicknames. For users it is left + up to them to provide an adequate reason to satisfy others who see + it. To prevent/discourage fake KILLs from being generated to hide + the identify of the KILLer, the comment also shows a 'kill-path' + which is updated by each server it passes through, each prepending + its name to the path. + + Numeric Replies: + + ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS + ERR_NOSUCHNICK ERR_CANTKILLSERVER + + + KILL David (csd.bu.edu <- tolsun.oulu.fi) + ; Nickname collision between csd.bu.edu + and tolson.oulu.fi + + + NOTE: + It is recommended that only Operators be allowed to kill other users + with KILL message. In an ideal world not even operators would need + to do this and it would be left to servers to deal with. + + + + + +Oikarinen & Reed [Page 36] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +4.6.2 Ping message + + Command: PING + Parameters: <server1> [<server2>] + + The PING message is used to test the presence of an active client at + the other end of the connection. A PING message is sent at regular + intervals if no other activity detected coming from a connection. If + a connection fails to respond to a PING command within a set amount + of time, that connection is closed. + + Any client which receives a PING message must respond to <server1> + (server which sent the PING message out) as quickly as possible with + an appropriate PONG message to indicate it is still there and alive. + Servers should not respond to PING commands but rely on PINGs from + the other end of the connection to indicate the connection is alive. + If the <server2> parameter is specified, the PING message gets + forwarded there. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Examples: + + PING tolsun.oulu.fi ; server sending a PING message to + another server to indicate it is still + alive. + + PING WiZ ; PING message being sent to nick WiZ + +4.6.3 Pong message + + Command: PONG + Parameters: <daemon> [<daemon2>] + + PONG message is a reply to ping message. If parameter <daemon2> is + given this message must be forwarded to given daemon. The <daemon> + parameter is the name of the daemon who has responded to PING message + and generated this message. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Examples: + + PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to + + + +Oikarinen & Reed [Page 37] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + tolsun.oulu.fi + +4.6.4 Error + + Command: ERROR + Parameters: <error message> + + The ERROR command is for use by servers when reporting a serious or + fatal error to its operators. It may also be sent from one server to + another but must not be accepted from any normal unknown clients. + + An ERROR message is for use for reporting errors which occur with a + server-to-server link only. An ERROR message is sent to the server + at the other end (which sends it to all of its connected operators) + and to all operators currently connected. It is not to be passed + onto any other servers by a server if it is received from a server. + + When a server sends a received ERROR message to its operators, the + message should be encapsulated inside a NOTICE message, indicating + that the client was not responsible for the error. + + Numerics: + + None. + + Examples: + + ERROR :Server *.fi already exists; ERROR message to the other server + which caused this error. + + NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists + ; Same ERROR message as above but sent + to user WiZ on the other server. + +5. OPTIONALS + + This section describes OPTIONAL messages. They are not required in a + working server implementation of the protocol described herein. In + the absence of the option, an error reply message must be generated + or an unknown command error. If the message is destined for another + server to answer then it must be passed on (elementary parsing + required) The allocated numerics for this are listed with the + messages below. + +5.1 Away + + Command: AWAY + Parameters: [message] + + + +Oikarinen & Reed [Page 38] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + With the AWAY message, clients can set an automatic reply string for + any PRIVMSG commands directed at them (not to a channel they are on). + The automatic reply is sent by the server to client sending the + PRIVMSG command. The only replying server is the one to which the + sending client is connected to. + + The AWAY message is used either with one parameter (to set an AWAY + message) or with no parameters (to remove the AWAY message). + + Numeric Replies: + + RPL_UNAWAY RPL_NOWAWAY + + Examples: + + AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch. + Back in 5". + + :WiZ AWAY ; unmark WiZ as being away. + + +5.2 Rehash message + + Command: REHASH + Parameters: None + + The rehash message can be used by the operator to force the server to + re-read and process its configuration file. + + Numeric Replies: + + RPL_REHASHING ERR_NOPRIVILEGES + +Examples: + +REHASH ; message from client with operator + status to server asking it to reread its + configuration file. + +5.3 Restart message + + Command: RESTART + Parameters: None + + The restart message can only be used by an operator to force a server + restart itself. This message is optional since it may be viewed as a + risk to allow arbitrary people to connect to a server as an operator + and execute this command, causing (at least) a disruption to service. + + + +Oikarinen & Reed [Page 39] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The RESTART command must always be fully processed by the server to + which the sending client is connected and not be passed onto other + connected servers. + + Numeric Replies: + + ERR_NOPRIVILEGES + + Examples: + + RESTART ; no parameters required. + +5.4 Summon message + + Command: SUMMON + Parameters: <user> [<server>] + + The SUMMON command can be used to give users who are on a host + running an IRC server a message asking them to please join IRC. This + message is only sent if the target server (a) has SUMMON enabled, (b) + the user is logged in and (c) the server process can write to the + user's tty (or similar). + + If no <server> parameter is given it tries to summon <user> from the + server the client is connected to is assumed as the target. + + If summon is not enabled in a server, it must return the + ERR_SUMMONDISABLED numeric and pass the summon message onwards. + + Numeric Replies: + + ERR_NORECIPIENT ERR_FILEERROR + ERR_NOLOGIN ERR_NOSUCHSERVER + RPL_SUMMONING + + Examples: + + SUMMON jto ; summon user jto on the server's host + + SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a + server named "tolsun.oulu.fi" is + running. + + +5.5 Users + + Command: USERS + Parameters: [<server>] + + + +Oikarinen & Reed [Page 40] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The USERS command returns a list of users logged into the server in a + similar format to who(1), rusers(1) and finger(1). Some people + may disable this command on their server for security related + reasons. If disabled, the correct numeric must be returned to + indicate this. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_FILEERROR + RPL_USERSSTART RPL_USERS + RPL_NOUSERS RPL_ENDOFUSERS + ERR_USERSDISABLED + + Disabled Reply: + + ERR_USERSDISABLED + + Examples: + +USERS eff.org ; request a list of users logged in on + server eff.org + +:John USERS tolsun.oulu.fi ; request from John for a list of users + logged in on server tolsun.oulu.fi + +5.6 Operwall message + + Command: WALLOPS + Parameters: Text to be sent to all operators currently online + + Sends a message to all operators currently online. After + implementing WALLOPS as a user command it was found that it was + often and commonly abused as a means of sending a message to a lot + of people (much similar to WALL). Due to this it is recommended + that the current implementation of WALLOPS be used as an + example by allowing and recognising only servers as the senders of + WALLOPS. + + Numeric Replies: + + ERR_NEEDMOREPARAMS + + Examples: + + :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS + message from csd.bu.edu announcing a + CONNECT message it received and acted + upon from Joshua. + + + +Oikarinen & Reed [Page 41] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +5.7 Userhost message + + Command: USERHOST + Parameters: <nickname>{<space><nickname>} + + The USERHOST command takes a list of up to 5 nicknames, each + separated by a space character and returns a list of information + about each nickname that it found. The returned list has each reply + separated by a space. + + Numeric Replies: + + RPL_USERHOST ERR_NEEDMOREPARAMS + + Examples: + + USERHOST Wiz Michael Marty p ;USERHOST request for information on + nicks "Wiz", "Michael", "Marty" and "p" + +5.8 Ison message + + Command: ISON + Parameters: <nickname>{<space><nickname>} + + The ISON command was implemented to provide a quick and efficient + means to get a response about whether a given nickname was currently + on IRC. ISON only takes one (1) parameter: a space-separated list of + nicks. For each nickname in the list that is present, the server + adds that to its reply string. Thus the reply string may return + empty (none of the given nicks are present), an exact copy of the + parameter string (all of them present) or as any other subset of the + set of nicks given in the parameter. The only limit on the number + of nicks that may be checked is that the combined length must not be + too large as to cause the server to chop it off so it fits in 512 + characters. + + ISON is only be processed by the server local to the client sending + the command and thus not passed onto other servers for further + processing. + + Numeric Replies: + + RPL_ISON ERR_NEEDMOREPARAMS + + Examples: + + ISON phone trillian WiZ jarlek Avalon Angel Monstah + ; Sample ISON request for 7 nicks. + + + +Oikarinen & Reed [Page 42] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +6. REPLIES + + The following is a list of numeric replies which are generated in + response to the commands given above. Each numeric is given with its + number, name and reply string. + +6.1 Error Replies. + + 401 ERR_NOSUCHNICK + "<nickname> :No such nick/channel" + + - Used to indicate the nickname parameter supplied to a + command is currently unused. + + 402 ERR_NOSUCHSERVER + "<server name> :No such server" + + - Used to indicate the server name given currently + doesn't exist. + + 403 ERR_NOSUCHCHANNEL + "<channel name> :No such channel" + + - Used to indicate the given channel name is invalid. + + 404 ERR_CANNOTSENDTOCHAN + "<channel name> :Cannot send to channel" + + - Sent to a user who is either (a) not on a channel + which is mode +n or (b) not a chanop (or mode +v) on + a channel which has mode +m set and is trying to send + a PRIVMSG message to that channel. + + 405 ERR_TOOMANYCHANNELS + "<channel name> :You have joined too many \ + channels" + - Sent to a user when they have joined the maximum + number of allowed channels and they try to join + another channel. + + 406 ERR_WASNOSUCHNICK + "<nickname> :There was no such nickname" + + - Returned by WHOWAS to indicate there is no history + information for that nickname. + + 407 ERR_TOOMANYTARGETS + "<target> :Duplicate recipients. No message \ + + + +Oikarinen & Reed [Page 43] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + delivered" + + - Returned to a client which is attempting to send a + PRIVMSG/NOTICE using the user@host destination format + and for a user@host which has several occurrences. + + 409 ERR_NOORIGIN + ":No origin specified" + + - PING or PONG message missing the originator parameter + which is required since these commands must work + without valid prefixes. + + 411 ERR_NORECIPIENT + ":No recipient given (<command>)" + 412 ERR_NOTEXTTOSEND + ":No text to send" + 413 ERR_NOTOPLEVEL + "<mask> :No toplevel domain specified" + 414 ERR_WILDTOPLEVEL + "<mask> :Wildcard in toplevel domain" + + - 412 - 414 are returned by PRIVMSG to indicate that + the message wasn't delivered for some reason. + ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that + are returned when an invalid use of + "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted. + + 421 ERR_UNKNOWNCOMMAND + "<command> :Unknown command" + + - Returned to a registered client to indicate that the + command sent is unknown by the server. + + 422 ERR_NOMOTD + ":MOTD File is missing" + + - Server's MOTD file could not be opened by the server. + + 423 ERR_NOADMININFO + "<server> :No administrative info available" + + - Returned by a server in response to an ADMIN message + when there is an error in finding the appropriate + information. + + 424 ERR_FILEERROR + ":File error doing <file op> on <file>" + + + +Oikarinen & Reed [Page 44] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + - Generic error message used to report a failed file + operation during the processing of a message. + + 431 ERR_NONICKNAMEGIVEN + ":No nickname given" + + - Returned when a nickname parameter expected for a + command and isn't found. + + 432 ERR_ERRONEUSNICKNAME + "<nick> :Erroneus nickname" + + - Returned after receiving a NICK message which contains + characters which do not fall in the defined set. See + section x.x.x for details on valid nicknames. + + 433 ERR_NICKNAMEINUSE + "<nick> :Nickname is already in use" + + - Returned when a NICK message is processed that results + in an attempt to change to a currently existing + nickname. + + 436 ERR_NICKCOLLISION + "<nick> :Nickname collision KILL" + + - Returned by a server to a client when it detects a + nickname collision (registered of a NICK that + already exists by another server). + + 441 ERR_USERNOTINCHANNEL + "<nick> <channel> :They aren't on that channel" + + - Returned by the server to indicate that the target + user of the command is not on the given channel. + + 442 ERR_NOTONCHANNEL + "<channel> :You're not on that channel" + + - Returned by the server whenever a client tries to + perform a channel effecting command for which the + client isn't a member. + + 443 ERR_USERONCHANNEL + "<user> <channel> :is already on channel" + + - Returned when a client tries to invite a user to a + channel they are already on. + + + +Oikarinen & Reed [Page 45] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 444 ERR_NOLOGIN + "<user> :User not logged in" + + - Returned by the summon after a SUMMON command for a + user was unable to be performed since they were not + logged in. + + 445 ERR_SUMMONDISABLED + ":SUMMON has been disabled" + + - Returned as a response to the SUMMON command. Must be + returned by any server which does not implement it. + + 446 ERR_USERSDISABLED + ":USERS has been disabled" + + - Returned as a response to the USERS command. Must be + returned by any server which does not implement it. + + 451 ERR_NOTREGISTERED + ":You have not registered" + + - Returned by the server to indicate that the client + must be registered before the server will allow it + to be parsed in detail. + + 461 ERR_NEEDMOREPARAMS + "<command> :Not enough parameters" + + - Returned by the server by numerous commands to + indicate to the client that it didn't supply enough + parameters. + + 462 ERR_ALREADYREGISTRED + ":You may not reregister" + + - Returned by the server to any link which tries to + change part of the registered details (such as + password or user details from second USER message). + + + 463 ERR_NOPERMFORHOST + ":Your host isn't among the privileged" + + - Returned to a client which attempts to register with + a server which does not been setup to allow + connections from the host the attempted connection + is tried. + + + +Oikarinen & Reed [Page 46] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 464 ERR_PASSWDMISMATCH + ":Password incorrect" + + - Returned to indicate a failed attempt at registering + a connection for which a password was required and + was either not given or incorrect. + + 465 ERR_YOUREBANNEDCREEP + ":You are banned from this server" + + - Returned after an attempt to connect and register + yourself with a server which has been setup to + explicitly deny connections to you. + + 467 ERR_KEYSET + "<channel> :Channel key already set" + 471 ERR_CHANNELISFULL + "<channel> :Cannot join channel (+l)" + 472 ERR_UNKNOWNMODE + "<char> :is unknown mode char to me" + 473 ERR_INVITEONLYCHAN + "<channel> :Cannot join channel (+i)" + 474 ERR_BANNEDFROMCHAN + "<channel> :Cannot join channel (+b)" + 475 ERR_BADCHANNELKEY + "<channel> :Cannot join channel (+k)" + 481 ERR_NOPRIVILEGES + ":Permission Denied- You're not an IRC operator" + + - Any command requiring operator privileges to operate + must return this error to indicate the attempt was + unsuccessful. + + 482 ERR_CHANOPRIVSNEEDED + "<channel> :You're not channel operator" + + - Any command requiring 'chanop' privileges (such as + MODE messages) must return this error if the client + making the attempt is not a chanop on the specified + channel. + + 483 ERR_CANTKILLSERVER + ":You cant kill a server!" + + - Any attempts to use the KILL command on a server + are to be refused and this error returned directly + to the client. + + + + +Oikarinen & Reed [Page 47] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 491 ERR_NOOPERHOST + ":No O-lines for your host" + + - If a client sends an OPER message and the server has + not been configured to allow connections from the + client's host as an operator, this error must be + returned. + + 501 ERR_UMODEUNKNOWNFLAG + ":Unknown MODE flag" + + - Returned by the server to indicate that a MODE + message was sent with a nickname parameter and that + the a mode flag sent was not recognized. + + 502 ERR_USERSDONTMATCH + ":Cant change mode for other users" + + - Error sent to any user trying to view or change the + user mode for a user other than themselves. + +6.2 Command responses. + + 300 RPL_NONE + Dummy reply number. Not used. + + 302 RPL_USERHOST + ":[<reply>{<space><reply>}]" + + - Reply format used by USERHOST to list replies to + the query list. The reply string is composed as + follows: + + <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname> + + The '*' indicates whether the client has registered + as an Operator. The '-' or '+' characters represent + whether the client has set an AWAY message or not + respectively. + + 303 RPL_ISON + ":[<nick> {<space><nick>}]" + + - Reply format used by ISON to list replies to the + query list. + + 301 RPL_AWAY + "<nick> :<away message>" + + + +Oikarinen & Reed [Page 48] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 305 RPL_UNAWAY + ":You are no longer marked as being away" + 306 RPL_NOWAWAY + ":You have been marked as being away" + + - These replies are used with the AWAY command (if + allowed). RPL_AWAY is sent to any client sending a + PRIVMSG to a client which is away. RPL_AWAY is only + sent by the server to which the client is connected. + Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the + client removes and sets an AWAY message. + + 311 RPL_WHOISUSER + "<nick> <user> <host> * :<real name>" + 312 RPL_WHOISSERVER + "<nick> <server> :<server info>" + 313 RPL_WHOISOPERATOR + "<nick> :is an IRC operator" + 317 RPL_WHOISIDLE + "<nick> <integer> :seconds idle" + 318 RPL_ENDOFWHOIS + "<nick> :End of /WHOIS list" + 319 RPL_WHOISCHANNELS + "<nick> :{[@|+]<channel><space>}" + + - Replies 311 - 313, 317 - 319 are all replies + generated in response to a WHOIS message. Given that + there are enough parameters present, the answering + server must either formulate a reply out of the above + numerics (if the query nick is found) or return an + error reply. The '*' in RPL_WHOISUSER is there as + the literal character and not as a wild card. For + each reply set, only RPL_WHOISCHANNELS may appear + more than once (for long lists of channel names). + The '@' and '+' characters next to the channel name + indicate whether a client is a channel operator or + has been granted permission to speak on a moderated + channel. The RPL_ENDOFWHOIS reply is used to mark + the end of processing a WHOIS message. + + 314 RPL_WHOWASUSER + "<nick> <user> <host> * :<real name>" + 369 RPL_ENDOFWHOWAS + "<nick> :End of WHOWAS" + + - When replying to a WHOWAS message, a server must use + the replies RPL_WHOWASUSER, RPL_WHOISSERVER or + ERR_WASNOSUCHNICK for each nickname in the presented + + + +Oikarinen & Reed [Page 49] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + list. At the end of all reply batches, there must + be RPL_ENDOFWHOWAS (even if there was only one reply + and it was an error). + + 321 RPL_LISTSTART + "Channel :Users Name" + 322 RPL_LIST + "<channel> <# visible> :<topic>" + 323 RPL_LISTEND + ":End of /LIST" + + - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark + the start, actual replies with data and end of the + server's response to a LIST command. If there are + no channels available to return, only the start + and end reply must be sent. + + 324 RPL_CHANNELMODEIS + "<channel> <mode> <mode params>" + + 331 RPL_NOTOPIC + "<channel> :No topic is set" + 332 RPL_TOPIC + "<channel> :<topic>" + + - When sending a TOPIC message to determine the + channel topic, one of two replies is sent. If + the topic is set, RPL_TOPIC is sent back else + RPL_NOTOPIC. + + 341 RPL_INVITING + "<channel> <nick>" + + - Returned by the server to indicate that the + attempted INVITE message was successful and is + being passed onto the end client. + + 342 RPL_SUMMONING + "<user> :Summoning user to IRC" + + - Returned by a server answering a SUMMON message to + indicate that it is summoning that user. + + 351 RPL_VERSION + "<version>.<debuglevel> <server> :<comments>" + + - Reply by the server showing its version details. + The <version> is the version of the software being + + + +Oikarinen & Reed [Page 50] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + used (including any patchlevel revisions) and the + <debuglevel> is used to indicate if the server is + running in "debug mode". + + The "comments" field may contain any comments about + the version or further version details. + + 352 RPL_WHOREPLY + "<channel> <user> <host> <server> <nick> \ + <H|G>[*][@|+] :<hopcount> <real name>" + 315 RPL_ENDOFWHO + "<name> :End of /WHO list" + + - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used + to answer a WHO message. The RPL_WHOREPLY is only + sent if there is an appropriate match to the WHO + query. If there is a list of parameters supplied + with a WHO message, a RPL_ENDOFWHO must be sent + after processing each list item with <name> being + the item. + + 353 RPL_NAMREPLY + "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]" + 366 RPL_ENDOFNAMES + "<channel> :End of /NAMES list" + + - To reply to a NAMES message, a reply pair consisting + of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the + server back to the client. If there is no channel + found as in the query, then only RPL_ENDOFNAMES is + returned. The exception to this is when a NAMES + message is sent with no parameters and all visible + channels and contents are sent back in a series of + RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark + the end. + + 364 RPL_LINKS + "<mask> <server> :<hopcount> <server info>" + 365 RPL_ENDOFLINKS + "<mask> :End of /LINKS list" + + - In replying to the LINKS message, a server must send + replies back using the RPL_LINKS numeric and mark the + end of the list using an RPL_ENDOFLINKS reply. + + 367 RPL_BANLIST + "<channel> <banid>" + 368 RPL_ENDOFBANLIST + + + +Oikarinen & Reed [Page 51] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + "<channel> :End of channel ban list" + + - When listing the active 'bans' for a given channel, + a server is required to send the list back using the + RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate + RPL_BANLIST is sent for each active banid. After the + banids have been listed (or if none present) a + RPL_ENDOFBANLIST must be sent. + + 371 RPL_INFO + ":<string>" + 374 RPL_ENDOFINFO + ":End of /INFO list" + + - A server responding to an INFO message is required to + send all its 'info' in a series of RPL_INFO messages + with a RPL_ENDOFINFO reply to indicate the end of the + replies. + + 375 RPL_MOTDSTART + ":- <server> Message of the day - " + 372 RPL_MOTD + ":- <text>" + 376 RPL_ENDOFMOTD + ":End of /MOTD command" + + - When responding to the MOTD message and the MOTD file + is found, the file is displayed line by line, with + each line no longer than 80 characters, using + RPL_MOTD format replies. These should be surrounded + by a RPL_MOTDSTART (before the RPL_MOTDs) and an + RPL_ENDOFMOTD (after). + + 381 RPL_YOUREOPER + ":You are now an IRC operator" + + - RPL_YOUREOPER is sent back to a client which has + just successfully issued an OPER message and gained + operator status. + + 382 RPL_REHASHING + "<config file> :Rehashing" + + - If the REHASH option is used and an operator sends + a REHASH message, an RPL_REHASHING is sent back to + the operator. + + 391 RPL_TIME + + + +Oikarinen & Reed [Page 52] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + "<server> :<string showing server's local time>" + + - When replying to the TIME message, a server must send + the reply using the RPL_TIME format above. The string + showing the time need only contain the correct day and + time there. There is no further requirement for the + time string. + + 392 RPL_USERSSTART + ":UserID Terminal Host" + 393 RPL_USERS + ":%-8s %-9s %-8s" + 394 RPL_ENDOFUSERS + ":End of users" + 395 RPL_NOUSERS + ":Nobody logged in" + + - If the USERS message is handled by a server, the + replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and + RPL_NOUSERS are used. RPL_USERSSTART must be sent + first, following by either a sequence of RPL_USERS + or a single RPL_NOUSER. Following this is + RPL_ENDOFUSERS. + + 200 RPL_TRACELINK + "Link <version & debug level> <destination> \ + <next server>" + 201 RPL_TRACECONNECTING + "Try. <class> <server>" + 202 RPL_TRACEHANDSHAKE + "H.S. <class> <server>" + 203 RPL_TRACEUNKNOWN + "???? <class> [<client IP address in dot form>]" + 204 RPL_TRACEOPERATOR + "Oper <class> <nick>" + 205 RPL_TRACEUSER + "User <class> <nick>" + 206 RPL_TRACESERVER + "Serv <class> <int>S <int>C <server> \ + <nick!user|*!*>@<host|server>" + 208 RPL_TRACENEWTYPE + "<newtype> 0 <client name>" + 261 RPL_TRACELOG + "File <logfile> <debug level>" + + - The RPL_TRACE* are all returned by the server in + response to the TRACE message. How many are + returned is dependent on the the TRACE message and + + + +Oikarinen & Reed [Page 53] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + whether it was sent by an operator or not. There + is no predefined order for which occurs first. + Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and + RPL_TRACEHANDSHAKE are all used for connections + which have not been fully established and are either + unknown, still attempting to connect or in the + process of completing the 'server handshake'. + RPL_TRACELINK is sent by any server which handles + a TRACE message and has to pass it on to another + server. The list of RPL_TRACELINKs sent in + response to a TRACE command traversing the IRC + network should reflect the actual connectivity of + the servers themselves along that path. + RPL_TRACENEWTYPE is to be used for any connection + which does not fit in the other categories but is + being displayed anyway. + + 211 RPL_STATSLINKINFO + "<linkname> <sendq> <sent messages> \ + <sent bytes> <received messages> \ + <received bytes> <time open>" + 212 RPL_STATSCOMMANDS + "<command> <count>" + 213 RPL_STATSCLINE + "C <host> * <name> <port> <class>" + 214 RPL_STATSNLINE + "N <host> * <name> <port> <class>" + 215 RPL_STATSILINE + "I <host> * <host> <port> <class>" + 216 RPL_STATSKLINE + "K <host> * <username> <port> <class>" + 218 RPL_STATSYLINE + "Y <class> <ping frequency> <connect \ + frequency> <max sendq>" + 219 RPL_ENDOFSTATS + "<stats letter> :End of /STATS report" + 241 RPL_STATSLLINE + "L <hostmask> * <servername> <maxdepth>" + 242 RPL_STATSUPTIME + ":Server Up %d days %d:%02d:%02d" + 243 RPL_STATSOLINE + "O <hostmask> * <name>" + 244 RPL_STATSHLINE + "H <hostmask> * <servername>" + + 221 RPL_UMODEIS + "<user mode string>" + + + + +Oikarinen & Reed [Page 54] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + - To answer a query about a client's own mode, + RPL_UMODEIS is sent back. + + 251 RPL_LUSERCLIENT + ":There are <integer> users and <integer> \ + invisible on <integer> servers" + 252 RPL_LUSEROP + "<integer> :operator(s) online" + 253 RPL_LUSERUNKNOWN + "<integer> :unknown connection(s)" + 254 RPL_LUSERCHANNELS + "<integer> :channels formed" + 255 RPL_LUSERME + ":I have <integer> clients and <integer> \ + servers" + + - In processing an LUSERS message, the server + sends a set of replies from RPL_LUSERCLIENT, + RPL_LUSEROP, RPL_USERUNKNOWN, + RPL_LUSERCHANNELS and RPL_LUSERME. When + replying, a server must send back + RPL_LUSERCLIENT and RPL_LUSERME. The other + replies are only sent back if a non-zero count + is found for them. + + 256 RPL_ADMINME + "<server> :Administrative info" + 257 RPL_ADMINLOC1 + ":<admin info>" + 258 RPL_ADMINLOC2 + ":<admin info>" + 259 RPL_ADMINEMAIL + ":<admin info>" + + - When replying to an ADMIN message, a server + is expected to use replies RLP_ADMINME + through to RPL_ADMINEMAIL and provide a text + message with each. For RPL_ADMINLOC1 a + description of what city, state and country + the server is in is expected, followed by + details of the university and department + (RPL_ADMINLOC2) and finally the administrative + contact for the server (an email address here + is required) in RPL_ADMINEMAIL. + + + + + + + +Oikarinen & Reed [Page 55] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +6.3 Reserved numerics. + + These numerics are not described above since they fall into one of + the following categories: + + 1. no longer in use; + + 2. reserved for future planned use; + + 3. in current use but are part of a non-generic 'feature' of + the current IRC server. + + 209 RPL_TRACECLASS 217 RPL_STATSQLINE + 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES + 233 RPL_SERVICE 234 RPL_SERVLIST + 235 RPL_SERVLISTEND + 316 RPL_WHOISCHANOP 361 RPL_KILLDONE + 362 RPL_CLOSING 363 RPL_CLOSEEND + 373 RPL_INFOSTART 384 RPL_MYPORTIS + 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK + 492 ERR_NOSERVICEHOST + +7. Client and server authentication + + Clients and servers are both subject to the same level of + authentication. For both, an IP number to hostname lookup (and + reverse check on this) is performed for all connections made to the + server. Both connections are then subject to a password check (if + there is a password set for that connection). These checks are + possible on all connections although the password check is only + commonly used with servers. + + An additional check that is becoming of more and more common is that + of the username responsible for making the connection. Finding the + username of the other end of the connection typically involves + connecting to an authentication server such as IDENT as described in + RFC 1413. + + Given that without passwords it is not easy to reliably determine who + is on the other end of a network connection, use of passwords is + strongly recommended on inter-server connections in addition to any + other measures such as using an ident server. + +8. Current implementations + + The only current implementation of this protocol is the IRC server, + version 2.8. Earlier versions may implement some or all of the + commands described by this document with NOTICE messages replacing + + + +Oikarinen & Reed [Page 56] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + many of the numeric replies. Unfortunately, due to backward + compatibility requirements, the implementation of some parts of this + document varies with what is laid out. On notable difference is: + + * recognition that any LF or CR anywhere in a message marks the + end of that message (instead of requiring CR-LF); + + The rest of this section deals with issues that are mostly of + importance to those who wish to implement a server but some parts + also apply directly to clients as well. + +8.1 Network protocol: TCP - why it is best used here. + + IRC has been implemented on top of TCP since TCP supplies a reliable + network protocol which is well suited to this scale of conferencing. + The use of multicast IP is an alternative, but it is not widely + available or supported at the present time. + +8.1.1 Support of Unix sockets + + Given that Unix domain sockets allow listen/connect operations, the + current implementation can be configured to listen and accept both + client and server connections on a Unix domain socket. These are + recognized as sockets where the hostname starts with a '/'. + + When providing any information about the connections on a Unix domain + socket, the server is required to supplant the actual hostname in + place of the pathname unless the actual socket name is being asked + for. + +8.2 Command Parsing + + To provide useful 'non-buffered' network IO for clients and servers, + each connection is given its own private 'input buffer' in which the + results of the most recent read and parsing are kept. A buffer size + of 512 bytes is used so as to hold 1 full message, although, this + will usually hold several commands. The private buffer is parsed + after every read operation for valid messages. When dealing with + multiple messages from one client in the buffer, care should be taken + in case one happens to cause the client to be 'removed'. + +8.3 Message delivery + + It is common to find network links saturated or hosts to which you + are sending data unable to send data. Although Unix typically + handles this through the TCP window and internal buffers, the server + often has large amounts of data to send (especially when a new + server-server link forms) and the small buffers provided in the + + + +Oikarinen & Reed [Page 57] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + kernel are not enough for the outgoing queue. To alleviate this + problem, a "send queue" is used as a FIFO queue for data to be sent. + A typical "send queue" may grow to 200 Kbytes on a large IRC network + with a slow network connection when a new server connects. + + When polling its connections, a server will first read and parse all + incoming data, queuing any data to be sent out. When all available + input is processed, the queued data is sent. This reduces the number + of write() system calls and helps TCP make bigger packets. + +8.4 Connection 'Liveness' + + To detect when a connection has died or become unresponsive, the + server must ping each of its connections that it doesn't get a + response from in a given amount of time. + + If a connection doesn't respond in time, its connection is closed + using the appropriate procedures. A connection is also dropped if + its sendq grows beyond the maximum allowed, because it is better to + close a slow connection than have a server process block. + +8.5 Establishing a server to client connection + + Upon connecting to an IRC server, a client is sent the MOTD (if + present) as well as the current user/server count (as per the LUSER + command). The server is also required to give an unambiguous message + to the client which states its name and version as well as any other + introductory messages which may be deemed appropriate. + + After dealing with this, the server must then send out the new user's + nickname and other information as supplied by itself (USER command) + and as the server could discover (from DNS/authentication servers). + The server must send this information out with NICK first followed by + USER. + +8.6 Establishing a server-server connection. + + The process of establishing of a server-to-server connection is + fraught with danger since there are many possible areas where + problems can occur - the least of which are race conditions. + + After a server has received a connection following by a PASS/SERVER + pair which were recognised as being valid, the server should then + reply with its own PASS/SERVER information for that connection as + well as all of the other state information it knows about as + described below. + + When the initiating server receives a PASS/SERVER pair, it too then + + + +Oikarinen & Reed [Page 58] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + checks that the server responding is authenticated properly before + accepting the connection to be that server. + +8.6.1 Server exchange of state information when connecting + + The order of state information being exchanged between servers is + essential. The required order is as follows: + + * all known other servers; + + * all known user information; + + * all known channel information. + + Information regarding servers is sent via extra SERVER messages, user + information with NICK/USER/MODE/JOIN messages and channels with MODE + messages. + + NOTE: channel topics are *NOT* exchanged here because the TOPIC + command overwrites any old topic information, so at best, the two + sides of the connection would exchange topics. + + By passing the state information about servers first, any collisions + with servers that already exist occur before nickname collisions due + to a second server introducing a particular nickname. Due to the IRC + network only being able to exist as an acyclic graph, it may be + possible that the network has already reconnected in another + location, the place where the collision occurs indicating where the + net needs to split. + +8.7 Terminating server-client connections + + When a client connection closes, a QUIT message is generated on + behalf of the client by the server to which the client connected. No + other message is to be generated or used. + +8.8 Terminating server-server connections + + If a server-server connection is closed, either via a remotely + generated SQUIT or 'natural' causes, the rest of the connected IRC + network must have its information updated with by the server which + detected the closure. The server then sends a list of SQUITs (one + for each server behind that connection) and a list of QUITs (again, + one for each client behind that connection). + + + + + + + +Oikarinen & Reed [Page 59] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +8.9 Tracking nickname changes + + All IRC servers are required to keep a history of recent nickname + changes. This is required to allow the server to have a chance of + keeping in touch of things when nick-change race conditions occur + with commands which manipulate them. Commands which must trace nick + changes are: + + * KILL (the nick being killed) + + * MODE (+/- o,v) + + * KICK (the nick being kicked) + + No other commands are to have nick changes checked for. + + In the above cases, the server is required to first check for the + existence of the nickname, then check its history to see who that + nick currently belongs to (if anyone!). This reduces the chances of + race conditions but they can still occur with the server ending up + affecting the wrong client. When performing a change trace for an + above command it is recommended that a time range be given and + entries which are too old ignored. + + For a reasonable history, a server should be able to keep previous + nickname for every client it knows about if they all decided to + change. This size is limited by other factors (such as memory, etc). + +8.10 Flood control of clients + + With a large network of interconnected IRC servers, it is quite easy + for any single client attached to the network to supply a continuous + stream of messages that result in not only flooding the network, but + also degrading the level of service provided to others. Rather than + require every 'victim' to be provide their own protection, flood + protection was written into the server and is applied to all clients + except services. The current algorithm is as follows: + + * check to see if client's `message timer' is less than + current time (set to be equal if it is); + + * read any data present from the client; + + * while the timer is less than ten seconds ahead of the current + time, parse any present messages and penalize the client by + 2 seconds for each message; + + which in essence means that the client may send 1 message every 2 + + + +Oikarinen & Reed [Page 60] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + seconds without being adversely affected. + +8.11 Non-blocking lookups + + In a real-time environment, it is essential that a server process do + as little waiting as possible so that all the clients are serviced + fairly. Obviously this requires non-blocking IO on all network + read/write operations. For normal server connections, this was not + difficult, but there are other support operations that may cause the + server to block (such as disk reads). Where possible, such activity + should be performed with a short timeout. + +8.11.1 Hostname (DNS) lookups + + Using the standard resolver libraries from Berkeley and others has + meant large delays in some cases where replies have timed out. To + avoid this, a separate set of DNS routines were written which were + setup for non-blocking IO operations and then polled from within the + main server IO loop. + +8.11.2 Username (Ident) lookups + + Although there are numerous ident libraries for use and inclusion + into other programs, these caused problems since they operated in a + synchronous manner and resulted in frequent delays. Again the + solution was to write a set of routines which would cooperate with + the rest of the server and work using non-blocking IO. + +8.12 Configuration File + + To provide a flexible way of setting up and running the server, it is + recommended that a configuration file be used which contains + instructions to the server on the following: + + * which hosts to accept client connections from; + + * which hosts to allow to connect as servers; + + * which hosts to connect to (both actively and + passively); + + * information about where the server is (university, + city/state, company are examples of this); + + * who is responsible for the server and an email address + at which they can be contacted; + + * hostnames and passwords for clients which wish to be given + + + +Oikarinen & Reed [Page 61] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + access to restricted operator commands. + + In specifying hostnames, both domain names and use of the 'dot' + notation (127.0.0.1) should both be accepted. It must be possible to + specify the password to be used/accepted for all outgoing and + incoming connections (although the only outgoing connections are + those to other servers). + + The above list is the minimum requirement for any server which wishes + to make a connection with another server. Other items which may be + of use are: + + * specifying which servers other server may introduce; + + * how deep a server branch is allowed to become; + + * hours during which clients may connect. + +8.12.1 Allowing clients to connect + + A server should use some sort of 'access control list' (either in the + configuration file or elsewhere) that is read at startup and used to + decide what hosts clients may use to connect to it. + + Both 'deny' and 'allow' should be implemented to provide the required + flexibility for host access control. + +8.12.2 Operators + + The granting of operator privileges to a disruptive person can have + dire consequences for the well-being of the IRC net in general due to + the powers given to them. Thus, the acquisition of such powers + should not be very easy. The current setup requires two 'passwords' + to be used although one of them is usually easy guessed. Storage of + oper passwords in configuration files is preferable to hard coding + them in and should be stored in a crypted format (ie using crypt(3) + from Unix) to prevent easy theft. + +8.12.3 Allowing servers to connect + + The interconnection of server is not a trivial matter: a bad + connection can have a large impact on the usefulness of IRC. Thus, + each server should have a list of servers to which it may connect and + which servers may connect to it. Under no circumstances should a + server allow an arbitrary host to connect as a server. In addition + to which servers may and may not connect, the configuration file + should also store the password and other characteristics of that + link. + + + +Oikarinen & Reed [Page 62] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +8.12.4 Administrivia + + To provide accurate and valid replies to the ADMIN command (see + section 4.3.7), the server should find the relevant details in the + configuration. + +8.13 Channel membership + + The current server allows any registered local user to join upto 10 + different channels. There is no limit imposed on non-local users so + that the server remains (reasonably) consistant with all others on a + channel membership basis + +9. Current problems + + There are a number of recognized problems with this protocol, all of + which hope to be solved sometime in the near future during its + rewrite. Currently, work is underway to find working solutions to + these problems. + +9.1 Scalability + + It is widely recognized that this protocol does not scale + sufficiently well when used in a large arena. The main problem comes + from the requirement that all servers know about all other servers + and users and that information regarding them be updated as soon as + it changes. It is also desirable to keep the number of servers low + so that the path length between any two points is kept minimal and + the spanning tree as strongly branched as possible. + +9.2 Labels + + The current IRC protocol has 3 types of labels: the nickname, the + channel name and the server name. Each of the three types has its + own domain and no duplicates are allowed inside that domain. + Currently, it is possible for users to pick the label for any of the + three, resulting in collisions. It is widely recognized that this + needs reworking, with a plan for unique names for channels and nicks + that don't collide being desirable as well as a solution allowing a + cyclic tree. + +9.2.1 Nicknames + + The idea of the nickname on IRC is very convenient for users to use + when talking to each other outside of a channel, but there is only a + finite nickname space and being what they are, its not uncommon for + several people to want to use the same nick. If a nickname is chosen + by two people using this protocol, either one will not succeed or + + + +Oikarinen & Reed [Page 63] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + both will removed by use of KILL (4.6.1). + +9.2.2 Channels + + The current channel layout requires that all servers know about all + channels, their inhabitants and properties. Besides not scaling + well, the issue of privacy is also a concern. A collision of + channels is treated as an inclusive event (both people who create the + new channel are considered to be members of it) rather than an + exclusive one such as used to solve nickname collisions. + +9.2.3 Servers + + Although the number of servers is usually small relative to the + number of users and channels, they two currently required to be known + globally, either each one separately or hidden behind a mask. + +9.3 Algorithms + + In some places within the server code, it has not been possible to + avoid N^2 algorithms such as checking the channel list of a set + of clients. + + In current server versions, there are no database consistency checks, + each server assumes that a neighbouring server is correct. This + opens the door to large problems if a connecting server is buggy or + otherwise tries to introduce contradictions to the existing net. + + Currently, because of the lack of unique internal and global labels, + there are a multitude of race conditions that exist. These race + conditions generally arise from the problem of it taking time for + messages to traverse and effect the IRC network. Even by changing to + unique labels, there are problems with channel-related commands being + disrupted. + +10. Current support and availability + + Mailing lists for IRC related discussion: + Future protocol: ircd-three-request@eff.org + General discussion: operlist-request@eff.org + + Software implemenations + cs.bu.edu:/irc + nic.funet.fi:/pub/irc + coombs.anu.edu.au:/pub/irc + + Newsgroup: alt.irc + + + + +Oikarinen & Reed [Page 64] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +Security Considerations + + Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and + 7. + +12. Authors' Addresses + + Jarkko Oikarinen + Tuirantie 17 as 9 + 90500 OULU + FINLAND + + Email: jto@tolsun.oulu.fi + + + Darren Reed + 4 Pateman Street + Watsonia, Victoria 3087 + Australia + + Email: avalon@coombs.anu.edu.au + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Oikarinen & Reed [Page 65] +
\ No newline at end of file diff --git a/irc_mod/Docs/rfc2810.txt b/irc_mod/Docs/rfc2810.txt new file mode 100644 index 0000000..e628a83 --- /dev/null +++ b/irc_mod/Docs/rfc2810.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group C. Kalt +Request for Comments: 2810 April 2000 +Updates: 1459 +Category: Informational + + + Internet Relay Chat: Architecture + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + The IRC (Internet Relay Chat) protocol is for use with text based + conferencing. It has been developed since 1989 when it was originally + implemented as a mean for users on a BBS to chat amongst themselves. + + First formally documented in May 1993 by RFC 1459 [IRC], the protocol + has kept evolving. This document is an update describing the + architecture of the current IRC protocol and the role of its + different components. Other documents describe in detail the + protocol used between the various components defined here. + +Table of Contents + + 1. Introduction ............................................... 2 + 2. Components ................................................. 2 + 2.1 Servers ................................................ 2 + 2.2 Clients ................................................ 3 + 2.2.1 User Clients ...................................... 3 + 2.2.2 Service Clients ................................... 3 + 3. Architecture ............................................... 3 + 4. IRC Protocol Services ...................................... 4 + 4.1 Client Locator ......................................... 4 + 4.2 Message Relaying ....................................... 4 + 4.3 Channel Hosting And Management ......................... 4 + 5. IRC Concepts ............................................... 4 + 5.1 One-To-One Communication ............................... 5 + 5.2 One-To-Many ............................................ 5 + 5.2.1 To A Channel ...................................... 5 + 5.2.2 To A Host/Server Mask ............................. 6 + + + +Kalt Informational [Page 1] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + + 5.2.3 To A List ......................................... 6 + 5.3 One-To-All ............................................. 6 + 5.3.1 Client-to-Client .................................. 6 + 5.3.2 Client-to-Server .................................. 7 + 5.3.3 Server-to-Server .................................. 7 + 6. Current Problems ........................................... 7 + 6.1 Scalability ............................................ 7 + 6.2 Reliability ............................................ 7 + 6.3 Network Congestion ..................................... 7 + 6.4 Privacy ................................................ 8 + 7. Security Considerations .................................... 8 + 8. Current Support And Availability ........................... 8 + 9. Acknowledgements ........................................... 8 + 10. References ................................................ 8 + 11. Author's Address .......................................... 9 + 12. Full Copyright Statement .................................. 10 + +1. Introduction + + The IRC (Internet Relay Chat) protocol has been designed over a + number of years for use with text based conferencing. This document + describes its current architecture. + + The IRC Protocol is based on the client-server model, and is well + suited to running on many machines in a distributed fashion. A + typical setup involves a single process (the server) forming a + central point for clients (or other servers) to connect to, + performing the required message delivery/multiplexing and other + functions. + + This distributed model, which requires each server to have a copy + of the global state information, is still the most flagrant problem + of the protocol as it is a serious handicap, which limits the maximum + size a network can reach. If the existing networks have been able to + keep growing at an incredible pace, we must thank hardware + manufacturers for giving us ever more powerful systems. + +2. Components + + The following paragraphs define the basic components of the IRC + protocol. + +2.1 Servers + + The server forms the backbone of IRC as it is the only component + of the protocol which is able to link all the other components + together: it provides a point to which clients may connect to talk to + + + + +Kalt Informational [Page 2] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + + each other [IRC-CLIENT], and a point for other servers to connect to + [IRC-SERVER]. The server is also responsible for providing the basic + services defined by the IRC protocol. + +2.2 Clients + + A client is anything connecting to a server that is not another + server. There are two types of clients which both serve a different + purpose. + +2.2.1 User Clients + + User clients are generally programs providing a text based + interface that is used to communicate interactively via IRC. This + particular type of clients is often referred as "users". + +2.2.2 Service Clients + + Unlike users, service clients are not intended to be used manually + nor for talking. They have a more limited access to the chat + functions of the protocol, while optionally having access to more + private data from the servers. + + Services are typically automatons used to provide some kind of + service (not necessarily related to IRC itself) to users. An example + is a service collecting statistics about the origin of users + connected on the IRC network. + +3. Architecture + + An IRC network is defined by a group of servers connected to each + other. A single server forms the simplest IRC network. + + The only network configuration allowed for IRC servers is that of + a spanning tree where each server acts as a central node for the rest + of the network it sees. + + 1--\ + A D---4 + 2--/ \ / + B----C + / \ + 3 E + + Servers: A, B, C, D, E Clients: 1, 2, 3, 4 + + [ Fig. 1. Sample small IRC network ] + + + + +Kalt Informational [Page 3] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + + The IRC protocol provides no mean for two clients to directly + communicate. All communication between clients is relayed by the + server(s). + +4. IRC Protocol Services + + This section describes the services offered by the IRC protocol. The + combination of these services allow real-time conferencing. + +4.1 Client Locator + + To be able to exchange messages, two clients must be able to locate + each other. + + Upon connecting to a server, a client registers using a label which + is then used by other servers and clients to know where the client is + located. Servers are responsible for keeping track of all the labels + being used. + +4.2 Message Relaying + + The IRC protocol provides no mean for two clients to directly + communicate. All communication between clients is relayed by the + server(s). + +4.3 Channel Hosting And Management + + A channel is a named group of one or more users which will all + receive messages addressed to that channel. A channel is + characterized by its name and current members, it also has a set of + properties which can be manipulated by (some of) its members. + + Channels provide a mean for a message to be sent to several clients. + Servers host channels, providing the necessary message multiplexing. + Servers are also responsible for managing channels by keeping track + of the channel members. The exact role of servers is defined in + "Internet Relay Chat: Channel Management" [IRC-CHAN]. + +5. IRC Concepts + + This section is devoted to describing the actual concepts behind the + organization of the IRC protocol and how different classes of + messages are delivered. + + + + + + + + +Kalt Informational [Page 4] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + +5.1 One-To-One Communication + + Communication on a one-to-one basis is usually performed by clients, + since most server-server traffic is not a result of servers talking + only to each other. To provide a means for clients to talk to each + other, it is REQUIRED that all servers be able to send a message in + exactly one direction along the spanning tree in order to reach any + client. Thus the path of a message being delivered is the shortest + path between any two points on the spanning tree. + + The following examples all refer to Figure 1 above. + + Example 1: A message between clients 1 and 2 is only seen by server + A, which sends it straight to client 2. + + Example 2: A message between clients 1 and 3 is seen by servers A & + B, and client 3. No other clients or servers are allowed see the + message. + + Example 3: A message between clients 2 and 4 is seen by servers A, B, + C & D and client 4 only. + +5.2 One-To-Many + + The main goal of IRC is to provide a forum which allows easy and + efficient conferencing (one to many conversations). IRC offers + several means to achieve this, each serving its own purpose. + +5.2.1 To A Channel + + In IRC the channel has a role equivalent to that of the multicast + group; their existence is dynamic and the actual conversation carried + out on a channel MUST only be sent to servers which are supporting + users on a given channel. Moreover, the message SHALL only be sent + once to every local link as each server is responsible to fan the + original message to ensure that it will reach all the recipients. + + The following examples all refer to Figure 2. + + Example 4: Any channel with 1 client in it. Messages to the channel + go to the server and then nowhere else. + + Example 5: 2 clients in a channel. All messages traverse a path as if + they were private messages between the two clients outside a + channel. + + + + + + +Kalt Informational [Page 5] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + + Example 6: Clients 1, 2 and 3 in a channel. All messages to the + channel are sent to all clients and only those servers which must + be traversed by the message if it were a private message to a + single client. If client 1 sends a message, it goes back to + client 2 and then via server B to client 3. + +5.2.2 To A Host/Server Mask + + To provide with some mechanism to send messages to a large body of + related users, host and server mask messages are available. These + messages are sent to users whose host or server information match + that of the mask. The messages are only sent to locations where + users are, in a fashion similar to that of channels. + +5.2.3 To A List + + The least efficient style of one-to-many conversation is through + clients talking to a 'list' of targets (client, channel, mask). How + this is done is almost self explanatory: the client gives a list of + destinations to which the message is to be delivered and the server + breaks it up and dispatches a separate copy of the message to each + given destination. + + This is not as efficient as using a channel since the destination + list MAY be broken up and the dispatch sent without checking to make + sure duplicates aren't sent down each path. + +5.3 One-To-All + + The one-to-all type of message is better described as a broadcast + message, sent to all clients or servers or both. On a large network + of users and servers, a single message can result in a lot of traffic + being sent over the network in an effort to reach all of the desired + destinations. + + For some class of messages, there is no option but to broadcast it to + all servers so that the state information held by each server is + consistent between servers. + +5.3.1 Client-to-Client + + There is no class of message which, from a single message, results in + a message being sent to every other client. + + + + + + + + +Kalt Informational [Page 6] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + +5.3.2 Client-to-Server + + Most of the commands which result in a change of state information + (such as channel membership, channel mode, user status, etc.) MUST be + sent to all servers by default, and this distribution SHALL NOT be + changed by the client. + +5.3.3 Server-to-Server + + While most messages between servers are distributed to all 'other' + servers, this is only required for any message that affects a user, + channel or server. Since these are the basic items found in IRC, + nearly all messages originating from a server are broadcast to all + other connected servers. + +6. Current Problems + + There are a number of recognized problems with this protocol, this + section only addresses the problems related to the architecture of + the protocol. + +6.1 Scalability + + It is widely recognized that this protocol does not scale + sufficiently well when used in a large arena. The main problem comes + from the requirement that all servers know about all other servers, + clients and channels and that information regarding them be updated + as soon as it changes. + +6.2 Reliability + + As the only network configuration allowed for IRC servers is that of + a spanning tree, each link between two servers is an obvious and + quite serious point of failure. This particular issue is addressed + more in detail in "Internet Relay Chat: Server Protocol" [IRC- + SERVER]. + +6.3 Network Congestion + + Another problem related to the scalability and reliability issues, as + well as the spanning tree architecture, is that the protocol and + architecture for IRC are extremely vulnerable to network congestions. + This problem is endemic, and should be solved for the next + generation: if congestion and high traffic volume cause a link + between two servers to fail, not only this failure generates more + network traffic, but the reconnection (eventually elsewhere) of two + servers also generates more traffic. + + + + +Kalt Informational [Page 7] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + + In an attempt to minimize the impact of these problems, it is + strongly RECOMMENDED that servers do not automatically try to + reconnect too fast, in order to avoid aggravating the situation. + +6.4 Privacy + + Besides not scaling well, the fact that servers need to know all + information about other entities, the issue of privacy is also a + concern. This is in particular true for channels, as the related + information is quite a lot more revealing than whether a user is + online or not. + +7. Security Considerations + + Asides from the privacy concerns mentioned in section 6.4 (Privacy), + security is believed to be irrelevant to this document. + +8. Current Support And Availability + + Mailing lists for IRC related discussion: + General discussion: ircd-users@irc.org + Protocol development: ircd-dev@irc.org + + Software implementations: + ftp://ftp.irc.org/irc/server + ftp://ftp.funet.fi/pub/unix/irc + ftp://coombs.anu.edu.au/pub/irc + + Newsgroup: alt.irc + +9. Acknowledgements + + Parts of this document were copied from the RFC 1459 [IRC] which + first formally documented the IRC Protocol. It has also benefited + from many rounds of review and comments. In particular, the + following people have made significant contributions to this + document: + + Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa + Ruokonen, Magnus Tjernstrom, Stefan Zehl. + + + + + + + + + + + +Kalt Informational [Page 8] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + +10. References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat + Protocol", RFC 1459, May 1993. + + [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC + 2812, April 2000. + + [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC + 2813, April 2000. + + [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC + 2811, April 2000. + +11. Author's Address + + Christophe Kalt + 99 Teaneck Rd, Apt #117 + Ridgefield Park, NJ 07660 + USA + + EMail: kalt@stealth.net + + + + + + + + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 9] + +RFC 2810 Internet Relay Chat: Architecture April 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 10] + diff --git a/irc_mod/Docs/rfc2811.txt b/irc_mod/Docs/rfc2811.txt new file mode 100644 index 0000000..7c2c4ea --- /dev/null +++ b/irc_mod/Docs/rfc2811.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group C. Kalt +Request for Comments: 2811 April 2000 +Updates: 1459 +Category: Informational + + + Internet Relay Chat: Channel Management + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + One of the most notable characteristics of the IRC (Internet Relay + Chat) protocol is to allow for users to be grouped in forums, called + channels, providing a mean for multiple users to communicate + together. + + There was originally a unique type of channels, but with the years, + new types appeared either as a response to a need, or for + experimental purposes. + + This document specifies how channels, their characteristics and + properties are managed by IRC servers. + +Table of Contents + + 1. Introduction ............................................... 2 + 2. Channel Characteristics .................................... 3 + 2.1 Namespace .............................................. 3 + 2.2 Channel Scope .......................................... 3 + 2.3 Channel Properties ..................................... 4 + 2.4 Privileged Channel Members ............................. 4 + 2.4.1 Channel Operators ................................. 5 + 2.4.2 Channel Creator ................................... 5 + 3. Channel lifetime ........................................... 5 + 3.1 Standard channels ...................................... 5 + 3.2 Safe Channels .......................................... 6 + 4. Channel Modes .............................................. 7 + 4.1 Member Status .......................................... 7 + 4.1.1 "Channel Creator" Status .......................... 7 + + + +Kalt Informational [Page 1] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + 4.1.2 Channel Operator Status ........................... 8 + 4.1.3 Voice Privilege ................................... 8 + 4.2 Channel Flags .......................................... 8 + 4.2.1 Anonymous Flag .................................... 8 + 4.2.2 Invite Only Flag .................................. 8 + 4.2.3 Moderated Channel Flag ............................ 9 + 4.2.4 No Messages To Channel From Clients On The Outside 9 + 4.2.5 Quiet Channel ..................................... 9 + 4.2.6 Private and Secret Channels ....................... 9 + 4.2.7 Server Reop Flag .................................. 10 + 4.2.8 Topic ............................................. 10 + 4.2.9 User Limit ........................................ 10 + 4.2.10 Channel Key ...................................... 10 + 4.3 Channel Access Control ................................. 10 + 4.3.1 Channel Ban and Exception ......................... 11 + 4.3.2 Channel Invitation ................................ 11 + 5. Current Implementations .................................... 11 + 5.1 Tracking Recently Used Channels ........................ 11 + 5.2 Safe Channels .......................................... 12 + 5.2.1 Channel Identifier ................................ 12 + 5.2.2 Channel Delay ..................................... 12 + 5.2.3 Abuse Window ...................................... 13 + 5.2.4 Preserving Sanity In The Name Space ............... 13 + 5.2.5 Server Reop Mechanism ............................. 13 + 6. Current problems ........................................... 14 + 6.1 Labels ................................................. 14 + 6.1.1 Channel Delay ..................................... 14 + 6.1.2 Safe Channels ..................................... 15 + 6.2 Mode Propagation Delays ................................ 15 + 6.3 Collisions And Channel Modes ........................... 15 + 6.4 Resource Exhaustion .................................... 16 + 7. Security Considerations .................................... 16 + 7.1 Access Control ......................................... 16 + 7.2 Channel Privacy ........................................ 16 + 7.3 Anonymity ............................................... 17 + 8. Current support and availability ........................... 17 + 9. Acknowledgements ........................................... 17 + 10. References ................................................ 18 + 11. Author's Address .......................................... 18 + 12. Full Copyright Statement ................................... 19 + +1. Introduction + + This document defines in detail on how channels are managed by the + IRC servers and will be mostly useful to people working on + implementing an IRC server. + + + + + +Kalt Informational [Page 2] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + While the concepts defined here are an important part of IRC, they + remain non essential for implementing clients. While the trend seems + to be towards more and more complex and "intelligent" clients which + are able to take advantage of knowing the internal workings of + channels to provide the users with a more friendly interface, simple + clients can be implemented without reading this document. + + Many of the concepts defined here were designed with the IRC + architecture [IRC-ARCH] in mind and mostly make sense in this + context. However, many others could be applied to other + architectures in order to provide forums for a conferencing system. + + Finally, it is to be noted that IRC users may find some of the + following sections of interest, in particular sections 2 (Channel + Characteristics) and 4 (Channel Modes). + +2. Channel Characteristics + + A channel is a named group of one or more users which will all + receive messages addressed to that channel. A channel is + characterized by its name, properties and current members. + +2.1 Namespace + + Channels names are strings (beginning with a '&', '#', '+' or '!' + character) of length up to fifty (50) characters. Channel names are + case insensitive. + + Apart from the the requirement that the first character being either + '&', '#', '+' or '!' (hereafter called "channel prefix"). The only + restriction on a channel name is that it SHALL NOT contain any spaces + (' '), a control G (^G or ASCII 7), a comma (',' which is used as a + list item separator by the protocol). Also, a colon (':') is used as + a delimiter for the channel mask. The exact syntax of a channel name + is defined in "IRC Server Protocol" [IRC-SERVER]. + + The use of different prefixes effectively creates four (4) distinct + namespaces for channel names. This is important because of the + protocol limitations regarding namespaces (in general). See section + 6.1 (Labels) for more details on these limitations. + +2.2 Channel Scope + + A channel entity is known by one or more servers on the IRC network. + A user can only become member of a channel known by the server to + which the user is directly connected. The list of servers which know + + + + + +Kalt Informational [Page 3] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + of the existence of a particular channel MUST be a contiguous part of + the IRC network, in order for the messages addressed to the channel + to be sent to all the channel members. + + Channels with '&' as prefix are local to the server where they are + created. + + Other channels are known to one (1) or more servers that are + connected to the network, depending on the channel mask: + + If there is no channel mask, then the channel is known to all + the servers. + + If there is a channel mask, then the channel MUST only be known + to servers which has a local user on the channel, and to its + neighbours if the mask matches both the local and neighbouring + server names. Since other servers have absolutely no knowledge of + the existence of such a channel, the area formed by the servers + having a name matching the mask has to be contiguous for the + channel to be known by all these servers. Channel masks are best + used in conjunction with server hostmasking [IRC-SERVER]. + +2.3 Channel Properties + + Each channel has its own properties, which are defined by channel + modes. Channel modes can be manipulated by the channel members. The + modes affect the way servers manage the channels. + + Channels with '+' as prefix do not support channel modes. This means + that all the modes are unset, with the exception of the 't' channel + flag which is set. + +2.4 Privileged Channel Members + + In order for the channel members to keep some control over a channel, + and some kind of sanity, some channel members are privileged. Only + these members are allowed to perform the following actions on the + channel: + + INVITE - Invite a client to an invite-only channel (mode +i) + KICK - Eject a client from the channel + MODE - Change the channel's mode, as well as + members' privileges + PRIVMSG - Sending messages to the channel (mode +n, +m, +v) + TOPIC - Change the channel topic in a mode +t channel + + + + + + +Kalt Informational [Page 4] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +2.4.1 Channel Operators + + The channel operators (also referred to as a "chop" or "chanop") on a + given channel are considered to 'own' that channel. Ownership of a + channel is shared among channel operators. + + Channel operators are identified by the '@' symbol next to their + nickname whenever it is associated with a channel (i.e., replies to + the NAMES, WHO and WHOIS commands). + + Since channels starting with the character '+' as prefix do not + support channel modes, no member can therefore have the status of + channel operator. + +2.4.2 Channel Creator + + A user who creates a channel with the character '!' as prefix is + identified as the "channel creator". Upon creation of the channel, + this user is also given channel operator status. + + In recognition of this status, the channel creators are endowed with + the ability to toggle certain modes of the channel which channel + operators may not manipulate. + + A "channel creator" can be distinguished from a channel operator by + issuing the proper MODE command. See the "IRC Client Protocol" + [IRC-CLIENT] for more information on this topic. + +3. Channel lifetime + + In regard to the lifetime of a channel, there are typically two + groups of channels: standard channels which prefix is either '&', '#' + or '+', and "safe channels" which prefix is '!'. + +3.1 Standard channels + + These channels are created implicitly when the first user joins it, + and cease to exist when the last user leaves it. While the channel + exists, any client can reference the channel using the name of the + channel. + + The user creating a channel automatically becomes channel operator + with the notable exception of channels which name is prefixed by the + character '+', see section 4 (Channel modes). See section 2.4.1 + (Channel Operators) for more details on this title. + + + + + + +Kalt Informational [Page 5] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + In order to avoid the creation of duplicate channels (typically when + the IRC network becomes disjoint because of a split between two + servers), channel names SHOULD NOT be allowed to be reused by a user + if a channel operator (See Section 2.4.1 (Channel Operators)) has + recently left the channel because of a network split. If this + happens, the channel name is temporarily unavailable. The duration + while a channel remains unavailable should be tuned on a per IRC + network basis. It is important to note that this prevents local + users from creating a channel using the same name, but does not + prevent the channel to be recreated by a remote user. The latter + typically happens when the IRC network rejoins. Obviously, this + mechanism only makes sense for channels which name begins with the + character '#', but MAY be used for channels which name begins with + the character '+'. This mechanism is commonly known as "Channel + Delay". + +3.2 Safe Channels + + Unlike other channels, "safe channels" are not implicitly created. A + user wishing to create such a channel MUST request the creation by + sending a special JOIN command to the server in which the channel + identifier (then unknown) is replaced by the character '!'. The + creation process for this type of channel is strictly controlled. + The user only chooses part of the channel name (known as the channel + "short name"), the server automatically prepends the user provided + name with a channel identifier consisting of five (5) characters. + The channel name resulting from the combination of these two elements + is unique, making the channel safe from abuses based on network + splits. + + The user who creates such a channel automatically becomes "channel + creator". See section 2.4.2 (Channel Creator) for more details on + this title. + + A server MUST NOT allow the creation of a new channel if another + channel with the same short name exists; or if another channel with + the same short name existed recently AND any of its member(s) left + because of a network split. Such channel ceases to exist after last + user leaves AND no other member recently left the channel because of + a network split. + + Unlike the mechanism described in section 5.2.2 (Channel Delay), in + this case, channel names do not become unavailable: these channels + may continue to exist after the last user left. Only the user + creating the channel becomes "channel creator", users joining an + existing empty channel do not automatically become "channel creator" + nor "channel operator". + + + + +Kalt Informational [Page 6] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + To ensure the uniqueness of the channel names, the channel identifier + created by the server MUST follow specific rules. For more details + on this, see section 5.2.1 (Channel Identifier). + +4. Channel Modes + + The various modes available for channels are as follows: + + O - give "channel creator" status; + o - give/take channel operator privilege; + v - give/take the voice privilege; + + a - toggle the anonymous channel flag; + i - toggle the invite-only channel flag; + m - toggle the moderated channel; + n - toggle the no messages to channel from clients on the + outside; + q - toggle the quiet channel flag; + p - toggle the private channel flag; + s - toggle the secret channel flag; + r - toggle the server reop channel flag; + t - toggle the topic settable by channel operator only flag; + + k - set/remove the channel key (password); + l - set/remove the user limit to channel; + + b - set/remove ban mask to keep users out; + e - set/remove an exception mask to override a ban mask; + I - set/remove an invitation mask to automatically override + the invite-only flag; + + Unless mentioned otherwise below, all these modes can be manipulated + by "channel operators" by using the MODE command defined in "IRC + Client Protocol" [IRC-CLIENT]. + +4.1 Member Status + + The modes in this category take a channel member nickname as argument + and affect the privileges given to this user. + +4.1.1 "Channel Creator" Status + + The mode 'O' is only used in conjunction with "safe channels" and + SHALL NOT be manipulated by users. Servers use it to give the user + creating the channel the status of "channel creator". + + + + + + +Kalt Informational [Page 7] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +4.1.2 Channel Operator Status + + The mode 'o' is used to toggle the operator status of a channel + member. + +4.1.3 Voice Privilege + + The mode 'v' is used to give and take voice privilege to/from a + channel member. Users with this privilege can talk on moderated + channels. (See section 4.2.3 (Moderated Channel Flag). + +4.2 Channel Flags + + The modes in this category are used to define properties which + affects how channels operate. + +4.2.1 Anonymous Flag + + The channel flag 'a' defines an anonymous channel. This means that + when a message sent to the channel is sent by the server to users, + and the origin is a user, then it MUST be masked. To mask the + message, the origin is changed to "anonymous!anonymous@anonymous." + (e.g., a user with the nickname "anonymous", the username "anonymous" + and from a host called "anonymous."). Because of this, servers MUST + forbid users from using the nickname "anonymous". Servers MUST also + NOT send QUIT messages for users leaving such channels to the other + channel members but generate a PART message instead. + + On channels with the character '&' as prefix, this flag MAY be + toggled by channel operators, but on channels with the character '!' + as prefix, this flag can be set (but SHALL NOT be unset) by the + "channel creator" only. This flag MUST NOT be made available on + other types of channels. + + Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the + presence of other users on channels for which the anonymous flag is + set. + +4.2.2 Invite Only Flag + + When the channel flag 'i' is set, new members are only accepted if + their mask matches Invite-list (See section 4.3.2) or they have been + invited by a channel operator. This flag also restricts the usage of + the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to + channel operators. + + + + + + +Kalt Informational [Page 8] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +4.2.3 Moderated Channel Flag + + The channel flag 'm' is used to control who may speak on a channel. + When it is set, only channel operators, and members who have been + given the voice privilege may send messages to the channel. + + This flag only affects users. + +4.2.4 No Messages To Channel From Clients On The Outside + + When the channel flag 'n' is set, only channel members MAY send + messages to the channel. + + This flag only affects users. + +4.2.5 Quiet Channel + + The channel flag 'q' is for use by servers only. When set, it + restricts the type of data sent to users about the channel + operations: other user joins, parts and nick changes are not sent. + From a user's point of view, the channel contains only one user. + + This is typically used to create special local channels on which the + server sends notices related to its operations. This was used as a + more efficient and flexible way to replace the user mode 's' defined + in RFC 1459 [IRC]. + +4.2.6 Private and Secret Channels + + The channel flag 'p' is used to mark a channel "private" and the + channel flag 's' to mark a channel "secret". Both properties are + similar and conceal the existence of the channel from other users. + + This means that there is no way of getting this channel's name from + the server without being a member. In other words, these channels + MUST be omitted from replies to queries like the WHOIS command. + + When a channel is "secret", in addition to the restriction above, the + server will act as if the channel does not exist for queries like the + TOPIC, LIST, NAMES commands. Note that there is one exception to + this rule: servers will correctly reply to the MODE command. + Finally, secret channels are not accounted for in the reply to the + LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC- + CLIENT]) when the <mask> parameter is specified. + + + + + + + +Kalt Informational [Page 9] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + The channel flags 'p' and 's' MUST NOT both be set at the same time. + If a MODE message originating from a server sets the flag 'p' and the + flag 's' is already set for the channel, the change is silently + ignored. This should only happen during a split healing phase + (mentioned in the "IRC Server Protocol" document [IRC-SERVER]). + +4.2.7 Server Reop Flag + + The channel flag 'r' is only available on channels which name begins + with the character '!' and MAY only be toggled by the "channel + creator". + + This flag is used to prevent a channel from having no channel + operator for an extended period of time. When this flag is set, any + channel that has lost all its channel operators for longer than the + "reop delay" period triggers a mechanism in servers to reop some or + all of the channel inhabitants. This mechanism is described more in + detail in section 5.2.4 (Channel Reop Mechanism). + +4.2.8 Topic + + The channel flag 't' is used to restrict the usage of the TOPIC + command to channel operators. + +4.2.9 User Limit + + A user limit may be set on channels by using the channel flag 'l'. + When the limit is reached, servers MUST forbid their local users to + join the channel. + + The value of the limit MUST only be made available to the channel + members in the reply sent by the server to a MODE query. + +4.2.10 Channel Key + + When a channel key is set (by using the mode 'k'), servers MUST + reject their local users request to join the channel unless this key + is given. + + The channel key MUST only be made visible to the channel members in + the reply sent by the server to a MODE query. + +4.3 Channel Access Control + + The last category of modes is used to control access to the channel, + they take a mask as argument. + + + + + +Kalt Informational [Page 10] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + In order to reduce the size of the global database for control access + modes set for channels, servers MAY put a maximum limit on the number + of such modes set for a particular channel. If such restriction is + imposed, it MUST only affect user requests. The limit SHOULD be + homogeneous on a per IRC network basis. + +4.3.1 Channel Ban and Exception + + When a user requests to join a channel, his local server checks if + the user's address matches any of the ban masks set for the channel. + If a match is found, the user request is denied unless the address + also matches an exception mask set for the channel. + + Servers MUST NOT allow a channel member who is banned from the + channel to speak on the channel, unless this member is a channel + operator or has voice privilege. (See Section 4.1.3 (Voice + Privilege)). + + A user who is banned from a channel and who carries an invitation + sent by a channel operator is allowed to join the channel. + +4.3.2 Channel Invitation + + For channels which have the invite-only flag set (See Section 4.2.2 + (Invite Only Flag)), users whose address matches an invitation mask + set for the channel are allowed to join the channel without any + invitation. + +5. Current Implementations + + The only current implementation of these rules as part of the IRC + protocol is the IRC server, version 2.10. + + The rest of this section deals with issues that are mostly of + importance to those who wish to implement a server but some parts may + also be of interest for client writers. + +5.1 Tracking Recently Used Channels + + This mechanism is commonly known as "Channel Delay" and generally + only applies to channels which names is prefixed with the character + '#' (See Section 3.1 "Standard channels"). + + When a network split occurs, servers SHOULD keep track of which + channels lost a "channel operator" as the result of the break. These + channels are then in a special state which lasts for a certain period + of time. In this particular state, the channels cannot cease to + + + + +Kalt Informational [Page 11] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + exist. If all the channel members leave the channel, the channel + becomes unavailable: the server local clients cannot join the channel + as long as it is empty. + + Once a channel is unavailable, it will become available again either + because a remote user has joined the channel (most likely because the + network is healing), or because the delay period has expired (in + which case the channel ceases to exist and may be re-created). + + The duration for which a channel death is delayed SHOULD be set + considering many factors among which are the size (user wise) of the + IRC network, and the usual duration of network splits. It SHOULD be + uniform on all servers for a given IRC network. + +5.2 Safe Channels + + This document introduces the notion of "safe channels". These + channels have a name prefixed with the character '!' and great effort + is made to avoid collisions in this name space. Collisions are not + impossible, however they are very unlikely. + +5.2.1 Channel Identifier + + The channel identifier is a function of the time. The current time + (as defined under UNIX by the number of seconds elapsed since + 00:00:00 GMT, January 1, 1970) is converted in a string of five (5) + characters using the following base: + "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal + value starting from 0 for 'A' to 35 for '0'). + + The channel identifier therefore has a periodicity of 36^5 seconds + (about 700 days). + +5.2.2 Channel Delay + + These channels MUST be subject to the "channel delay" mechanism + described in section 5.1 (Channel Delay). However, the mechanism is + slightly adapted to fit better. + + Servers MUST keep track of all such channels which lose members as + the result of a network split, no matter whether the user is a + "channel operator" or not. + + However, these channels do NOT ever become unavailable, it is always + possible to join them even when they are empty. + + + + + + +Kalt Informational [Page 12] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +5.2.3 Abuse Window + + Because the periodicity is so long, attacks on a particular channel + (name) may only occur once in a very long while. However, with luck + and patience, it is still possible for a user to cause a channel + collision. In order to avoid this, servers MUST "look in the future" + and keep a list of channel names which identifier is about to be used + (in the coming few days for example). Such list should remain small, + not be a burden for servers to maintain and be used to avoid channel + collisions by preventing the re-creation of such channel for a longer + period of time than channel delay does. + + Eventually a server MAY choose to extend this procedure to forbid + creation of channels with the same shortname only (then ignoring the + channel identifier). + +5.2.4 Preserving Sanity In The Name Space + + The combination of the mechanisms described in sections 5.2.2 and + 5.2.3 makes it quite difficult for a user to create a channel + collision. However, another type of abuse consists of creating many + channels having the same shortname, but different identifiers. To + prevent this from happening, servers MUST forbid the creation of a + new channel which has the same shortname of a channel currently + existing. + +5.2.5 Server Reop Mechanism + + When a channel has been opless for longer than the "reop delay" + period and has the channel flag 'r' set (See Section 4.2.7 (Server + Reop Flag)), IRC servers are responsible for giving the channel + operator status randomly to some of the members. + + The exact logic used for this mechanism by the current implementation + is described below. Servers MAY use a different logic, but that it + is strongly RECOMMENDED that all servers use the same logic on a + particular IRC network to maintain coherence as well as fairness. + For the same reason, the "reop delay" SHOULD be uniform on all + servers for a given IRC network. As for the "channel delay", the + value of the "reop delay" SHOULD be set considering many factors + among which are the size (user wise) of the IRC network, and the + usual duration of network splits. + + a) the reop mechanism is triggered after a random time following the + expiration of the "reop delay". This should limit the eventuality + of the mechanism being triggered at the same time (for the same + channel) on two separate servers. + + + + +Kalt Informational [Page 13] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + b) If the channel is small (five (5) users or less), and the "channel + delay" for this channel has expired, + Then reop all channel members if at least one member is local to + the server. + + c) If the channel is small (five (5) users or less), and the "channel + delay" for this channel has expired, and the "reop delay" has + expired for longer than its value, + Then reop all channel members. + + d) For other cases, reop at most one member on the channel, based on + some method build into the server. If you don't reop a member, the + method should be such that another server will probably op + someone. The method SHOULD be the same over the whole network. A + good heuristic could be just random reop. + (The current implementation actually tries to choose a member + local to the server who has not been idle for too long, eventually + postponing action, therefore letting other servers have a chance + to find a "not too idle" member. This is over complicated due to + the fact that servers only know the "idle" time of their local + users) + +6. Current problems + + There are a number of recognized problems with the way IRC channels + are managed. Some of these can be directly attributed to the rules + defined in this document, while others are the result of the + underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from + RFC 1459 [IRC], this document introduces several novelties in an + attempt to solve some of the known problems. + +6.1 Labels + + This document defines one of the many labels used by the IRC + protocol. Although there are several distinct namespaces (based on + the channel name prefix), duplicates inside each of these are not + allowed. Currently, it is possible for users on different servers to + pick the label which may result in collisions (with the exception of + channels known to only one server where they can be averted). + +6.1.1 Channel Delay + + The channel delay mechanism described in section 5.1 (Tracking + Recently Used Channels) and used for channels prefixed with the + character '#' is a simple attempt at preventing collisions from + happening. Experience has shown that, under normal circumstances, it + + + + + +Kalt Informational [Page 14] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + is very efficient; however, it obviously has severe limitations + keeping it from being an adequate solution to the problem discussed + here. + +6.1.2 Safe Channels + + "Safe channels" described in section 3.2 (Safe Channels) are a better + way to prevent collisions from happening as it prevents users from + having total control over the label they choose. The obvious + drawback for such labels is that they are not user friendly. + However, it is fairly trivial for a client program to improve on + this. + +6.2 Mode Propagation Delays + + Because of network delays induced by the network, and because each + server on the path is REQUIRED to check the validity of mode changes + (e.g., user exists and has the right privileges), it is not unusual + for a MODE message to only affect part of the network, often creating + a discrepancy between servers on the current state of a channel. + + While this may seem easy to fix (by having only the original server + check the validity of mode changes), it was decided not to do so for + various reasons. One concern is that servers cannot trust each + other, and that a misbehaving servers can easily be detected. This + way of doing so also stops wave effects on channels which are out of + synch when mode changes are issued from different directions. + +6.3 Collisions And Channel Modes + + The "Internet Relay Chat: Server Protocol" document [IRC-SERVER] + describes how channel data is exchanged when two servers connect to + each other. Channel collisions (either legitimate or not) are + treated as inclusive events, meaning that the resulting channel has + for members all the users who are members of the channel on either + server prior to the connection. + + Similarly, each server sends the channel modes to the other one. + Therefore, each server also receives these channel modes. There are + three types of modes for a given channel: flags, masks, and data. + The first two types are easy to deal with as they are either set or + unset. If such a mode is set on one server, it MUST be set on the + other server as a result of the connection. + + + + + + + + +Kalt Informational [Page 15] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + + As topics are not sent as part of this exchange, they are not a + problem. However, channel modes 'l' and 'k' are exchanged, and if + they are set on both servers prior to the connection, there is no + mechanism to decide which of the two values takes precedence. It is + left up to the users to fix the resulting discrepancy. + +6.4 Resource Exhaustion + + The mode based on masks defined in section 4.3 make the IRC servers + (and network) vulnerable to a simple abuse of the system: a single + channel operator can set as many different masks as possible on a + particular channel. This can easily cause the server to waste + memory, as well as network bandwidth (since the info is propagated to + other servers). For this reason it is RECOMMENDED that a limit be + put on the number of such masks per channels as mentioned in section + 4.3. + + Moreover, more complex mechanisms MAY be used to avoid having + redundant masks set for the same channel. + +7. Security Considerations + +7.1 Access Control + + One of the main ways to control access to a channel is to use masks + which are based on the username and hostname of the user connections. + This mechanism can only be efficient and safe if the IRC servers have + an accurate way of authenticating user connections, and if users + cannot easily get around it. While it is in theory possible to + implement such a strict authentication mechanism, most IRC networks + (especially public networks) do not have anything like this in place + and provide little guaranty about the accuracy of the username and + hostname for a particular client connection. + + Another way to control access is to use a channel key, but since this + key is sent in plaintext, it is vulnerable to traditional man in the + middle attacks. + +7.2 Channel Privacy + + Because channel collisions are treated as inclusive events (See + Section 6.3), it is possible for users to join a channel overriding + its access control settings. This method has long been used by + individuals to "take over" channels by "illegitimately" gaining + channel operator status on the channel. The same method can be used + to find out the exact list of members of a channel, as well as to + eventually receive some of the messages sent to the channel. + + + + +Kalt Informational [Page 16] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +7.3 Anonymity + + The anonymous channel flag (See Section 4.2.1) can be used to render + all users on such channel "anonymous" by presenting all messages to + the channel as originating from a pseudo user which nickname is + "anonymous". This is done at the client-server level, and no + anonymity is provided at the server-server level. + + It should be obvious to readers, that the level of anonymity offered + is quite poor and insecure, and that clients SHOULD display strong + warnings for users joining such channels. + +8. Current support and availability + + Mailing lists for IRC related discussion: + General discussion: ircd-users@irc.org + Protocol development: ircd-dev@irc.org + + Software implementations: + ftp://ftp.irc.org/irc/server + ftp://ftp.funet.fi/pub/unix/irc + ftp://coombs.anu.edu.au/pub/irc + + Newsgroup: alt.irc + +9. Acknowledgements + + Parts of this document were copied from the RFC 1459 [IRC] which + first formally documented the IRC Protocol. It has also benefited + from many rounds of review and comments. In particular, the + following people have made significant contributions to this + document: + + Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa + Ruokonen, Magnus Tjernstrom, Stefan Zehl. + + + + + + + + + + + + + + + + +Kalt Informational [Page 17] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +10. References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat + Protocol", RFC 1459, May 1993. + + [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, + April 2000. + + [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC + 2812, April 2000. + + [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC + 2813, April 2000. + +11. Author's Address + + Christophe Kalt + 99 Teaneck Rd, Apt #117 + Ridgefield Park, NJ 07660 + USA + + EMail: kalt@stealth.net + + + + + + + + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 18] + +RFC 2811 Internet Relay Chat: Channel Management April 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 19] + diff --git a/irc_mod/Docs/rfc2812.txt b/irc_mod/Docs/rfc2812.txt new file mode 100644 index 0000000..7f1b162 --- /dev/null +++ b/irc_mod/Docs/rfc2812.txt @@ -0,0 +1,3531 @@ + + + + + + +Network Working Group C. Kalt +Request for Comments: 2812 April 2000 +Updates: 1459 +Category: Informational + + + Internet Relay Chat: Client Protocol + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +IESG NOTE: + + The IRC protocol itself enables several possibilities of transferring + data between clients, and just like with other transfer mechanisms + like email, the receiver of the data has to be careful about how the + data is handled. For more information on security issues with the IRC + protocol, see for example http://www.irchelp.org/irchelp/security/. + +Abstract + + The IRC (Internet Relay Chat) protocol is for use with text based + conferencing; the simplest client being any socket program capable of + connecting to the server. + + This document defines the Client Protocol, and assumes that the + reader is familiar with the IRC Architecture [IRC-ARCH]. + +Table of Contents + + 1. Labels ..................................................... 3 + 1.1 Servers ................................................ 3 + 1.2 Clients ................................................ 3 + 1.2.1 Users ............................................. 4 + 1.2.1.1 Operators .................................... 4 + 1.2.2 Services .......................................... 4 + 1.3 Channels ............................................... 4 + 2. The IRC Client Specification ............................... 5 + 2.1 Overview ............................................... 5 + 2.2 Character codes ........................................ 5 + 2.3 Messages ............................................... 5 + + + +Kalt Informational [Page 1] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 2.3.1 Message format in Augmented BNF ................... 6 + 2.4 Numeric replies ........................................ 8 + 2.5 Wildcard expressions ................................... 9 + 3. Message Details ............................................ 9 + 3.1 Connection Registration ................................ 10 + 3.1.1 Password message .................................. 10 + 3.1.2 Nick message ...................................... 10 + 3.1.3 User message ...................................... 11 + 3.1.4 Oper message ...................................... 12 + 3.1.5 User mode message ................................. 12 + 3.1.6 Service message ................................... 13 + 3.1.7 Quit .............................................. 14 + 3.1.8 Squit ............................................. 15 + 3.2 Channel operations ..................................... 15 + 3.2.1 Join message ...................................... 16 + 3.2.2 Part message ...................................... 17 + 3.2.3 Channel mode message .............................. 18 + 3.2.4 Topic message ..................................... 19 + 3.2.5 Names message ..................................... 20 + 3.2.6 List message ...................................... 21 + 3.2.7 Invite message .................................... 21 + 3.2.8 Kick command ...................................... 22 + 3.3 Sending messages ....................................... 23 + 3.3.1 Private messages .................................. 23 + 3.3.2 Notice ............................................ 24 + 3.4 Server queries and commands ............................ 25 + 3.4.1 Motd message ...................................... 25 + 3.4.2 Lusers message .................................... 25 + 3.4.3 Version message ................................... 26 + 3.4.4 Stats message ..................................... 26 + 3.4.5 Links message ..................................... 27 + 3.4.6 Time message ...................................... 28 + 3.4.7 Connect message ................................... 28 + 3.4.8 Trace message ..................................... 29 + 3.4.9 Admin command ..................................... 30 + 3.4.10 Info command ...................................... 31 + 3.5 Service Query and Commands ............................. 31 + 3.5.1 Servlist message .................................. 31 + 3.5.2 Squery ............................................ 32 + 3.6 User based queries ..................................... 32 + 3.6.1 Who query ......................................... 32 + 3.6.2 Whois query ....................................... 33 + 3.6.3 Whowas ............................................ 34 + 3.7 Miscellaneous messages ................................. 34 + 3.7.1 Kill message ...................................... 35 + 3.7.2 Ping message ...................................... 36 + 3.7.3 Pong message ...................................... 37 + 3.7.4 Error ............................................. 37 + + + +Kalt Informational [Page 2] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 4. Optional features .......................................... 38 + 4.1 Away ................................................... 38 + 4.2 Rehash message ......................................... 39 + 4.3 Die message ............................................ 39 + 4.4 Restart message ........................................ 40 + 4.5 Summon message ......................................... 40 + 4.6 Users .................................................. 41 + 4.7 Operwall message ....................................... 41 + 4.8 Userhost message ....................................... 42 + 4.9 Ison message ........................................... 42 + 5. Replies .................................................... 43 + 5.1 Command responses ...................................... 43 + 5.2 Error Replies .......................................... 53 + 5.3 Reserved numerics ...................................... 59 + 6. Current implementations .................................... 60 + 7. Current problems ........................................... 60 + 7.1 Nicknames .............................................. 60 + 7.2 Limitation of wildcards ................................ 61 + 7.3 Security considerations ................................ 61 + 8. Current support and availability ........................... 61 + 9. Acknowledgements ........................................... 61 + 10. References ................................................ 62 + 11. Author's Address .......................................... 62 + 12. Full Copyright Statement .................................. 63 + +1. Labels + + This section defines the identifiers used for the various components + of the IRC protocol. + +1.1 Servers + + Servers are uniquely identified by their name, which has a maximum + length of sixty three (63) characters. See the protocol grammar + rules (section 2.3.1) for what may and may not be used in a server + name. + +1.2 Clients + + For each client all servers MUST have the following information: a + netwide unique identifier (whose format depends on the type of + client) and the server which introduced the client. + + + + + + + + + +Kalt Informational [Page 3] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +1.2.1 Users + + Each user is distinguished from other users by a unique nickname + having a maximum length of nine (9) characters. See the protocol + grammar rules (section 2.3.1) for what may and may not be used in a + nickname. + + While the maximum length is limited to nine characters, clients + SHOULD accept longer strings as they may become used in future + evolutions of the protocol. + +1.2.1.1 Operators + + To allow a reasonable amount of order to be kept within the IRC + network, a special class of users (operators) is allowed to perform + general maintenance functions on the network. Although the powers + granted to an operator can be considered as 'dangerous', they are + nonetheless often necessary. Operators SHOULD be able to perform + basic network tasks such as disconnecting and reconnecting servers as + needed. In recognition of this need, the protocol discussed herein + provides for operators only to be able to perform such functions. + See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT). + + A more controversial power of operators is the ability to remove a + user from the connected network by 'force', i.e., operators are able + to close the connection between any client and server. The + justification for this is very delicate since its abuse is both + destructive and annoying, and its benefits close to inexistent. For + further details on this type of action, see section 3.7.1 (KILL). + +1.2.2 Services + + Each service is distinguished from other services by a service name + composed of a nickname and a server name. As for users, the nickname + has a maximum length of nine (9) characters. See the protocol + grammar rules (section 2.3.1) for what may and may not be used in a + nickname. + +1.3 Channels + + Channels names are strings (beginning with a '&', '#', '+' or '!' + character) of length up to fifty (50) characters. Apart from the + requirement that the first character is either '&', '#', '+' or '!', + the only restriction on a channel name is that it SHALL NOT contain + any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space + is used as parameter separator and command is used as a list item + separator by the protocol). A colon (':') can also be used as a + delimiter for the channel mask. Channel names are case insensitive. + + + +Kalt Informational [Page 4] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + See the protocol grammar rules (section 2.3.1) for the exact syntax + of a channel name. + + Each prefix characterizes a different channel type. The definition + of the channel types is not relevant to the client-server protocol + and thus it is beyond the scope of this document. More details can + be found in "Internet Relay Chat: Channel Management" [IRC-CHAN]. + +2. The IRC Client Specification + +2.1 Overview + + The protocol as described herein is for use only with client to + server connections when the client registers as a user. + +2.2 Character codes + + No specific character set is specified. The protocol is based on a + set of codes which are composed of eight (8) bits, making up an + octet. Each message may be composed of any number of these octets; + however, some octet values are used for control codes, which act as + message delimiters. + + Regardless of being an 8-bit protocol, the delimiters and keywords + are such that protocol is mostly usable from US-ASCII terminal and a + telnet connection. + + Because of IRC's Scandinavian origin, the characters {}|^ are + considered to be the lower case equivalents of the characters []\~, + respectively. This is a critical issue when determining the + equivalence of two nicknames or channel names. + +2.3 Messages + + Servers and clients send each other messages, which may or may not + generate a reply. If the message contains a valid command, as + described in later sections, the client should expect a reply as + specified but it is not advised to wait forever for the reply; client + to server and server to server communication is essentially + asynchronous by nature. + + Each IRC message may consist of up to three main parts: the prefix + (OPTIONAL), the command, and the command parameters (maximum of + fifteen (15)). The prefix, command, and all parameters are separated + by one ASCII space character (0x20) each. + + + + + + +Kalt Informational [Page 5] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + The presence of a prefix is indicated with a single leading ASCII + colon character (':', 0x3b), which MUST be the first character of the + message itself. There MUST be NO gap (whitespace) between the colon + and the prefix. The prefix is used by servers to indicate the true + origin of the message. If the prefix is missing from the message, it + is assumed to have originated from the connection from which it was + received from. Clients SHOULD NOT use a prefix when sending a + message; if they use one, the only valid prefix is the registered + nickname associated with the client. + + The command MUST either be a valid IRC command or a three (3) digit + number represented in ASCII text. + + IRC messages are always lines of characters terminated with a CR-LF + (Carriage Return - Line Feed) pair, and these messages SHALL NOT + exceed 512 characters in length, counting all characters including + the trailing CR-LF. Thus, there are 510 characters maximum allowed + for the command and its parameters. There is no provision for + continuation of message lines. See section 6 for more details about + current implementations. + +2.3.1 Message format in Augmented BNF + + The protocol messages must be extracted from the contiguous stream of + octets. The current solution is to designate two characters, CR and + LF, as message separators. Empty messages are silently ignored, + which permits use of the sequence CR-LF between messages without + extra problems. + + The extracted message is parsed into the components <prefix>, + <command> and list of parameters (<params>). + + The Augmented BNF representation for this is: + + message = [ ":" prefix SPACE ] command [ params ] crlf + prefix = servername / ( nickname [ [ "!" user ] "@" host ] ) + command = 1*letter / 3digit + params = *14( SPACE middle ) [ SPACE ":" trailing ] + =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ] + + nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF + ; any octet except NUL, CR, LF, " " and ":" + middle = nospcrlfcl *( ":" / nospcrlfcl ) + trailing = *( ":" / " " / nospcrlfcl ) + + SPACE = %x20 ; space character + crlf = %x0D %x0A ; "carriage return" "linefeed" + + + + +Kalt Informational [Page 6] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + NOTES: + 1) After extracting the parameter list, all parameters are equal + whether matched by <middle> or <trailing>. <trailing> is just a + syntactic trick to allow SPACE within the parameter. + + 2) The NUL (%x00) character is not special in message framing, and + basically could end up inside a parameter, but it would cause + extra complexities in normal C string handling. Therefore, NUL + is not allowed within messages. + + Most protocol messages specify additional semantics and syntax for + the extracted parameter strings dictated by their position in the + list. For example, many server commands will assume that the first + parameter after the command is the list of targets, which can be + described with: + + target = nickname / server + msgtarget = msgto *( "," msgto ) + msgto = channel / ( user [ "%" host ] "@" servername ) + msgto =/ ( user "%" host ) / targetmask + msgto =/ nickname / ( nickname "!" user "@" host ) + channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring + [ ":" chanstring ] + servername = hostname + host = hostname / hostaddr + hostname = shortname *( "." shortname ) + shortname = ( letter / digit ) *( letter / digit / "-" ) + *( letter / digit ) + ; as specified in RFC 1123 [HNAME] + hostaddr = ip4addr / ip6addr + ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit + ip6addr = 1*hexdigit 7( ":" 1*hexdigit ) + ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr + nickname = ( letter / special ) *8( letter / digit / special / "-" ) + targetmask = ( "$" / "#" ) mask + ; see details on allowed masks in section 3.3.1 + chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B + chanstring =/ %x2D-39 / %x3B-FF + ; any octet except NUL, BELL, CR, LF, " ", "," and ":" + channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 ) + + + + + + + + + + + +Kalt Informational [Page 7] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Other parameter syntaxes are: + + user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF ) + ; any octet except NUL, CR, LF, " " and "@" + key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F ) + ; any 7-bit US_ASCII character, + ; except NUL, CR, LF, FF, h/v TABs, and " " + letter = %x41-5A / %x61-7A ; A-Z / a-z + digit = %x30-39 ; 0-9 + hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F" + special = %x5B-60 / %x7B-7D + ; "[", "]", "\", "`", "_", "^", "{", "|", "}" + + NOTES: + 1) The <hostaddr> syntax is given here for the sole purpose of + indicating the format to follow for IP addresses. This + reflects the fact that the only available implementations of + this protocol uses TCP/IP as underlying network protocol but is + not meant to prevent other protocols to be used. + + 2) <hostname> has a maximum length of 63 characters. This is a + limitation of the protocol as internet hostnames (in + particular) can be longer. Such restriction is necessary + because IRC messages are limited to 512 characters in length. + Clients connecting from a host which name is longer than 63 + characters are registered using the host (numeric) address + instead of the host name. + + 3) Some parameters used in the following sections of this + documents are not defined here as there is nothing specific + about them besides the name that is used for convenience. + These parameters follow the general syntax defined for + <params>. + +2.4 Numeric replies + + Most of the messages sent to the server generate a reply of some + sort. The most common reply is the numeric reply, used for both + errors and normal replies. The numeric reply MUST be sent as one + message consisting of the sender prefix, the three-digit numeric, and + the target of the reply. A numeric reply is not allowed to originate + from a client. In all other respects, a numeric reply is just like a + normal message, except that the keyword is made up of 3 numeric + digits rather than a string of letters. A list of different replies + is supplied in section 5 (Replies). + + + + + + +Kalt Informational [Page 8] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +2.5 Wildcard expressions + + When wildcards are allowed in a string, it is referred as a "mask". + + For string matching purposes, the protocol allows the use of two + special characters: '?' (%x3F) to match one and only one character, + and '*' (%x2A) to match any number of any characters. These two + characters can be escaped using the character '\' (%x5C). + + The Augmented BNF syntax for this is: + + mask = *( nowild / noesc wildone / noesc wildmany ) + wildone = %x3F + wildmany = %x2A + nowild = %x01-29 / %x2B-3E / %x40-FF + ; any octet except NUL, "*", "?" + noesc = %x01-5B / %x5D-FF + ; any octet except NUL and "\" + matchone = %x01-FF + ; matches wildone + matchmany = *matchone + ; matches wildmany + + Examples: + + a?c ; Matches any string of 3 characters in length starting + with "a" and ending with "c" + + a*c ; Matches any string of at least 2 characters in length + starting with "a" and ending with "c" + +3. Message Details + + On the following pages there are descriptions of each message + recognized by the IRC server and client. All commands described in + this section MUST be implemented by any server for this protocol. + + Where the reply ERR_NOSUCHSERVER is returned, it means that the + target of the message could not be found. The server MUST NOT send + any other replies after this error for that command. + + The server to which a client is connected is required to parse the + complete message, and return any appropriate errors. + + If multiple parameters is presented, then each MUST be checked for + validity and appropriate responses MUST be sent back to the client. + In the case of incorrect messages which use parameter lists with + comma as an item separator, a reply MUST be sent for each item. + + + +Kalt Informational [Page 9] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.1 Connection Registration + + The commands described here are used to register a connection with an + IRC server as a user as well as to correctly disconnect. + + A "PASS" command is not required for a client connection to be + registered, but it MUST precede the latter of the NICK/USER + combination (for a user connection) or the SERVICE command (for a + service connection). The RECOMMENDED order for a client to register + is as follows: + + 1. Pass message + 2. Nick message 2. Service message + 3. User message + + Upon success, the client will receive an RPL_WELCOME (for users) or + RPL_YOURESERVICE (for services) message indicating that the + connection is now registered and known the to the entire IRC network. + The reply message MUST contain the full client identifier upon which + it was registered. + +3.1.1 Password message + + Command: PASS + Parameters: <password> + + The PASS command is used to set a 'connection password'. The + optional password can and MUST be set before any attempt to register + the connection is made. Currently this requires that user send a + PASS command before sending the NICK/USER combination. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + PASS secretpasswordhere + +3.1.2 Nick message + + + Command: NICK + Parameters: <nickname> + + NICK command is used to give user a nickname or change the existing + one. + + + + +Kalt Informational [Page 10] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME + ERR_NICKNAMEINUSE ERR_NICKCOLLISION + ERR_UNAVAILRESOURCE ERR_RESTRICTED + + Examples: + + NICK Wiz ; Introducing new nick "Wiz" if session is + still unregistered, or user changing his + nickname to "Wiz" + + :WiZ!jto@tolsun.oulu.fi NICK Kilroy + ; Server telling that WiZ changed his + nickname to Kilroy. + +3.1.3 User message + + Command: USER + Parameters: <user> <mode> <unused> <realname> + + The USER command is used at the beginning of connection to specify + the username, hostname and realname of a new user. + + The <mode> parameter should be a numeric, and can be used to + automatically set user modes when registering with the server. This + parameter is a bitmask, with only 2 bits having any signification: if + the bit 2 is set, the user mode 'w' will be set and if the bit 3 is + set, the user mode 'i' will be set. (See Section 3.1.5 "User + Modes"). + + The <realname> may contain space characters. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + USER guest 0 * :Ronnie Reagan ; User registering themselves with a + username of "guest" and real name + "Ronnie Reagan". + + USER guest 8 * :Ronnie Reagan ; User registering themselves with a + username of "guest" and real name + "Ronnie Reagan", and asking to be set + invisible. + + + + +Kalt Informational [Page 11] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.1.4 Oper message + + Command: OPER + Parameters: <name> <password> + + A normal user uses the OPER command to obtain operator privileges. + The combination of <name> and <password> are REQUIRED to gain + Operator privileges. Upon success, the user will receive a MODE + message (see section 3.1.5) indicating the new user modes. + + Numeric Replies: + + ERR_NEEDMOREPARAMS RPL_YOUREOPER + ERR_NOOPERHOST ERR_PASSWDMISMATCH + + Example: + + OPER foo bar ; Attempt to register as an operator + using a username of "foo" and "bar" + as the password. + +3.1.5 User mode message + + Command: MODE + Parameters: <nickname> + *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) ) + + The user MODE's are typically changes which affect either how the + client is seen by others or what 'extra' messages the client is sent. + + A user MODE command MUST only be accepted if both the sender of the + message and the nickname given as a parameter are both the same. If + no other parameter is given, then the server will return the current + settings for the nick. + + The available modes are as follows: + + a - user is flagged as away; + i - marks a users as invisible; + w - user receives wallops; + r - restricted user connection; + o - operator flag; + O - local operator flag; + s - marks a user for receipt of server notices. + + Additional modes may be available later on. + + + + + +Kalt Informational [Page 12] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + The flag 'a' SHALL NOT be toggled by the user using the MODE command, + instead use of the AWAY command is REQUIRED. + + If a user attempts to make themselves an operator using the "+o" or + "+O" flag, the attempt SHOULD be ignored as users could bypass the + authentication mechanisms of the OPER command. There is no + restriction, however, on anyone `deopping' themselves (using "-o" or + "-O"). + + On the other hand, if a user attempts to make themselves unrestricted + using the "-r" flag, the attempt SHOULD be ignored. There is no + restriction, however, on anyone `deopping' themselves (using "+r"). + This flag is typically set by the server upon connection for + administrative reasons. While the restrictions imposed are left up + to the implementation, it is typical that a restricted user not be + allowed to change nicknames, nor make use of the channel operator + status on channels. + + The flag 's' is obsolete but MAY still be used. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH + ERR_UMODEUNKNOWNFLAG RPL_UMODEIS + + Examples: + + MODE WiZ -w ; Command by WiZ to turn off + reception of WALLOPS messages. + + MODE Angel +i ; Command from Angel to make herself + invisible. + + MODE WiZ -o ; WiZ 'deopping' (removing operator + status). + +3.1.6 Service message + + Command: SERVICE + Parameters: <nickname> <reserved> <distribution> <type> + <reserved> <info> + + The SERVICE command to register a new service. Command parameters + specify the service nickname, distribution, type and info of a new + service. + + + + + + +Kalt Informational [Page 13] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + The <distribution> parameter is used to specify the visibility of a + service. The service may only be known to servers which have a name + matching the distribution. For a matching server to have knowledge + of the service, the network path between that server and the server + on which the service is connected MUST be composed of servers which + names all match the mask. + + The <type> parameter is currently reserved for future usage. + + Numeric Replies: + + ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS + ERR_ERRONEUSNICKNAME + RPL_YOURESERVICE RPL_YOURHOST + RPL_MYINFO + + Example: + + SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering + itself with a name of "dict". This + service will only be available on + servers which name matches "*.fr". + +3.1.7 Quit + + Command: QUIT + Parameters: [ <Quit Message> ] + + A client session is terminated with a quit message. The server + acknowledges this by sending an ERROR message to the client. + + Numeric Replies: + + None. + + Example: + + QUIT :Gone to have lunch ; Preferred message format. + + :syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User + syrk has quit IRC to have lunch. + + + + + + + + + + +Kalt Informational [Page 14] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.1.8 Squit + + Command: SQUIT + Parameters: <server> <comment> + + The SQUIT command is available only to operators. It is used to + disconnect server links. Also servers can generate SQUIT messages on + error conditions. A SQUIT message may also target a remote server + connection. In this case, the SQUIT message will simply be sent to + the remote server without affecting the servers in between the + operator and the remote server. + + The <comment> SHOULD be supplied by all operators who execute a SQUIT + for a remote server. The server ordered to disconnect its peer + generates a WALLOPS message with <comment> included, so that other + users may be aware of the reason of this action. + + Numeric replies: + + ERR_NOPRIVILEGES ERR_NOSUCHSERVER + ERR_NEEDMOREPARAMS + + Examples: + + SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server + tolson.oulu.fi to terminate its + connection with comment "Bad Link". + + :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command + from Trillian from to disconnect + "cm22.eng.umd.edu" from the net with + comment "Server out of control". + +3.2 Channel operations + + This group of messages is concerned with manipulating channels, their + properties (channel modes), and their contents (typically users). + For this reason, these messages SHALL NOT be made available to + services. + + All of these messages are requests which will or will not be granted + by the server. The server MUST send a reply informing the user + whether the request was granted, denied or generated an error. When + the server grants the request, the message is typically sent back + (eventually reformatted) to the user with the prefix set to the user + itself. + + + + + +Kalt Informational [Page 15] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + The rules governing how channels are managed are enforced by the + servers. These rules are beyond the scope of this document. More + details are found in "Internet Relay Chat: Channel Management" [IRC- + CHAN]. + +3.2.1 Join message + + Command: JOIN + Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] ) + / "0" + + The JOIN command is used by a user to request to start listening to + the specific channel. Servers MUST be able to parse arguments in the + form of a list of target, but SHOULD NOT use lists when sending JOIN + messages to clients. + + Once a user has joined a channel, he receives information about + all commands his server receives affecting the channel. This + includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. + This allows channel members to keep track of the other channel + members, as well as channel modes. + + If a JOIN is successful, the user receives a JOIN message as + confirmation and is then sent the channel's topic (using RPL_TOPIC) and + the list of users who are on the channel (using RPL_NAMREPLY), which + MUST include the user joining. + + Note that this message accepts a special argument ("0"), which is + a special request to leave all channels the user is currently a member + of. The server will process this message as if the user had sent + a PART command (See Section 3.2.2) for each channel he is a member + of. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN + ERR_INVITEONLYCHAN ERR_BADCHANNELKEY + ERR_CHANNELISFULL ERR_BADCHANMASK + ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS + ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE + RPL_TOPIC + + Examples: + + JOIN #foobar ; Command to join channel #foobar. + + JOIN &foo fubar ; Command to join channel &foo using + key "fubar". + + + +Kalt Informational [Page 16] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + JOIN #foo,&bar fubar ; Command to join channel #foo using + key "fubar" and &bar using no key. + + JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using + key "fubar", and channel #bar using + key "foobar". + + JOIN #foo,#bar ; Command to join channels #foo and + #bar. + + JOIN 0 ; Leave all currently joined + channels. + + :WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ + on channel #Twilight_zone + +3.2.2 Part message + + Command: PART + Parameters: <channel> *( "," <channel> ) [ <Part Message> ] + + The PART command causes the user sending the message to be removed + from the list of active members for all given channels listed in the + parameter string. If a "Part Message" is given, this will be sent + instead of the default message, the nickname. This request is always + granted by the server. + + Servers MUST be able to parse arguments in the form of a list of + target, but SHOULD NOT use lists when sending PART messages to + clients. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_NOTONCHANNEL + + Examples: + + PART #twilight_zone ; Command to leave channel + "#twilight_zone" + + PART #oz-ops,&group5 ; Command to leave both channels + "&group5" and "#oz-ops". + + :WiZ!jto@tolsun.oulu.fi PART #playzone :I lost + ; User WiZ leaving channel + "#playzone" with the message "I + lost". + + + +Kalt Informational [Page 17] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.2.3 Channel mode message + + Command: MODE + Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> ) + + The MODE command is provided so that users may query and change the + characteristics of a channel. For more details on available modes + and their uses, see "Internet Relay Chat: Channel Management" [IRC- + CHAN]. Note that there is a maximum limit of three (3) changes per + command for modes that take a parameter. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_KEYSET + ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED + ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE + RPL_CHANNELMODEIS + RPL_BANLIST RPL_ENDOFBANLIST + RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST + RPL_INVITELIST RPL_ENDOFINVITELIST + RPL_UNIQOPIS + + The following examples are given to help understanding the syntax of + the MODE command, but refer to modes defined in "Internet Relay Chat: + Channel Management" [IRC-CHAN]. + + Examples: + + MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel + moderated and 'invite-only' with user + with a hostname matching *.fi + automatically invited. + + MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges + to Kilroy on channel #Finnish. + + MODE #Finnish +v Wiz ; Command to allow WiZ to speak on + #Finnish. + + MODE #Fins -s ; Command to remove 'secret' flag + from channel #Fins. + + MODE #42 +k oulu ; Command to set the channel key to + "oulu". + + MODE #42 -k oulu ; Command to remove the "oulu" + channel key on channel "#42". + + + + +Kalt Informational [Page 18] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + MODE #eu-opers +l 10 ; Command to set the limit for the + number of users on channel + "#eu-opers" to 10. + + :WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l + ; User "WiZ" removing the limit for + the number of users on channel "#eu- + opers". + + MODE &oulu +b ; Command to list ban masks set for + the channel "&oulu". + + MODE &oulu +b *!*@* ; Command to prevent all users from + joining. + + MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu + ; Command to prevent any user from a + hostname matching *.edu from joining, + except if matching *.bu.edu + + MODE #bu +be *!*@*.edu *!*@*.bu.edu + ; Comment to prevent any user from a + hostname matching *.edu from joining, + except if matching *.bu.edu + + MODE #meditation e ; Command to list exception masks set + for the channel "#meditation". + + MODE #meditation I ; Command to list invitations masks + set for the channel "#meditation". + + MODE !12345ircd O ; Command to ask who the channel + creator for "!12345ircd" is + +3.2.4 Topic message + + Command: TOPIC + Parameters: <channel> [ <topic> ] + + The TOPIC command is used to change or view the topic of a channel. + The topic for channel <channel> is returned if there is no <topic> + given. If the <topic> parameter is present, the topic for that + channel will be changed, if this action is allowed for the user + requesting it. If the <topic> parameter is an empty string, the + topic for that channel will be removed. + + + + + + +Kalt Informational [Page 19] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL + RPL_NOTOPIC RPL_TOPIC + ERR_CHANOPRIVSNEEDED ERR_NOCHANMODES + + Examples: + + :WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the + topic. + + TOPIC #test :another topic ; Command to set the topic on #test + to "another topic". + + TOPIC #test : ; Command to clear the topic on + #test. + + TOPIC #test ; Command to check the topic for + #test. + +3.2.5 Names message + + Command: NAMES + Parameters: [ <channel> *( "," <channel> ) [ <target> ] ] + + By using the NAMES command, a user can list all nicknames that are + visible to him. For more details on what is visible and what is not, + see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The + <channel> parameter specifies which channel(s) to return information + about. There is no error reply for bad channel names. + + If no <channel> parameter is given, a list of all channels and their + occupants is returned. At the end of this list, a list of users who + are visible but either not on any channel or not on a visible channel + are listed as being on `channel' "*". + + If the <target> parameter is specified, the request is forwarded to + that server which will generate the reply. + + Wildcards are allowed in the <target> parameter. + + Numerics: + + ERR_TOOMANYMATCHES ERR_NOSUCHSERVER + RPL_NAMREPLY RPL_ENDOFNAMES + + + + + + +Kalt Informational [Page 20] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + NAMES #twilight_zone,#42 ; Command to list visible users on + #twilight_zone and #42 + + NAMES ; Command to list all visible + channels and users + +3.2.6 List message + + Command: LIST + Parameters: [ <channel> *( "," <channel> ) [ <target> ] ] + + The list command is used to list channels and their topics. If the + <channel> parameter is used, only the status of that channel is + displayed. + + If the <target> parameter is specified, the request is forwarded to + that server which will generate the reply. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_TOOMANYMATCHES ERR_NOSUCHSERVER + RPL_LIST RPL_LISTEND + + Examples: + + LIST ; Command to list all channels. + + LIST #twilight_zone,#42 ; Command to list channels + #twilight_zone and #42 + +3.2.7 Invite message + + Command: INVITE + Parameters: <nickname> <channel> + + The INVITE command is used to invite a user to a channel. The + parameter <nickname> is the nickname of the person to be invited to + the target channel <channel>. There is no requirement that the + channel the target user is being invited to must exist or be a valid + channel. However, if the channel exists, only members of the channel + are allowed to invite other users. When the channel has invite-only + flag set, only channel operators may issue INVITE command. + + + + + +Kalt Informational [Page 21] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Only the user inviting and the user being invited will receive + notification of the invitation. Other channel members are not + notified. (This is unlike the MODE changes, and is occasionally the + source of trouble for users.) + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHNICK + ERR_NOTONCHANNEL ERR_USERONCHANNEL + ERR_CHANOPRIVSNEEDED + RPL_INVITING RPL_AWAY + + Examples: + + :Angel!wings@irc.org INVITE Wiz #Dust + + ; Message to WiZ when he has been + invited by user Angel to channel + #Dust + + INVITE Wiz #Twilight_Zone ; Command to invite WiZ to + #Twilight_zone + +3.2.8 Kick command + + Command: KICK + Parameters: <channel> *( "," <channel> ) <user> *( "," <user> ) + [<comment>] + + The KICK command can be used to request the forced removal of a user + from a channel. It causes the <user> to PART from the <channel> by + force. For the message to be syntactically correct, there MUST be + either one channel parameter and multiple user parameter, or as many + channel parameters as there are user parameters. If a "comment" is + given, this will be sent instead of the default message, the nickname + of the user issuing the KICK. + + The server MUST NOT send KICK messages with multiple channels or + users to clients. This is necessarily to maintain backward + compatibility with old client software. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED + ERR_USERNOTINCHANNEL ERR_NOTONCHANNEL + + + + + +Kalt Informational [Page 22] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + KICK &Melbourne Matthew ; Command to kick Matthew from + &Melbourne + + KICK #Finnish John :Speaking English + ; Command to kick John from #Finnish + using "Speaking English" as the + reason (comment). + + :WiZ!jto@tolsun.oulu.fi KICK #Finnish John + ; KICK message on channel #Finnish + from WiZ to remove John from channel + +3.3 Sending messages + + The main purpose of the IRC protocol is to provide a base for clients + to communicate with each other. PRIVMSG, NOTICE and SQUERY + (described in Section 3.5 on Service Query and Commands) are the only + messages available which actually perform delivery of a text message + from one client to another - the rest just make it possible and try + to ensure it happens in a reliable and structured manner. + +3.3.1 Private messages + + Command: PRIVMSG + Parameters: <msgtarget> <text to be sent> + + PRIVMSG is used to send private messages between users, as well as to + send messages to channels. <msgtarget> is usually the nickname of + the recipient of the message, or a channel name. + + The <msgtarget> parameter may also be a host mask (#<mask>) or server + mask ($<mask>). In both cases the server will only send the PRIVMSG + to those who have a server or host matching the mask. The mask MUST + have at least 1 (one) "." in it and no wildcards following the last + ".". This requirement exists to prevent people sending messages to + "#*" or "$*", which would broadcast to all users. Wildcards are the + '*' and '?' characters. This extension to the PRIVMSG command is + only available to operators. + + Numeric Replies: + + ERR_NORECIPIENT ERR_NOTEXTTOSEND + ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL + ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS + ERR_NOSUCHNICK + RPL_AWAY + + + +Kalt Informational [Page 23] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + :Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ? + ; Message from Angel to Wiz. + + PRIVMSG Angel :yes I'm receiving it ! + ; Command to send a message to Angel. + + PRIVMSG jto@tolsun.oulu.fi :Hello ! + ; Command to send a message to a user + on server tolsun.oulu.fi with + username of "jto". + + PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog? + ; Message to a user on server + irc.stealth.net with username of + "kalt", and connected from the host + millennium.stealth.net. + + PRIVMSG kalt%millennium.stealth.net :Do you like cheese? + ; Message to a user on the local + server with username of "kalt", and + connected from the host + millennium.stealth.net. + + PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello ! + ; Message to the user with nickname + Wiz who is connected from the host + tolsun.oulu.fi and has the username + "jto". + + PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. + ; Message to everyone on a server + which has a name matching *.fi. + + PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions + ; Message to all users who come from + a host which has a name matching + *.edu. + +3.3.2 Notice + + Command: NOTICE + Parameters: <msgtarget> <text> + + The NOTICE command is used similarly to PRIVMSG. The difference + between NOTICE and PRIVMSG is that automatic replies MUST NEVER be + sent in response to a NOTICE message. This rule applies to servers + + + +Kalt Informational [Page 24] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + too - they MUST NOT send any error reply back to the client on + receipt of a notice. The object of this rule is to avoid loops + between clients automatically sending something in response to + something it received. + + This command is available to services as well as users. + + This is typically used by services, and automatons (clients with + either an AI or other interactive program controlling their actions). + + See PRIVMSG for more details on replies and examples. + +3.4 Server queries and commands + + The server query group of commands has been designed to return + information about any server which is connected to the network. + + In these queries, where a parameter appears as <target>, wildcard + masks are usually valid. For each parameter, however, only one query + and set of replies is to be generated. In most cases, if a nickname + is given, it will mean the server to which the user is connected. + + These messages typically have little value for services, it is + therefore RECOMMENDED to forbid services from using them. + +3.4.1 Motd message + + Command: MOTD + Parameters: [ <target> ] + + The MOTD command is used to get the "Message Of The Day" of the given + server, or current server if <target> is omitted. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + RPL_MOTDSTART RPL_MOTD + RPL_ENDOFMOTD ERR_NOMOTD + +3.4.2 Lusers message + + Command: LUSERS + Parameters: [ <mask> [ <target> ] ] + + The LUSERS command is used to get statistics about the size of the + IRC network. If no parameter is given, the reply will be about the + whole net. If a <mask> is specified, then the reply will only + + + + +Kalt Informational [Page 25] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + concern the part of the network formed by the servers matching the + mask. Finally, if the <target> parameter is specified, the request + is forwarded to that server which will generate the reply. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + RPL_LUSERCLIENT RPL_LUSEROP + RPL_LUSERUNKOWN RPL_LUSERCHANNELS + RPL_LUSERME ERR_NOSUCHSERVER + +3.4.3 Version message + + Command: VERSION + Parameters: [ <target> ] + + The VERSION command is used to query the version of the server + program. An optional parameter <target> is used to query the version + of the server program which a client is not directly connected to. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_VERSION + + Examples: + + VERSION tolsun.oulu.fi ; Command to check the version of + server "tolsun.oulu.fi". + +3.4.4 Stats message + + Command: STATS + Parameters: [ <query> [ <target> ] ] + + The stats command is used to query statistics of certain server. If + <query> parameter is omitted, only the end of stats reply is sent + back. + + A query may be given for any single letter which is only checked by + the destination server and is otherwise passed on by intermediate + servers, ignored and unaltered. + + Wildcards are allowed in the <target> parameter. + + + + + +Kalt Informational [Page 26] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Except for the ones below, the list of valid queries is + implementation dependent. The standard queries below SHOULD be + supported by the server: + + l - returns a list of the server's connections, showing how + long each connection has been established and the + traffic over that connection in Kbytes and messages for + each direction; + m - returns the usage count for each of commands supported + by the server; commands for which the usage count is + zero MAY be omitted; + o - returns a list of configured privileged users, + operators; + u - returns a string showing how long the server has been + up. + + It is also RECOMMENDED that client and server access configuration be + published this way. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_STATSLINKINFO RPL_STATSUPTIME + RPL_STATSCOMMANDS RPL_STATSOLINE + RPL_ENDOFSTATS + + Examples: + + STATS m ; Command to check the command usage + for the server you are connected to + +3.4.5 Links message + + Command: LINKS + Parameters: [ [ <remote server> ] <server mask> ] + + With LINKS, a user can list all servernames, which are known by the + server answering the query. The returned list of servers MUST match + the mask, or if no mask is given, the full list is returned. + + If <remote server> is given in addition to <server mask>, the LINKS + command is forwarded to the first server found that matches that name + (if any), and that server is then required to answer the query. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_LINKS RPL_ENDOFLINKS + + + +Kalt Informational [Page 27] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + LINKS *.au ; Command to list all servers which + have a name that matches *.au; + + LINKS *.edu *.bu.edu ; Command to list servers matching + *.bu.edu as seen by the first server + matching *.edu. + +3.4.6 Time message + + Command: TIME + Parameters: [ <target> ] + + The time command is used to query local time from the specified + server. If the <target> parameter is not given, the server receiving + the command must reply to the query. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_TIME + + Examples: + TIME tolsun.oulu.fi ; check the time on the server + "tolson.oulu.fi" + +3.4.7 Connect message + + Command: CONNECT + Parameters: <target server> <port> [ <remote server> ] + + The CONNECT command can be used to request a server to try to + establish a new connection to another server immediately. CONNECT is + a privileged command and SHOULD be available only to IRC Operators. + If a <remote server> is given and its mask doesn't match name of the + parsing server, the CONNECT attempt is sent to the first match of + remote server. Otherwise the CONNECT attempt is made by the server + processing the request. + + The server receiving a remote CONNECT command SHOULD generate a + WALLOPS message describing the source and target of the request. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NOPRIVILEGES + ERR_NEEDMOREPARAMS + + + +Kalt Informational [Page 28] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local + server to tolsun.oulu.fi on port 6667 + +3.4.8 Trace message + + Command: TRACE + Parameters: [ <target> ] + + TRACE command is used to find the route to specific server and + information about its peers. Each server that processes this command + MUST report to the sender about it. The replies from pass-through + links form a chain, which shows route to destination. After sending + this reply back, the query MUST be sent to the next server until + given <target> server is reached. + + TRACE command is used to find the route to specific server. Each + server that processes this message MUST tell the sender about it by + sending a reply indicating it is a pass-through link, forming a chain + of replies. After sending this reply back, it MUST then send the + TRACE message to the next server until given server is reached. If + the <target> parameter is omitted, it is RECOMMENDED that TRACE + command sends a message to the sender telling which servers the local + server has direct connection to. + + If the destination given by <target> is an actual server, the + destination server is REQUIRED to report all servers, services and + operators which are connected to it; if the command was issued by an + operator, the server MAY also report all users which are connected to + it. If the destination given by <target> is a nickname, then only a + reply for that nickname is given. If the <target> parameter is + omitted, it is RECOMMENDED that the TRACE command is parsed as + targeted to the processing server. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER + + If the TRACE message is destined for another server, all + intermediate servers must return a RPL_TRACELINK reply to indicate + that the TRACE passed through it and where it is going next. + + RPL_TRACELINK + + + + + +Kalt Informational [Page 29] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + A TRACE reply may be composed of any number of the following + numeric replies. + + RPL_TRACECONNECTING RPL_TRACEHANDSHAKE + RPL_TRACEUNKNOWN RPL_TRACEOPERATOR + RPL_TRACEUSER RPL_TRACESERVER + RPL_TRACESERVICE RPL_TRACENEWTYPE + RPL_TRACECLASS RPL_TRACELOG + RPL_TRACEEND + + Examples: + + TRACE *.oulu.fi ; TRACE to a server matching + *.oulu.fi + +3.4.9 Admin command + + Command: ADMIN + Parameters: [ <target> ] + + The admin command is used to find information about the administrator + of the given server, or current server if <target> parameter is + omitted. Each server MUST have the ability to forward ADMIN messages + to other servers. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_ADMINME RPL_ADMINLOC1 + RPL_ADMINLOC2 RPL_ADMINEMAIL + + Examples: + + ADMIN tolsun.oulu.fi ; request an ADMIN reply from + tolsun.oulu.fi + + ADMIN syrk ; ADMIN request for the server to + which the user syrk is connected + + + + + + + + + + + +Kalt Informational [Page 30] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.4.10 Info command + + Command: INFO + Parameters: [ <target> ] + + The INFO command is REQUIRED to return information describing the + server: its version, when it was compiled, the patchlevel, when it + was started, and any other miscellaneous information which may be + considered to be relevant. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_INFO RPL_ENDOFINFO + + Examples: + + INFO csd.bu.edu ; request an INFO reply from + csd.bu.edu + + INFO Angel ; request info from the server that + Angel is connected to. + +3.5 Service Query and Commands + + The service query group of commands has been designed to return + information about any service which is connected to the network. + +3.5.1 Servlist message + + Command: SERVLIST + Parameters: [ <mask> [ <type> ] ] + + The SERVLIST command is used to list services currently connected to + the network and visible to the user issuing the command. The + optional parameters may be used to restrict the result of the query + (to matching services names, and services type). + + Numeric Replies: + + RPL_SERVLIST RPL_SERVLISTEND + + + + + + + + +Kalt Informational [Page 31] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.5.2 Squery + + Command: SQUERY + Parameters: <servicename> <text> + + The SQUERY command is used similarly to PRIVMSG. The only difference + is that the recipient MUST be a service. This is the only way for a + text message to be delivered to a service. + + See PRIVMSG for more details on replies and example. + + Examples: + + SQUERY irchelp :HELP privmsg + ; Message to the service with + nickname irchelp. + + SQUERY dict@irc.fr :fr2en blaireau + ; Message to the service with name + dict@irc.fr. + +3.6 User based queries + + User queries are a group of commands which are primarily concerned + with finding details on a particular user or group users. When using + wildcards with any of these commands, if they match, they will only + return information on users who are 'visible' to you. The visibility + of a user is determined as a combination of the user's mode and the + common set of channels you are both on. + + Although services SHOULD NOT be using this class of message, they are + allowed to. + +3.6.1 Who query + + Command: WHO + Parameters: [ <mask> [ "o" ] ] + + The WHO command is used by a client to generate a query which returns + a list of information which 'matches' the <mask> parameter given by + the client. In the absence of the <mask> parameter, all visible + (users who aren't invisible (user mode +i) and who don't have a + common channel with the requesting client) are listed. The same + result can be achieved by using a <mask> of "0" or any wildcard which + will end up matching every visible user. + + The <mask> passed to WHO is matched against users' host, server, real + name and nickname if the channel <mask> cannot be found. + + + +Kalt Informational [Page 32] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + If the "o" parameter is passed only operators are returned according + to the <mask> supplied. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_WHOREPLY RPL_ENDOFWHO + + Examples: + + WHO *.fi ; Command to list all users who match + against "*.fi". + + WHO jto* o ; Command to list all users with a + match against "jto*" if they are an + operator. + +3.6.2 Whois query + + Command: WHOIS + Parameters: [ <target> ] <mask> *( "," <mask> ) + + This command is used to query information about particular user. + The server will answer this command with several numeric messages + indicating different statuses of each user which matches the mask (if + you are entitled to see them). If no wildcard is present in the + <mask>, any information about that nick which you are allowed to see + is presented. + + If the <target> parameter is specified, it sends the query to a + specific server. It is useful if you want to know how long the user + in question has been idle as only local server (i.e., the server the + user is directly connected to) knows that information, while + everything else is globally known. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN + RPL_WHOISUSER RPL_WHOISCHANNELS + RPL_WHOISCHANNELS RPL_WHOISSERVER + RPL_AWAY RPL_WHOISOPERATOR + RPL_WHOISIDLE ERR_NOSUCHNICK + RPL_ENDOFWHOIS + + + + + + +Kalt Informational [Page 33] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + WHOIS wiz ; return available user information + about nick WiZ + + WHOIS eff.org trillian ; ask server eff.org for user + information about trillian + +3.6.3 Whowas + + Command: WHOWAS + Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ] + + Whowas asks for information about a nickname which no longer exists. + This may either be due to a nickname change or the user leaving IRC. + In response to this query, the server searches through its nickname + history, looking for any nicks which are lexically the same (no wild + card matching here). The history is searched backward, returning the + most recent entry first. If there are multiple entries, up to + <count> replies will be returned (or all of them if no <count> + parameter is given). If a non-positive number is passed as being + <count>, then a full search is done. + + Wildcards are allowed in the <target> parameter. + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK + RPL_WHOWASUSER RPL_WHOISSERVER + RPL_ENDOFWHOWAS + + Examples: + + WHOWAS Wiz ; return all information in the nick + history about nick "WiZ"; + + WHOWAS Mermaid 9 ; return at most, the 9 most recent + entries in the nick history for + "Mermaid"; + + WHOWAS Trillian 1 *.edu ; return the most recent history for + "Trillian" from the first server + found to match "*.edu". + +3.7 Miscellaneous messages + + Messages in this category do not fit into any of the above categories + but are nonetheless still a part of and REQUIRED by the protocol. + + + +Kalt Informational [Page 34] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.7.1 Kill message + + Command: KILL + Parameters: <nickname> <comment> + + The KILL command is used to cause a client-server connection to be + closed by the server which has the actual connection. Servers + generate KILL messages on nickname collisions. It MAY also be + available available to users who have the operator status. + + Clients which have automatic reconnect algorithms effectively make + this command useless since the disconnection is only brief. It does + however break the flow of data and can be used to stop large amounts + of 'flooding' from abusive users or accidents. Abusive users usually + don't care as they will reconnect promptly and resume their abusive + behaviour. To prevent this command from being abused, any user may + elect to receive KILL messages generated for others to keep an 'eye' + on would be trouble spots. + + In an arena where nicknames are REQUIRED to be globally unique at all + times, KILL messages are sent whenever 'duplicates' are detected + (that is an attempt to register two users with the same nickname) in + the hope that both of them will disappear and only 1 reappear. + + When a client is removed as the result of a KILL message, the server + SHOULD add the nickname to the list of unavailable nicknames in an + attempt to avoid clients to reuse this name immediately which is + usually the pattern of abusive behaviour often leading to useless + "KILL loops". See the "IRC Server Protocol" document [IRC-SERVER] + for more information on this procedure. + + The comment given MUST reflect the actual reason for the KILL. For + server-generated KILLs it usually is made up of details concerning + the origins of the two conflicting nicknames. For users it is left + up to them to provide an adequate reason to satisfy others who see + it. To prevent/discourage fake KILLs from being generated to hide + the identify of the KILLer, the comment also shows a 'kill-path' + which is updated by each server it passes through, each prepending + its name to the path. + + Numeric Replies: + + ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS + ERR_NOSUCHNICK ERR_CANTKILLSERVER + + + + + + + +Kalt Informational [Page 35] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + NOTE: + It is RECOMMENDED that only Operators be allowed to kill other users + with KILL command. This command has been the subject of many + controversies over the years, and along with the above + recommendation, it is also widely recognized that not even operators + should be allowed to kill users on remote servers. + +3.7.2 Ping message + + Command: PING + Parameters: <server1> [ <server2> ] + + The PING command is used to test the presence of an active client or + server at the other end of the connection. Servers send a PING + message at regular intervals if no other activity detected coming + from a connection. If a connection fails to respond to a PING + message within a set amount of time, that connection is closed. A + PING message MAY be sent even if the connection is active. + + When a PING message is received, the appropriate PONG message MUST be + sent as reply to <server1> (server which sent the PING message out) + as soon as possible. If the <server2> parameter is specified, it + represents the target of the ping, and the message gets forwarded + there. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Examples: + + PING tolsun.oulu.fi ; Command to send a PING message to + server + + PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING + message to server "tolsun.oulu.fi" + + PING :irc.funet.fi ; Ping message sent by server + "irc.funet.fi" + + + + + + + + + + + + +Kalt Informational [Page 36] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +3.7.3 Pong message + + Command: PONG + Parameters: <server> [ <server2> ] + + PONG message is a reply to ping message. If parameter <server2> is + given, this message MUST be forwarded to given target. The <server> + parameter is the name of the entity who has responded to PING message + and generated this message. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Example: + + PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to + tolsun.oulu.fi + +3.7.4 Error + + Command: ERROR + Parameters: <error message> + + The ERROR command is for use by servers when reporting a serious or + fatal error to its peers. It may also be sent from one server to + another but MUST NOT be accepted from any normal unknown clients. + + Only an ERROR message SHOULD be used for reporting errors which occur + with a server-to-server link. An ERROR message is sent to the server + at the other end (which reports it to appropriate local users and + logs) and to appropriate local users and logs. It is not to be + passed onto any other servers by a server if it is received from a + server. + + The ERROR message is also used before terminating a client + connection. + + When a server sends a received ERROR message to its operators, the + message SHOULD be encapsulated inside a NOTICE message, indicating + that the client was not responsible for the error. + + Numerics: + + None. + + + + + + +Kalt Informational [Page 37] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + ERROR :Server *.fi already exists ; ERROR message to the other server + which caused this error. + + NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists + ; Same ERROR message as above but + sent to user WiZ on the other server. + +4. Optional features + + This section describes OPTIONAL messages. They are not required in a + working server implementation of the protocol described herein. In + the absence of the feature, an error reply message MUST be generated + or an unknown command error. If the message is destined for another + server to answer then it MUST be passed on (elementary parsing + REQUIRED) The allocated numerics for this are listed with the + messages below. + + From this section, only the USERHOST and ISON messages are available + to services. + +4.1 Away + + Command: AWAY + Parameters: [ <text> ] + + With the AWAY command, clients can set an automatic reply string for + any PRIVMSG commands directed at them (not to a channel they are on). + The server sends an automatic reply to the client sending the PRIVMSG + command. The only replying server is the one to which the sending + client is connected to. + + The AWAY command is used either with one parameter, to set an AWAY + message, or with no parameters, to remove the AWAY message. + + Because of its high cost (memory and bandwidth wise), the AWAY + message SHOULD only be used for client-server communication. A + server MAY choose to silently ignore AWAY messages received from + other servers. To update the away status of a client across servers, + the user mode 'a' SHOULD be used instead. (See Section 3.1.5) + + Numeric Replies: + + RPL_UNAWAY RPL_NOWAWAY + + + + + + +Kalt Informational [Page 38] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Example: + + AWAY :Gone to lunch. Back in 5 ; Command to set away message to + "Gone to lunch. Back in 5". + +4.2 Rehash message + + Command: REHASH + Parameters: None + + The rehash command is an administrative command which can be used by + an operator to force the server to re-read and process its + configuration file. + + Numeric Replies: + + RPL_REHASHING ERR_NOPRIVILEGES + + + Example: + + REHASH ; message from user with operator + status to server asking it to reread + its configuration file. + +4.3 Die message + + Command: DIE + Parameters: None + + An operator can use the DIE command to shutdown the server. This + message is optional since it may be viewed as a risk to allow + arbitrary people to connect to a server as an operator and execute + this command. + + The DIE command MUST always be fully processed by the server to which + the sending client is connected and MUST NOT be passed onto other + connected servers. + + Numeric Replies: + + ERR_NOPRIVILEGES + + Example: + + DIE ; no parameters required. + + + + + +Kalt Informational [Page 39] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +4.4 Restart message + + Command: RESTART + Parameters: None + + An operator can use the restart command to force the server to + restart itself. This message is optional since it may be viewed as a + risk to allow arbitrary people to connect to a server as an operator + and execute this command, causing (at least) a disruption to service. + + The RESTART command MUST always be fully processed by the server to + which the sending client is connected and MUST NOT be passed onto + other connected servers. + + Numeric Replies: + + ERR_NOPRIVILEGES + + Example: + + RESTART ; no parameters required. + +4.5 Summon message + + Command: SUMMON + Parameters: <user> [ <target> [ <channel> ] ] + + The SUMMON command can be used to give users who are on a host + running an IRC server a message asking them to please join IRC. This + message is only sent if the target server (a) has SUMMON enabled, (b) + the user is logged in and (c) the server process can write to the + user's tty (or similar). + + If no <server> parameter is given it tries to summon <user> from the + server the client is connected to is assumed as the target. + + If summon is not enabled in a server, it MUST return the + ERR_SUMMONDISABLED numeric. + + Numeric Replies: + + ERR_NORECIPIENT ERR_FILEERROR + ERR_NOLOGIN ERR_NOSUCHSERVER + ERR_SUMMONDISABLED RPL_SUMMONING + + + + + + + +Kalt Informational [Page 40] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + Examples: + + SUMMON jto ; summon user jto on the server's + host + + SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a + server named "tolsun.oulu.fi" is + running. + +4.6 Users + + Command: USERS + Parameters: [ <target> ] + + The USERS command returns a list of users logged into the server in a + format similar to the UNIX commands who(1), rusers(1) and finger(1). + If disabled, the correct numeric MUST be returned to indicate this. + + Because of the security implications of such a command, it SHOULD be + disabled by default in server implementations. Enabling it SHOULD + require recompiling the server or some equivalent change rather than + simply toggling an option and restarting the server. The procedure + to enable this command SHOULD also include suitable large comments. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_FILEERROR + RPL_USERSSTART RPL_USERS + RPL_NOUSERS RPL_ENDOFUSERS + ERR_USERSDISABLED + + Disabled Reply: + + ERR_USERSDISABLED + + Example: + + USERS eff.org ; request a list of users logged in + on server eff.org + +4.7 Operwall message + + Command: WALLOPS + Parameters: <Text to be sent> + + The WALLOPS command is used to send a message to all currently + connected users who have set the 'w' user mode for themselves. (See + Section 3.1.5 "User modes"). + + + +Kalt Informational [Page 41] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + After implementing WALLOPS as a user command it was found that it was + often and commonly abused as a means of sending a message to a lot of + people. Due to this, it is RECOMMENDED that the implementation of + WALLOPS allows and recognizes only servers as the originators of + WALLOPS. + + Numeric Replies: + + ERR_NEEDMOREPARAMS + + Example: + + :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS + message from csd.bu.edu announcing a + CONNECT message it received from + Joshua and acted upon. + +4.8 Userhost message + + Command: USERHOST + Parameters: <nickname> *( SPACE <nickname> ) + + The USERHOST command takes a list of up to 5 nicknames, each + separated by a space character and returns a list of information + about each nickname that it found. The returned list has each reply + separated by a space. + + Numeric Replies: + + RPL_USERHOST ERR_NEEDMOREPARAMS + + Example: + + USERHOST Wiz Michael syrk ; USERHOST request for information on + nicks "Wiz", "Michael", and "syrk" + + :ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net + ; Reply for user syrk + +4.9 Ison message + + Command: ISON + Parameters: <nickname> *( SPACE <nickname> ) + + The ISON command was implemented to provide a quick and efficient + means to get a response about whether a given nickname was currently + on IRC. ISON only takes one (1) type of parameter: a space-separated + list of nicks. For each nickname in the list that is present, the + + + +Kalt Informational [Page 42] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + server adds that to its reply string. Thus the reply string may + return empty (none of the given nicks are present), an exact copy of + the parameter string (all of them present) or any other subset of the + set of nicks given in the parameter. The only limit on the number of + nicks that may be checked is that the combined length MUST NOT be too + large as to cause the server to chop it off so it fits in 512 + characters. + + ISON is only processed by the server local to the client sending the + command and thus not passed onto other servers for further + processing. + + Numeric Replies: + + RPL_ISON ERR_NEEDMOREPARAMS + + Example: + + ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk + ; Sample ISON request for 7 nicks. + +5. Replies + + The following is a list of numeric replies which are generated in + response to the commands given above. Each numeric is given with its + number, name and reply string. + +5.1 Command responses + + Numerics in the range from 001 to 099 are used for client-server + connections only and should never travel between servers. Replies + generated in the response to commands are found in the range from 200 + to 399. + + 001 RPL_WELCOME + "Welcome to the Internet Relay Network + <nick>!<user>@<host>" + 002 RPL_YOURHOST + "Your host is <servername>, running version <ver>" + 003 RPL_CREATED + "This server was created <date>" + 004 RPL_MYINFO + "<servername> <version> <available user modes> + <available channel modes>" + + - The server sends Replies 001 to 004 to a user upon + successful registration. + + + + +Kalt Informational [Page 43] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 005 RPL_BOUNCE + "Try server <server name>, port <port number>" + + - Sent by the server to a user to suggest an alternative + server. This is often used when the connection is + refused because the server is already full. + + 302 RPL_USERHOST + ":*1<reply> *( " " <reply> )" + + - Reply format used by USERHOST to list replies to + the query list. The reply string is composed as + follows: + + reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname + + The '*' indicates whether the client has registered + as an Operator. The '-' or '+' characters represent + whether the client has set an AWAY message or not + respectively. + + 303 RPL_ISON + ":*1<nick> *( " " <nick> )" + + - Reply format used by ISON to list replies to the + query list. + + 301 RPL_AWAY + "<nick> :<away message>" + 305 RPL_UNAWAY + ":You are no longer marked as being away" + 306 RPL_NOWAWAY + ":You have been marked as being away" + + - These replies are used with the AWAY command (if + allowed). RPL_AWAY is sent to any client sending a + PRIVMSG to a client which is away. RPL_AWAY is only + sent by the server to which the client is connected. + Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the + client removes and sets an AWAY message. + + 311 RPL_WHOISUSER + "<nick> <user> <host> * :<real name>" + 312 RPL_WHOISSERVER + "<nick> <server> :<server info>" + 313 RPL_WHOISOPERATOR + "<nick> :is an IRC operator" + + + + +Kalt Informational [Page 44] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 317 RPL_WHOISIDLE + "<nick> <integer> :seconds idle" + 318 RPL_ENDOFWHOIS + "<nick> :End of WHOIS list" + 319 RPL_WHOISCHANNELS + "<nick> :*( ( "@" / "+" ) <channel> " " )" + + - Replies 311 - 313, 317 - 319 are all replies + generated in response to a WHOIS message. Given that + there are enough parameters present, the answering + server MUST either formulate a reply out of the above + numerics (if the query nick is found) or return an + error reply. The '*' in RPL_WHOISUSER is there as + the literal character and not as a wild card. For + each reply set, only RPL_WHOISCHANNELS may appear + more than once (for long lists of channel names). + The '@' and '+' characters next to the channel name + indicate whether a client is a channel operator or + has been granted permission to speak on a moderated + channel. The RPL_ENDOFWHOIS reply is used to mark + the end of processing a WHOIS message. + + 314 RPL_WHOWASUSER + "<nick> <user> <host> * :<real name>" + 369 RPL_ENDOFWHOWAS + "<nick> :End of WHOWAS" + + - When replying to a WHOWAS message, a server MUST use + the replies RPL_WHOWASUSER, RPL_WHOISSERVER or + ERR_WASNOSUCHNICK for each nickname in the presented + list. At the end of all reply batches, there MUST + be RPL_ENDOFWHOWAS (even if there was only one reply + and it was an error). + + 321 RPL_LISTSTART + Obsolete. Not used. + + 322 RPL_LIST + "<channel> <# visible> :<topic>" + 323 RPL_LISTEND + ":End of LIST" + + - Replies RPL_LIST, RPL_LISTEND mark the actual replies + with data and end of the server's response to a LIST + command. If there are no channels available to return, + only the end reply MUST be sent. + + + + + +Kalt Informational [Page 45] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 325 RPL_UNIQOPIS + "<channel> <nickname>" + + 324 RPL_CHANNELMODEIS + "<channel> <mode> <mode params>" + + 331 RPL_NOTOPIC + "<channel> :No topic is set" + 332 RPL_TOPIC + "<channel> :<topic>" + + - When sending a TOPIC message to determine the + channel topic, one of two replies is sent. If + the topic is set, RPL_TOPIC is sent back else + RPL_NOTOPIC. + + 341 RPL_INVITING + "<channel> <nick>" + + - Returned by the server to indicate that the + attempted INVITE message was successful and is + being passed onto the end client. + + 342 RPL_SUMMONING + "<user> :Summoning user to IRC" + + - Returned by a server answering a SUMMON message to + indicate that it is summoning that user. + + 346 RPL_INVITELIST + "<channel> <invitemask>" + 347 RPL_ENDOFINVITELIST + "<channel> :End of channel invite list" + + - When listing the 'invitations masks' for a given channel, + a server is required to send the list back using the + RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A + separate RPL_INVITELIST is sent for each active mask. + After the masks have been listed (or if none present) a + RPL_ENDOFINVITELIST MUST be sent. + + 348 RPL_EXCEPTLIST + "<channel> <exceptionmask>" + 349 RPL_ENDOFEXCEPTLIST + "<channel> :End of channel exception list" + + + + + + +Kalt Informational [Page 46] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + - When listing the 'exception masks' for a given channel, + a server is required to send the list back using the + RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A + separate RPL_EXCEPTLIST is sent for each active mask. + After the masks have been listed (or if none present) + a RPL_ENDOFEXCEPTLIST MUST be sent. + + 351 RPL_VERSION + "<version>.<debuglevel> <server> :<comments>" + + - Reply by the server showing its version details. + The <version> is the version of the software being + used (including any patchlevel revisions) and the + <debuglevel> is used to indicate if the server is + running in "debug mode". + + The "comments" field may contain any comments about + the version or further version details. + + 352 RPL_WHOREPLY + "<channel> <user> <host> <server> <nick> + ( "H" / "G" > ["*"] [ ( "@" / "+" ) ] + :<hopcount> <real name>" + + 315 RPL_ENDOFWHO + "<name> :End of WHO list" + + - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used + to answer a WHO message. The RPL_WHOREPLY is only + sent if there is an appropriate match to the WHO + query. If there is a list of parameters supplied + with a WHO message, a RPL_ENDOFWHO MUST be sent + after processing each list item with <name> being + the item. + + 353 RPL_NAMREPLY + "( "=" / "*" / "@" ) <channel> + :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> ) + - "@" is used for secret channels, "*" for private + channels, and "=" for others (public channels). + + 366 RPL_ENDOFNAMES + "<channel> :End of NAMES list" + + - To reply to a NAMES message, a reply pair consisting + of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the + server back to the client. If there is no channel + found as in the query, then only RPL_ENDOFNAMES is + + + +Kalt Informational [Page 47] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + returned. The exception to this is when a NAMES + message is sent with no parameters and all visible + channels and contents are sent back in a series of + RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark + the end. + + 364 RPL_LINKS + "<mask> <server> :<hopcount> <server info>" + 365 RPL_ENDOFLINKS + "<mask> :End of LINKS list" + + - In replying to the LINKS message, a server MUST send + replies back using the RPL_LINKS numeric and mark the + end of the list using an RPL_ENDOFLINKS reply. + + 367 RPL_BANLIST + "<channel> <banmask>" + 368 RPL_ENDOFBANLIST + "<channel> :End of channel ban list" + + - When listing the active 'bans' for a given channel, + a server is required to send the list back using the + RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate + RPL_BANLIST is sent for each active banmask. After the + banmasks have been listed (or if none present) a + RPL_ENDOFBANLIST MUST be sent. + + 371 RPL_INFO + ":<string>" + 374 RPL_ENDOFINFO + ":End of INFO list" + + - A server responding to an INFO message is required to + send all its 'info' in a series of RPL_INFO messages + with a RPL_ENDOFINFO reply to indicate the end of the + replies. + + 375 RPL_MOTDSTART + ":- <server> Message of the day - " + 372 RPL_MOTD + ":- <text>" + 376 RPL_ENDOFMOTD + ":End of MOTD command" + + - When responding to the MOTD message and the MOTD file + is found, the file is displayed line by line, with + each line no longer than 80 characters, using + + + + +Kalt Informational [Page 48] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + RPL_MOTD format replies. These MUST be surrounded + by a RPL_MOTDSTART (before the RPL_MOTDs) and an + RPL_ENDOFMOTD (after). + + 381 RPL_YOUREOPER + ":You are now an IRC operator" + + - RPL_YOUREOPER is sent back to a client which has + just successfully issued an OPER message and gained + operator status. + + 382 RPL_REHASHING + "<config file> :Rehashing" + + - If the REHASH option is used and an operator sends + a REHASH message, an RPL_REHASHING is sent back to + the operator. + + 383 RPL_YOURESERVICE + "You are service <servicename>" + + - Sent by the server to a service upon successful + registration. + + 391 RPL_TIME + "<server> :<string showing server's local time>" + + - When replying to the TIME message, a server MUST send + the reply using the RPL_TIME format above. The string + showing the time need only contain the correct day and + time there. There is no further requirement for the + time string. + + 392 RPL_USERSSTART + ":UserID Terminal Host" + 393 RPL_USERS + ":<username> <ttyline> <hostname>" + 394 RPL_ENDOFUSERS + ":End of users" + 395 RPL_NOUSERS + ":Nobody logged in" + + - If the USERS message is handled by a server, the + replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and + RPL_NOUSERS are used. RPL_USERSSTART MUST be sent + first, following by either a sequence of RPL_USERS + or a single RPL_NOUSER. Following this is + RPL_ENDOFUSERS. + + + +Kalt Informational [Page 49] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 200 RPL_TRACELINK + "Link <version & debug level> <destination> + <next server> V<protocol version> + <link uptime in seconds> <backstream sendq> + <upstream sendq>" + 201 RPL_TRACECONNECTING + "Try. <class> <server>" + 202 RPL_TRACEHANDSHAKE + "H.S. <class> <server>" + 203 RPL_TRACEUNKNOWN + "???? <class> [<client IP address in dot form>]" + 204 RPL_TRACEOPERATOR + "Oper <class> <nick>" + 205 RPL_TRACEUSER + "User <class> <nick>" + 206 RPL_TRACESERVER + "Serv <class> <int>S <int>C <server> + <nick!user|*!*>@<host|server> V<protocol version>" + 207 RPL_TRACESERVICE + "Service <class> <name> <type> <active type>" + 208 RPL_TRACENEWTYPE + "<newtype> 0 <client name>" + 209 RPL_TRACECLASS + "Class <class> <count>" + 210 RPL_TRACERECONNECT + Unused. + 261 RPL_TRACELOG + "File <logfile> <debug level>" + 262 RPL_TRACEEND + "<server name> <version & debug level> :End of TRACE" + + - The RPL_TRACE* are all returned by the server in + response to the TRACE message. How many are + returned is dependent on the TRACE message and + whether it was sent by an operator or not. There + is no predefined order for which occurs first. + Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and + RPL_TRACEHANDSHAKE are all used for connections + which have not been fully established and are either + unknown, still attempting to connect or in the + process of completing the 'server handshake'. + RPL_TRACELINK is sent by any server which handles + a TRACE message and has to pass it on to another + server. The list of RPL_TRACELINKs sent in + response to a TRACE command traversing the IRC + network should reflect the actual connectivity of + the servers themselves along that path. + + + + +Kalt Informational [Page 50] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + RPL_TRACENEWTYPE is to be used for any connection + which does not fit in the other categories but is + being displayed anyway. + RPL_TRACEEND is sent to indicate the end of the list. + + 211 RPL_STATSLINKINFO + "<linkname> <sendq> <sent messages> + <sent Kbytes> <received messages> + <received Kbytes> <time open>" + + - reports statistics on a connection. <linkname> + identifies the particular connection, <sendq> is + the amount of data that is queued and waiting to be + sent <sent messages> the number of messages sent, + and <sent Kbytes> the amount of data sent, in + Kbytes. <received messages> and <received Kbytes> + are the equivalent of <sent messages> and <sent + Kbytes> for received data, respectively. <time + open> indicates how long ago the connection was + opened, in seconds. + + 212 RPL_STATSCOMMANDS + "<command> <count> <byte count> <remote count>" + + - reports statistics on commands usage. + + 219 RPL_ENDOFSTATS + "<stats letter> :End of STATS report" + + 242 RPL_STATSUPTIME + ":Server Up %d days %d:%02d:%02d" + + - reports the server uptime. + + 243 RPL_STATSOLINE + "O <hostmask> * <name>" + + - reports the allowed hosts from where user may become IRC + operators. + + 221 RPL_UMODEIS + "<user mode string>" + + - To answer a query about a client's own mode, + RPL_UMODEIS is sent back. + + 234 RPL_SERVLIST + "<name> <server> <mask> <type> <hopcount> <info>" + + + +Kalt Informational [Page 51] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 235 RPL_SERVLISTEND + "<mask> <type> :End of service listing" + + - When listing services in reply to a SERVLIST message, + a server is required to send the list back using the + RPL_SERVLIST and RPL_SERVLISTEND messages. A separate + RPL_SERVLIST is sent for each service. After the + services have been listed (or if none present) a + RPL_SERVLISTEND MUST be sent. + + 251 RPL_LUSERCLIENT + ":There are <integer> users and <integer> + services on <integer> servers" + 252 RPL_LUSEROP + "<integer> :operator(s) online" + 253 RPL_LUSERUNKNOWN + "<integer> :unknown connection(s)" + 254 RPL_LUSERCHANNELS + "<integer> :channels formed" + 255 RPL_LUSERME + ":I have <integer> clients and <integer> + servers" + + - In processing an LUSERS message, the server + sends a set of replies from RPL_LUSERCLIENT, + RPL_LUSEROP, RPL_USERUNKNOWN, + RPL_LUSERCHANNELS and RPL_LUSERME. When + replying, a server MUST send back + RPL_LUSERCLIENT and RPL_LUSERME. The other + replies are only sent back if a non-zero count + is found for them. + + 256 RPL_ADMINME + "<server> :Administrative info" + 257 RPL_ADMINLOC1 + ":<admin info>" + 258 RPL_ADMINLOC2 + ":<admin info>" + 259 RPL_ADMINEMAIL + ":<admin info>" + + - When replying to an ADMIN message, a server + is expected to use replies RPL_ADMINME + through to RPL_ADMINEMAIL and provide a text + message with each. For RPL_ADMINLOC1 a + description of what city, state and country + the server is in is expected, followed by + details of the institution (RPL_ADMINLOC2) + + + +Kalt Informational [Page 52] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + and finally the administrative contact for the + server (an email address here is REQUIRED) + in RPL_ADMINEMAIL. + + 263 RPL_TRYAGAIN + "<command> :Please wait a while and try again." + + - When a server drops a command without processing it, + it MUST use the reply RPL_TRYAGAIN to inform the + originating client. + +5.2 Error Replies + + Error replies are found in the range from 400 to 599. + + 401 ERR_NOSUCHNICK + "<nickname> :No such nick/channel" + + - Used to indicate the nickname parameter supplied to a + command is currently unused. + + 402 ERR_NOSUCHSERVER + "<server name> :No such server" + + - Used to indicate the server name given currently + does not exist. + + 403 ERR_NOSUCHCHANNEL + "<channel name> :No such channel" + + - Used to indicate the given channel name is invalid. + + 404 ERR_CANNOTSENDTOCHAN + "<channel name> :Cannot send to channel" + + - Sent to a user who is either (a) not on a channel + which is mode +n or (b) not a chanop (or mode +v) on + a channel which has mode +m set or where the user is + banned and is trying to send a PRIVMSG message to + that channel. + + 405 ERR_TOOMANYCHANNELS + "<channel name> :You have joined too many channels" + + - Sent to a user when they have joined the maximum + number of allowed channels and they try to join + another channel. + + + + +Kalt Informational [Page 53] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 406 ERR_WASNOSUCHNICK + "<nickname> :There was no such nickname" + + - Returned by WHOWAS to indicate there is no history + information for that nickname. + + 407 ERR_TOOMANYTARGETS + "<target> :<error code> recipients. <abort message>" + + - Returned to a client which is attempting to send a + PRIVMSG/NOTICE using the user@host destination format + and for a user@host which has several occurrences. + + - Returned to a client which trying to send a + PRIVMSG/NOTICE to too many recipients. + + - Returned to a client which is attempting to JOIN a safe + channel using the shortname when there are more than one + such channel. + + 408 ERR_NOSUCHSERVICE + "<service name> :No such service" + + - Returned to a client which is attempting to send a SQUERY + to a service which does not exist. + + 409 ERR_NOORIGIN + ":No origin specified" + + - PING or PONG message missing the originator parameter. + + 411 ERR_NORECIPIENT + ":No recipient given (<command>)" + 412 ERR_NOTEXTTOSEND + ":No text to send" + 413 ERR_NOTOPLEVEL + "<mask> :No toplevel domain specified" + 414 ERR_WILDTOPLEVEL + "<mask> :Wildcard in toplevel domain" + 415 ERR_BADMASK + "<mask> :Bad Server/host mask" + + - 412 - 415 are returned by PRIVMSG to indicate that + the message wasn't delivered for some reason. + ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that + are returned when an invalid use of + "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted. + + + + +Kalt Informational [Page 54] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 421 ERR_UNKNOWNCOMMAND + "<command> :Unknown command" + + - Returned to a registered client to indicate that the + command sent is unknown by the server. + + 422 ERR_NOMOTD + ":MOTD File is missing" + + - Server's MOTD file could not be opened by the server. + + 423 ERR_NOADMININFO + "<server> :No administrative info available" + + - Returned by a server in response to an ADMIN message + when there is an error in finding the appropriate + information. + + 424 ERR_FILEERROR + ":File error doing <file op> on <file>" + + - Generic error message used to report a failed file + operation during the processing of a message. + + 431 ERR_NONICKNAMEGIVEN + ":No nickname given" + + - Returned when a nickname parameter expected for a + command and isn't found. + + 432 ERR_ERRONEUSNICKNAME + "<nick> :Erroneous nickname" + + - Returned after receiving a NICK message which contains + characters which do not fall in the defined set. See + section 2.3.1 for details on valid nicknames. + + 433 ERR_NICKNAMEINUSE + "<nick> :Nickname is already in use" + + - Returned when a NICK message is processed that results + in an attempt to change to a currently existing + nickname. + + + + + + + + +Kalt Informational [Page 55] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 436 ERR_NICKCOLLISION + "<nick> :Nickname collision KILL from <user>@<host>" + + - Returned by a server to a client when it detects a + nickname collision (registered of a NICK that + already exists by another server). + + 437 ERR_UNAVAILRESOURCE + "<nick/channel> :Nick/channel is temporarily unavailable" + + - Returned by a server to a user trying to join a channel + currently blocked by the channel delay mechanism. + + - Returned by a server to a user trying to change nickname + when the desired nickname is blocked by the nick delay + mechanism. + + 441 ERR_USERNOTINCHANNEL + "<nick> <channel> :They aren't on that channel" + + - Returned by the server to indicate that the target + user of the command is not on the given channel. + + 442 ERR_NOTONCHANNEL + "<channel> :You're not on that channel" + + - Returned by the server whenever a client tries to + perform a channel affecting command for which the + client isn't a member. + + 443 ERR_USERONCHANNEL + "<user> <channel> :is already on channel" + + - Returned when a client tries to invite a user to a + channel they are already on. + + 444 ERR_NOLOGIN + "<user> :User not logged in" + + - Returned by the summon after a SUMMON command for a + user was unable to be performed since they were not + logged in. + + + + + + + + + +Kalt Informational [Page 56] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 445 ERR_SUMMONDISABLED + ":SUMMON has been disabled" + + - Returned as a response to the SUMMON command. MUST be + returned by any server which doesn't implement it. + + 446 ERR_USERSDISABLED + ":USERS has been disabled" + + - Returned as a response to the USERS command. MUST be + returned by any server which does not implement it. + + 451 ERR_NOTREGISTERED + ":You have not registered" + + - Returned by the server to indicate that the client + MUST be registered before the server will allow it + to be parsed in detail. + + 461 ERR_NEEDMOREPARAMS + "<command> :Not enough parameters" + + - Returned by the server by numerous commands to + indicate to the client that it didn't supply enough + parameters. + + 462 ERR_ALREADYREGISTRED + ":Unauthorized command (already registered)" + + - Returned by the server to any link which tries to + change part of the registered details (such as + password or user details from second USER message). + + 463 ERR_NOPERMFORHOST + ":Your host isn't among the privileged" + + - Returned to a client which attempts to register with + a server which does not been setup to allow + connections from the host the attempted connection + is tried. + + 464 ERR_PASSWDMISMATCH + ":Password incorrect" + + - Returned to indicate a failed attempt at registering + a connection for which a password was required and + was either not given or incorrect. + + + + +Kalt Informational [Page 57] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 465 ERR_YOUREBANNEDCREEP + ":You are banned from this server" + + - Returned after an attempt to connect and register + yourself with a server which has been setup to + explicitly deny connections to you. + + 466 ERR_YOUWILLBEBANNED + + - Sent by a server to a user to inform that access to the + server will soon be denied. + + 467 ERR_KEYSET + "<channel> :Channel key already set" + 471 ERR_CHANNELISFULL + "<channel> :Cannot join channel (+l)" + 472 ERR_UNKNOWNMODE + "<char> :is unknown mode char to me for <channel>" + 473 ERR_INVITEONLYCHAN + "<channel> :Cannot join channel (+i)" + 474 ERR_BANNEDFROMCHAN + "<channel> :Cannot join channel (+b)" + 475 ERR_BADCHANNELKEY + "<channel> :Cannot join channel (+k)" + 476 ERR_BADCHANMASK + "<channel> :Bad Channel Mask" + 477 ERR_NOCHANMODES + "<channel> :Channel doesn't support modes" + 478 ERR_BANLISTFULL + "<channel> <char> :Channel list is full" + + 481 ERR_NOPRIVILEGES + ":Permission Denied- You're not an IRC operator" + + - Any command requiring operator privileges to operate + MUST return this error to indicate the attempt was + unsuccessful. + + 482 ERR_CHANOPRIVSNEEDED + "<channel> :You're not channel operator" + + - Any command requiring 'chanop' privileges (such as + MODE messages) MUST return this error if the client + making the attempt is not a chanop on the specified + channel. + + + + + + +Kalt Informational [Page 58] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 483 ERR_CANTKILLSERVER + ":You can't kill a server!" + + - Any attempts to use the KILL command on a server + are to be refused and this error returned directly + to the client. + + 484 ERR_RESTRICTED + ":Your connection is restricted!" + + - Sent by the server to a user upon connection to indicate + the restricted nature of the connection (user mode "+r"). + + 485 ERR_UNIQOPPRIVSNEEDED + ":You're not the original channel operator" + + - Any MODE requiring "channel creator" privileges MUST + return this error if the client making the attempt is not + a chanop on the specified channel. + + 491 ERR_NOOPERHOST + ":No O-lines for your host" + + - If a client sends an OPER message and the server has + not been configured to allow connections from the + client's host as an operator, this error MUST be + returned. + + 501 ERR_UMODEUNKNOWNFLAG + ":Unknown MODE flag" + + - Returned by the server to indicate that a MODE + message was sent with a nickname parameter and that + the a mode flag sent was not recognized. + + 502 ERR_USERSDONTMATCH + ":Cannot change mode for other users" + + - Error sent to any user trying to view or change the + user mode for a user other than themselves. + +5.3 Reserved numerics + + These numerics are not described above since they fall into one of + the following categories: + + 1. no longer in use; + + + + +Kalt Informational [Page 59] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + + 2. reserved for future planned use; + + 3. in current use but are part of a non-generic 'feature' of + the current IRC server. + + 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES + 233 RPL_SERVICE + 300 RPL_NONE 316 RPL_WHOISCHANOP + 361 RPL_KILLDONE 362 RPL_CLOSING + 363 RPL_CLOSEEND 373 RPL_INFOSTART + 384 RPL_MYPORTIS + + 213 RPL_STATSCLINE 214 RPL_STATSNLINE + 215 RPL_STATSILINE 216 RPL_STATSKLINE + 217 RPL_STATSQLINE 218 RPL_STATSYLINE + 240 RPL_STATSVLINE 241 RPL_STATSLLINE + 244 RPL_STATSHLINE 244 RPL_STATSSLINE + 246 RPL_STATSPING 247 RPL_STATSBLINE + 250 RPL_STATSDLINE + + 492 ERR_NOSERVICEHOST + +6. Current implementations + + The IRC software, version 2.10 is the only complete implementation of + the IRC protocol (client and server). Because of the small amount of + changes in the client protocol since the publication of RFC 1459 + [IRC], implementations that follow it are likely to be compliant with + this protocol or to require a small amount of changes to reach + compliance. + +7. Current problems + + There are a number of recognized problems with the IRC Client + Protocol, and more generally with the IRC Server Protocol. In order + to preserve backward compatibility with old clients, this protocol + has almost not evolved since the publication of RFC 1459 [IRC]. + +7.1 Nicknames + + The idea of the nickname on IRC is very convenient for users to use + when talking to each other outside of a channel, but there is only a + finite nickname space and being what they are, it's not uncommon for + several people to want to use the same nick. If a nickname is chosen + by two people using this protocol, either one will not succeed or + both will removed by use of a server KILL (See Section 3.7.1). + + + + + +Kalt Informational [Page 60] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +7.2 Limitation of wildcards + + There is no way to escape the escape character "\" (%x5C). While + this isn't usually a problem, it makes it impossible to form a mask + with a backslash character ("\") preceding a wildcard. + +7.3 Security considerations + + Security issues related to this protocol are discussed in the "IRC + Server Protocol" [IRC-SERVER] as they are mostly an issue for the + server side of the connection. + +8. Current support and availability + + Mailing lists for IRC related discussion: + General discussion: ircd-users@irc.org + Protocol development: ircd-dev@irc.org + + Software implementations: + ftp://ftp.irc.org/irc/server + ftp://ftp.funet.fi/pub/unix/irc + ftp://ftp.irc.org/irc/clients + + Newsgroup: alt.irc + +9. Acknowledgements + + Parts of this document were copied from the RFC 1459 [IRC] which + first formally documented the IRC Protocol. It has also benefited + from many rounds of review and comments. In particular, the + following people have made significant contributions to this + document: + + Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa + Ruokonen, Magnus Tjernstrom, Stefan Zehl. + + + + + + + + + + + + + + + + +Kalt Informational [Page 61] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +10. References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [HNAME] Braden, R., "Requirements for Internet Hosts -- + Application and Support", STD 3, RFC 1123, October 1989. + + [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol", + RFC 1459, May 1993. + + [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, + April 2000. + + [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC + 2811, April 2000. + + [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC + 2813, April 2000. + +11. Author's Address + + Christophe Kalt + 99 Teaneck Rd, Apt #117 + Ridgefield Park, NJ 07660 + USA + + EMail: kalt@stealth.net + + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 62] + +RFC 2812 Internet Relay Chat: Client Protocol April 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 63] + diff --git a/irc_mod/Docs/rfc2813.txt b/irc_mod/Docs/rfc2813.txt new file mode 100644 index 0000000..2da3de0 --- /dev/null +++ b/irc_mod/Docs/rfc2813.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group C. Kalt +Request for Comments: 2813 April 2000 +Updates: 1459 +Category: Informational + + + Internet Relay Chat: Server Protocol + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + While based on the client-server model, the IRC (Internet Relay Chat) + protocol allows servers to connect to each other effectively forming + a network. + + This document defines the protocol used by servers to talk to each + other. It was originally a superset of the client protocol but has + evolved differently. + + First formally documented in May 1993 as part of RFC 1459 [IRC], most + of the changes brought since then can be found in this document as + development was focused on making the protocol scale better. Better + scalability has allowed existing world-wide networks to keep growing + and reach sizes which defy the old specification. + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 1] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +Table of Contents + + 1. Introduction ............................................... 3 + 2. Global database ............................................ 3 + 2.1 Servers ................................................ 3 + 2.2 Clients ................................................ 4 + 2.2.1 Users ............................................. 4 + 2.2.2 Services .......................................... 4 + 2.3 Channels ............................................... 4 + 3. The IRC Server Specification ............................... 5 + 3.1 Overview ............................................... 5 + 3.2 Character codes ........................................ 5 + 3.3 Messages ............................................... 5 + 3.3.1 Message format in Augmented BNF ................... 6 + 3.4 Numeric replies ........................................ 7 + 4. Message Details ............................................ 7 + 4.1 Connection Registration ................................ 8 + 4.1.1 Password message .................................. 8 + 4.1.2 Server message .................................... 9 + 4.1.3 Nick .............................................. 10 + 4.1.4 Service message ................................... 11 + 4.1.5 Quit .............................................. 12 + 4.1.6 Server quit message ............................... 13 + 4.2 Channel operations ..................................... 14 + 4.2.1 Join message ...................................... 14 + 4.2.2 Njoin message ..................................... 15 + 4.2.3 Mode message ...................................... 16 + 5. Implementation details .................................... 16 + 5.1 Connection 'Liveness' .................................. 16 + 5.2 Accepting a client to server connection ................ 16 + 5.2.1 Users ............................................. 16 + 5.2.2 Services .......................................... 17 + 5.3 Establishing a server-server connection. ............... 17 + 5.3.1 Link options ...................................... 17 + 5.3.1.1 Compressed server to server links ............ 18 + 5.3.1.2 Anti abuse protections ....................... 18 + 5.3.2 State information exchange when connecting ........ 18 + 5.4 Terminating server-client connections .................. 19 + 5.5 Terminating server-server connections .................. 19 + 5.6 Tracking nickname changes .............................. 19 + 5.7 Tracking recently used nicknames ....................... 20 + 5.8 Flood control of clients ............................... 20 + 5.9 Non-blocking lookups ................................... 21 + 5.9.1 Hostname (DNS) lookups ............................ 21 + 5.9.2 Username (Ident) lookups .......................... 21 + 6. Current problems ........................................... 21 + 6.1 Scalability ............................................ 21 + 6.2 Labels ................................................. 22 + + + +Kalt Informational [Page 2] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + 6.2.1 Nicknames ......................................... 22 + 6.2.2 Channels .......................................... 22 + 6.2.3 Servers ........................................... 22 + 6.3 Algorithms ............................................. 22 + 7. Security Considerations .................................... 23 + 7.1 Authentication ......................................... 23 + 7.2 Integrity .............................................. 23 + 8. Current support and availability ........................... 24 + 9. Acknowledgements ........................................... 24 + 10. References ................................................ 24 + 11. Author's Address .......................................... 25 + 12. Full Copyright Statement ................................... 26 + +1. Introduction + + This document is intended for people working on implementing an IRC + server but will also be useful to anyone implementing an IRC service. + + Servers provide the three basic services required for realtime + conferencing defined by the "Internet Relay Chat: Architecture" + [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]), + message relaying (via the server protocol defined in this document) + and channel hosting and management (following specific rules [IRC- + CHAN]). + +2. Global database + + Although the IRC Protocol defines a fairly distributed model, each + server maintains a "global state database" about the whole IRC + network. This database is, in theory, identical on all servers. + +2.1 Servers + + Servers are uniquely identified by their name which has a maximum + length of sixty three (63) characters. See the protocol grammar + rules (section 3.3.1) for what may and may not be used in a server + name. + + Each server is typically known by all other servers, however it is + possible to define a "hostmask" to group servers together according + to their name. Inside the hostmasked area, all the servers have a + name which matches the hostmask, and any other server with a name + matching the hostmask SHALL NOT be connected to the IRC network + outside the hostmasked area. Servers which are outside the area have + no knowledge of the individual servers present inside the area, + instead they are presented with a virtual server which has the + hostmask for name. + + + + +Kalt Informational [Page 3] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +2.2 Clients + + For each client, all servers MUST have the following information: a + netwide unique identifier (whose format depends on the type of + client) and the server to which the client is connected. + +2.2.1 Users + + Each user is distinguished from other users by a unique nickname + having a maximum length of nine (9) characters. See the protocol + grammar rules (section 3.3.1) for what may and may not be used in a + nickname. In addition to the nickname, all servers MUST have the + following information about all users: the name of the host that the + user is running on, the username of the user on that host, and the + server to which the client is connected. + +2.2.2 Services + + Each service is distinguished from other services by a service name + composed of a nickname and a server name. The nickname has a maximum + length of nine (9) characters. See the protocol grammar rules + (section 3.3.1) for what may and may not be used in a nickname. The + server name used to compose the service name is the name of the + server to which the service is connected. In addition to this + service name all servers MUST know the service type. + + Services differ from users by the format of their identifier, but + more importantly services and users don't have the same type of + access to the server: services can request part or all of the global + state information that a server maintains, but have a more restricted + set of commands available to them (See "IRC Client Protocol" [IRC- + CLIENT] for details on which) and are not allowed to join channels. + Finally services are not usually subject to the "Flood control" + mechanism described in section 5.8. + +2.3 Channels + + Alike services, channels have a scope [IRC-CHAN] and are not + necessarily known to all servers. When a channel existence is known + to a server, the server MUST keep track of the channel members, as + well as the channel modes. + + + + + + + + + + +Kalt Informational [Page 4] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +3. The IRC Server Specification + +3.1 Overview + + The protocol as described herein is for use with server to server + connections. For client to server connections, see the IRC Client + Protocol specification. + + There are, however, more restrictions on client connections (which + are considered to be untrustworthy) than on server connections. + +3.2 Character codes + + No specific character set is specified. The protocol is based on a a + set of codes which are composed of eight (8) bits, making up an + octet. Each message may be composed of any number of these octets; + however, some octet values are used for control codes which act as + message delimiters. + + Regardless of being an 8-bit protocol, the delimiters and keywords + are such that protocol is mostly usable from US-ASCII terminal and a + telnet connection. + + Because of IRC's Scandinavian origin, the characters {}|^ are + considered to be the lower case equivalents of the characters []\~, + respectively. This is a critical issue when determining the + equivalence of two nicknames, or channel names. + +3.3 Messages + + Servers and clients send each other messages which may or may not + generate a reply. Most communication between servers do not generate + any reply, as servers mostly perform routing tasks for the clients. + + Each IRC message may consist of up to three main parts: the prefix + (OPTIONAL), the command, and the command parameters (maximum of + fifteen (15)). The prefix, command, and all parameters are separated + by one ASCII space character (0x20) each. + + The presence of a prefix is indicated with a single leading ASCII + colon character (':', 0x3b), which MUST be the first character of the + message itself. There MUST be NO gap (whitespace) between the colon + and the prefix. The prefix is used by servers to indicate the true + origin of the message. If the prefix is missing from the message, it + is assumed to have originated from the connection from which it was + received. Clients SHOULD not use a prefix when sending a message + from themselves; if they use one, the only valid prefix is the + registered nickname associated with the client. + + + +Kalt Informational [Page 5] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + When a server receives a message, it MUST identify its source using + the (eventually assumed) prefix. If the prefix cannot be found in + the server's internal database, it MUST be discarded, and if the + prefix indicates the message comes from an (unknown) server, the link + from which the message was received MUST be dropped. Dropping a link + in such circumstances is a little excessive but necessary to maintain + the integrity of the network and to prevent future problems. Another + common error condition is that the prefix found in the server's + internal database identifies a different source (typically a source + registered from a different link than from which the message + arrived). If the message was received from a server link and the + prefix identifies a client, a KILL message MUST be issued for the + client and sent to all servers. In other cases, the link from which + the message arrived SHOULD be dropped for clients, and MUST be + dropped for servers. In all cases, the message MUST be discarded. + + The command MUST either be a valid IRC command or a three (3) digit + number represented in ASCII text. + + IRC messages are always lines of characters terminated with a CR-LF + (Carriage Return - Line Feed) pair, and these messages SHALL NOT + exceed 512 characters in length, counting all characters including + the trailing CR-LF. Thus, there are 510 characters maximum allowed + for the command and its parameters. There is no provision for + continuation message lines. See section 5 for more details about + current implementations. + +3.3.1 Message format in Augmented BNF + + The protocol messages must be extracted from the contiguous stream of + octets. The current solution is to designate two characters, CR and + LF, as message separators. Empty messages are silently ignored, + which permits use of the sequence CR-LF between messages without + extra problems. + + The extracted message is parsed into the components <prefix>, + <command> and list of parameters (<params>). + + The Augmented BNF representation for this is found in "IRC Client + Protocol" [IRC-CLIENT]. + + The extended prefix (["!" user "@" host ]) MUST NOT be used in server + to server communications and is only intended for server to client + messages in order to provide clients with more useful information + about who a message is from without the need for additional queries. + + + + + + +Kalt Informational [Page 6] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +3.4 Numeric replies + + Most of the messages sent to the server generate a reply of some + sort. The most common reply is the numeric reply, used for both + errors and normal replies. The numeric reply MUST be sent as one + message consisting of the sender prefix, the three digit numeric, and + the target of the reply. A numeric reply is not allowed to originate + from a client; any such messages received by a server are silently + dropped. In all other respects, a numeric reply is just like a normal + message, except that the keyword is made up of 3 numeric digits + rather than a string of letters. A list of different replies is + supplied in "IRC Client Protocol" [IRC-CLIENT]. + +4. Message Details + + All the messages recognized by the IRC server and client are + described in the IRC Client Protocol specification. + + Where the reply ERR_NOSUCHSERVER is returned, it means that the + target of the message could not be found. The server MUST NOT send + any other replies after this error for that command. + + The server to which a client is connected is required to parse the + complete message, returning any appropriate errors. If the server + encounters a fatal error while parsing a message, an error MUST be + sent back to the client and the parsing terminated. A fatal error + may follow from incorrect command, a destination which is otherwise + unknown to the server (server, client or channel names fit this + category), not enough parameters or incorrect privileges. + + If a full set of parameters is presented, then each MUST be checked + for validity and appropriate responses sent back to the client. In + the case of messages which use parameter lists using the comma as an + item separator, a reply MUST be sent for each item. + + In the examples below, some messages appear using the full format: + + :Name COMMAND parameter list + + Such examples represent a message from "Name" in transit between + servers, where it is essential to include the name of the original + sender of the message so remote servers may send back a reply along + the correct path. + + The message details for client to server communication are described + in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the + following pages apply to some of these messages, they are additions + to the message specifications which are only relevant to server to + + + +Kalt Informational [Page 7] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + server communication, or to the server implementation. The messages + which are introduced here are only used for server to server + communication. + +4.1 Connection Registration + + The commands described here are used to register a connection with + another IRC server. + +4.1.1 Password message + + Command: PASS + Parameters: <password> <version> <flags> [<options>] + + The PASS command is used to set a 'connection password'. The + password MUST be set before any attempt to register the connection is + made. Currently this means that servers MUST send a PASS command + before any SERVER command. Only one (1) PASS command SHALL be + accepted from a connection. + + The last three (3) parameters MUST be ignored if received from a + client (e.g. a user or a service). They are only relevant when + received from a server. + + The <version> parameter is a string of at least four (4) characters, + and up to fourteen (14) characters. The first four (4) characters + MUST be digits and indicate the protocol version known by the server + issuing the message. The protocol described by this document is + version 2.10 which is encoded as "0210". The remaining OPTIONAL + characters are implementation dependent and should describe the + software version number. + + The <flags> parameter is a string of up to one hundred (100) + characters. It is composed of two substrings separated by the + character "|" (%x7C). If present, the first substring MUST be the + name of the implementation. The reference implementation (See + Section 8, "Current support and availability") uses the string "IRC". + If a different implementation is written, which needs an identifier, + then that identifier should be registered through publication of an + RFC. The second substring is implementation dependent. Both + substrings are OPTIONAL, but the character "|" is REQUIRED. The + character "|" MUST NOT appear in either substring. + + Finally, the last parameter, <options>, is used for link options. + The only options defined by the protocol are link compression (using + the character "Z"), and an abuse protection flag (using the character + + + + + +Kalt Informational [Page 8] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + "P"). See sections 5.3.1.1 (Compressed server to server links) and + 5.3.1.2 (Anti abuse protections) respectively for more information on + these options. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + PASS moresecretpassword 0210010000 IRC|aBgH$ Z + +4.1.2 Server message + + Command: SERVER + Parameters: <servername> <hopcount> <token> <info> + + The SERVER command is used to register a new server. A new connection + introduces itself as a server to its peer. This message is also used + to pass server data over whole net. When a new server is connected + to net, information about it MUST be broadcasted to the whole + network. + + The <info> parameter may contain space characters. + + <hopcount> is used to give all servers some internal information on + how far away each server is. Local peers have a value of 0, and each + passed server increments the value. With a full server list, it + would be possible to construct a map of the entire server tree, but + hostmasks prevent this from being done. + + The <token> parameter is an unsigned number used by servers as an + identifier. This identifier is subsequently used to reference a + server in the NICK and SERVICE messages sent between servers. Server + tokens only have a meaning for the point-to-point peering they are + used and MUST be unique for that connection. They are not global. + + The SERVER message MUST only be accepted from either (a) a connection + which is yet to be registered and is attempting to register as a + server, or (b) an existing connection to another server, in which + case the SERVER message is introducing a new server behind that + server. + + Most errors that occur with the receipt of a SERVER command result in + the connection being terminated by the destination host (target + SERVER). Because of the severity of such event, error replies are + usually sent using the "ERROR" command rather than a numeric. + + + + +Kalt Informational [Page 9] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + If a SERVER message is parsed and it attempts to introduce a server + which is already known to the receiving server, the connection, from + which that message arrived, MUST be closed (following the correct + procedures), since a duplicate route to a server has been formed and + the acyclic nature of the IRC tree breaks. In some conditions, the + connection from which the already known server has registered MAY be + closed instead. It should be noted that this kind of error can also + be the result of a second running server, problem which cannot be + fixed within the protocol and typically requires human intervention. + This type of problem is particularly insidious, as it can quite + easily result in part of the IRC network to be isolated, with one of + the two servers connected to each partition therefore making it + impossible for the two parts to unite. + + Numeric Replies: + + ERR_ALREADYREGISTRED + + Example: + + SERVER test.oulu.fi 1 1 :Experimental server ; New server + test.oulu.fi introducing itself and + attempting to register. + + :tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server + tolsun.oulu.fi is our uplink for + csd.bu.edu which is 5 hops away. The + token "34" will be used by + tolsun.oulu.fi when introducing new + users or services connected to + csd.bu.edu. + +4.1.3 Nick + + Command: NICK + Parameters: <nickname> <hopcount> <username> <host> <servertoken> + <umode> <realname> + + This form of the NICK message MUST NOT be allowed from user + connections. However, it MUST be used instead of the NICK/USER pair + to notify other servers of new users joining the IRC network. + + This message is really the combination of three distinct messages: + NICK, USER and MODE [IRC-CLIENT]. + + The <hopcount> parameter is used by servers to indicate how far away + a user is from its home server. A local connection has a hopcount of + 0. The hopcount value is incremented by each passed server. + + + +Kalt Informational [Page 10] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + The <servertoken> parameter replaces the <servername> parameter of + the USER (See section 4.1.2 for more information on server tokens). + + Examples: + + NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New + user with nickname "syrk", username + "kalt", connected from host + "millennium.stealth.net" to server + "34" ("csd.bu.edu" according to the + previous example). + + :krys NICK syrk ; The other form of the NICK message, + as defined in "IRC Client Protocol" + [IRC-CLIENT] and used between + servers: krys changed his nickname to + syrk + +4.1.4 Service message + + Command: SERVICE + Parameters: <servicename> <servertoken> <distribution> <type> + <hopcount> <info> + + The SERVICE command is used to introduce a new service. This form of + the SERVICE message SHOULD NOT be allowed from client (unregistered, + or registered) connections. However, it MUST be used between servers + to notify other servers of new services joining the IRC network. + + The <servertoken> is used to identify the server to which the service + is connected. (See section 4.1.2 for more information on server + tokens). + + The <hopcount> parameter is used by servers to indicate how far away + a service is from its home server. A local connection has a hopcount + of 0. The hopcount value is incremented by each passed server. + + The <distribution> parameter is used to specify the visibility of a + service. The service may only be known to servers which have a name + matching the distribution. For a matching server to have knowledge + of the service, the network path between that server and the server + to which the service is connected MUST be composed of servers whose + names all match the mask. Plain "*" is used when no restriction is + wished. + + The <type> parameter is currently reserved for future usage. + + + + + +Kalt Informational [Page 11] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + Numeric Replies: + + ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS + ERR_ERRONEUSNICKNAME + RPL_YOURESERVICE RPL_YOURHOST + RPL_MYINFO + + Example: + +SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on + server "9" is being announced to + another server. This service will + only be available on servers whose + name matches "*.fr". + +4.1.5 Quit + + Command: QUIT + Parameters: [<Quit Message>] + + A client session ends with a quit message. The server MUST close the + connection to a client which sends a QUIT message. If a "Quit + Message" is given, this will be sent instead of the default message, + the nickname or service name. + + When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is + composed of the names of two servers involved, separated by a space. + The first name is that of the server which is still connected and the + second name is either that of the server which has become + disconnected or that of the server to which the leaving client was + connected: + + <Quit Message> = ":" servername SPACE servername + + Because the "Quit Message" has a special meaning for "netsplits", + servers SHOULD NOT allow a client to use a <Quit Message> in the + format described above. + + If, for some other reason, a client connection is closed without the + client issuing a QUIT command (e.g. client dies and EOF occurs on + socket), the server is REQUIRED to fill in the quit message with some + sort of message reflecting the nature of the event which caused it to + happen. Typically, this is done by reporting a system specific + error. + + Numeric Replies: + + None. + + + +Kalt Informational [Page 12] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + Examples: + + :WiZ QUIT :Gone to have lunch ; Preferred message format. + +4.1.6 Server quit message + + Command: SQUIT + Parameters: <server> <comment> + + The SQUIT message has two distinct uses. + + The first one (described in "Internet Relay Chat: Client Protocol" + [IRC-CLIENT]) allows operators to break a local or remote server + link. This form of the message is also eventually used by servers to + break a remote server link. + + The second use of this message is needed to inform other servers when + a "network split" (also known as "netsplit") occurs, in other words + to inform other servers about quitting or dead servers. If a server + wishes to break the connection to another server it MUST send a SQUIT + message to the other server, using the name of the other server as + the server parameter, which then closes its connection to the + quitting server. + + The <comment> is filled in by servers which SHOULD place an error or + similar message here. + + Both of the servers which are on either side of the connection being + closed are REQUIRED to send out a SQUIT message (to all its other + server connections) for all other servers which are considered to be + behind that link. + + Similarly, a QUIT message MAY be sent to the other still connected + servers on behalf of all clients behind that quitting link. In + addition to this, all channel members of a channel which lost a + member due to the "split" MUST be sent a QUIT message. Messages to + channel members are generated by each client's local server. + + If a server connection is terminated prematurely (e.g., the server on + the other end of the link died), the server which detects this + disconnection is REQUIRED to inform the rest of the network that the + connection has closed and fill in the comment field with something + appropriate. + + When a client is removed as the result of a SQUIT message, the server + SHOULD add the nickname to the list of temporarily unavailable + nicknames in an attempt to prevent future nickname collisions. See + + + + +Kalt Informational [Page 13] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + section 5.7 (Tracking recently used nicknames) for more information + on this procedure. + + Numeric replies: + + ERR_NOPRIVILEGES ERR_NOSUCHSERVER + ERR_NEEDMOREPARAMS + + Example: + + SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi + has been terminated because of "Bad + Link". + + :Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message + from Trillian to disconnect + "cm22.eng.umd.edu" from the net + because "Server out of control". + +4.2 Channel operations + + This group of messages is concerned with manipulating channels, their + properties (channel modes), and their contents (typically users). In + implementing these, a number of race conditions are inevitable when + users at opposing ends of a network send commands which will + ultimately clash. It is also REQUIRED that servers keep a nickname + history to ensure that wherever a <nick> parameter is given, the + server check its history in case it has recently been changed. + +4.2.1 Join message + + Command: JOIN + Parameters: <channel>[ %x7 <modes> ] + *( "," <channel>[ %x7 <modes> ] ) + + The JOIN command is used by client to start listening a specific + channel. Whether or not a client is allowed to join a channel is + checked only by the local server the client is connected to; all + other servers automatically add the user to the channel when the + command is received from other servers. + + Optionally, the user status (channel modes 'O', 'o', and 'v') on the + channel may be appended to the channel name using a control G (^G or + ASCII 7) as separator. Such data MUST be ignored if the message + wasn't received from a server. This format MUST NOT be sent to + clients, it can only be used between servers and SHOULD be avoided. + + + + + +Kalt Informational [Page 14] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + The JOIN command MUST be broadcast to all servers so that each server + knows where to find the users who are on the channel. This allows + optimal delivery of PRIVMSG and NOTICE messages to the channel. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN + ERR_INVITEONLYCHAN ERR_BADCHANNELKEY + ERR_CHANNELISFULL ERR_BADCHANMASK + ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS + ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE + RPL_TOPIC + + Examples: + + :WiZ JOIN #Twilight_zone ; JOIN message from WiZ + +4.2.2 Njoin message + + Command: NJOIN + Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname> + *( "," [ "@@" / "@" ] [ "+" ] <nickname> ) + + The NJOIN message is used between servers only. If such a message is + received from a client, it MUST be ignored. It is used when two + servers connect to each other to exchange the list of channel members + for each channel. + + Even though the same function can be performed by using a succession + of JOIN, this message SHOULD be used instead as it is more efficient. + The prefix "@@" indicates that the user is the "channel creator", the + character "@" alone indicates a "channel operator", and the character + '+' indicates that the user has the voice privilege. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_ALREADYREGISTRED + + Examples: + + :ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN + message from ircd.stealth.net + announcing users joining the + #Twilight_zone channel: WiZ with + channel operator status, syrk with + voice privilege and avalon with no + privilege. + + + +Kalt Informational [Page 15] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +4.2.3 Mode message + + The MODE message is a dual-purpose command in IRC. It allows both + usernames and channels to have their mode changed. + + When parsing MODE messages, it is RECOMMENDED that the entire message + be parsed first, and then the changes which resulted passed on. + + It is REQUIRED that servers are able to change channel modes so that + "channel creator" and "channel operators" may be created. + +5. Implementation details + + A the time of writing, the only current implementation of this + protocol is the IRC server, version 2.10. Earlier versions may + implement some or all of the commands described by this document with + NOTICE messages replacing many of the numeric replies. Unfortunately, + due to backward compatibility requirements, the implementation of + some parts of this document varies with what is laid out. One + notable difference is: + + * recognition that any LF or CR anywhere in a message marks + the end of that message (instead of requiring CR-LF); + + The rest of this section deals with issues that are mostly of + importance to those who wish to implement a server but some parts + also apply directly to clients as well. + +5.1 Connection 'Liveness' + + To detect when a connection has died or become unresponsive, the + server MUST poll each of its connections. The PING command (See "IRC + Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a + response from its peer in a given amount of time. + + If a connection doesn't respond in time, its connection is closed + using the appropriate procedures. + +5.2 Accepting a client to server connection + +5.2.1 Users + + When a server successfully registers a new user connection, it is + REQUIRED to send to the user unambiguous messages stating: the user + identifiers upon which it was registered (RPL_WELCOME), the server + name and version (RPL_YOURHOST), the server birth information + (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it + MAY send any introductory messages which may be deemed appropriate. + + + +Kalt Informational [Page 16] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + In particular the server SHALL send the current user/service/server + count (as per the LUSER reply) and finally the MOTD (if any, as per + the MOTD reply). + + After dealing with registration, the server MUST then send out to + other servers the new user's nickname (NICK message), other + information as supplied by itself (USER message) and as the server + could discover (from DNS servers). The server MUST NOT send this + information out with a pair of NICK and USER messages as defined in + "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage + of the extended NICK message defined in section 4.1.3. + +5.2.2 Services + + Upon successfully registering a new service connection, the server is + subject to the same kind of REQUIREMENTS as for a user. Services + being somewhat different, only the following replies are sent: + RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO. + + After dealing with this, the server MUST then send out to other + servers (SERVICE message) the new service's nickname and other + information as supplied by the service (SERVICE message) and as the + server could discover (from DNS servers). + +5.3 Establishing a server-server connection. + + The process of establishing a server-to-server connection is fraught + with danger since there are many possible areas where problems can + occur - the least of which are race conditions. + + After a server has received a connection following by a PASS/SERVER + pair which were recognized as being valid, the server SHOULD then + reply with its own PASS/SERVER information for that connection as + well as all of the other state information it knows about as + described below. + + When the initiating server receives a PASS/SERVER pair, it too then + checks that the server responding is authenticated properly before + accepting the connection to be that server. + +5.3.1 Link options + + Server links are based on a common protocol (defined by this + document) but a particular link MAY set specific options using the + PASS message (See Section 4.1.1). + + + + + + +Kalt Informational [Page 17] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +5.3.1.1 Compressed server to server links + + If a server wishes to establish a compressed link with its peer, it + MUST set the 'Z' flag in the options parameter to the PASS message. + If both servers request compression and both servers are able to + initialize the two compressed streams, then the remainder of the + communication is to be compressed. If any server fails to initialize + the stream, it will send an uncompressed ERROR message to its peer + and close the connection. + + The data format used for the compression is described by RFC 1950 + [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP]. + +5.3.1.2 Anti abuse protections + + Most servers implement various kinds of protections against possible + abusive behaviours from non trusted parties (typically users). On + some networks, such protections are indispensable, on others they are + superfluous. To require that all servers implement and enable such + features on a particular network, the 'P' flag is used when two + servers connect. If this flag is present, it means that the server + protections are enabled, and that the server REQUIRES all its server + links to enable them as well. + + Commonly found protections are described in sections 5.7 (Tracking + recently used nicknames) and 5.8 (Flood control of clients). + +5.3.2 State information exchange when connecting + + The order of state information being exchanged between servers is + essential. The REQUIRED order is as follows: + + * all known servers; + + * all known client information; + + * all known channel information. + + Information regarding servers is sent via extra SERVER messages, + client information with NICK and SERVICE messages and channels with + NJOIN/MODE messages. + + NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC + command overwrites any old topic information, so at best, the two + sides of the connection would exchange topics. + + + + + + +Kalt Informational [Page 18] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + By passing the state information about servers first, any collisions + with servers that already exist occur before nickname collisions + caused by a second server introducing a particular nickname. Due to + the IRC network only being able to exist as an acyclic graph, it may + be possible that the network has already reconnected in another + location. In this event, the place where the server collision occurs + indicates where the net needs to split. + +5.4 Terminating server-client connections + + When a client connection unexpectedly closes, a QUIT message is + generated on behalf of the client by the server to which the client + was connected. No other message is to be generated or used. + +5.5 Terminating server-server connections + + If a server-server connection is closed, either via a SQUIT command + or "natural" causes, the rest of the connected IRC network MUST have + its information updated by the server which detected the closure. + The terminating server then sends a list of SQUITs (one for each + server behind that connection). (See Section 4.1.6 (SQUIT)). + +5.6 Tracking nickname changes + + All IRC servers are REQUIRED to keep a history of recent nickname + changes. This is important to allow the server to have a chance of + keeping in touch of things when nick-change race conditions occur + with commands manipulating them. Messages which MUST trace nick + changes are: + + * KILL (the nick being disconnected) + + * MODE (+/- o,v on channels) + + * KICK (the nick being removed from channel) + + No other commands need to check nick changes. + + In the above cases, the server is required to first check for the + existence of the nickname, then check its history to see who that + nick now belongs to (if anyone!). This reduces the chances of race + conditions but they can still occur with the server ending up + affecting the wrong client. When performing a change trace for an + above command it is RECOMMENDED that a time range be given and + entries which are too old ignored. + + + + + + +Kalt Informational [Page 19] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + For a reasonable history, a server SHOULD be able to keep previous + nickname for every client it knows about if they all decided to + change. This size is limited by other factors (such as memory, etc). + +5.7 Tracking recently used nicknames + + This mechanism is commonly known as "Nickname Delay", it has been + proven to significantly reduce the number of nickname collisions + resulting from "network splits"/reconnections as well as abuse. + + In addition of keeping track of nickname changes, servers SHOULD keep + track of nicknames which were recently used and were released as the + result of a "network split" or a KILL message. These nicknames are + then unavailable to the server local clients and cannot be re-used + (even though they are not currently in use) for a certain period of + time. + + The duration for which a nickname remains unavailable SHOULD be set + considering many factors among which are the size (user wise) of the + IRC network, and the usual duration of "network splits". It SHOULD + be uniform on all servers for a given IRC network. + +5.8 Flood control of clients + + With a large network of interconnected IRC servers, it is quite easy + for any single client attached to the network to supply a continuous + stream of messages that result in not only flooding the network, but + also degrading the level of service provided to others. Rather than + require every 'victim' to provide their own protection, flood + protection was written into the server and is applied to all clients + except services. The current algorithm is as follows: + + * check to see if client's `message timer' is less than current time + (set to be equal if it is); + + * read any data present from the client; + + * while the timer is less than ten (10) seconds ahead of the current + time, parse any present messages and penalize the client by two (2) + seconds for each message; + + * additional penalties MAY be used for specific commands which + generate a lot of traffic across the network. + + This in essence means that the client may send one (1) message every + two (2) seconds without being adversely affected. Services MAY also + be subject to this mechanism. + + + + +Kalt Informational [Page 20] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +5.9 Non-blocking lookups + + In a real-time environment, it is essential that a server process + does as little waiting as possible so that all the clients are + serviced fairly. Obviously this requires non-blocking IO on all + network read/write operations. For normal server connections, this + was not difficult, but there are other support operations that may + cause the server to block (such as disk reads). Where possible, such + activity SHOULD be performed with a short timeout. + +5.9.1 Hostname (DNS) lookups + + Using the standard resolver libraries from Berkeley and others has + meant large delays in some cases where replies have timed out. To + avoid this, a separate set of DNS routines were written for the + current implementation. Routines were setup for non-blocking IO + operations with local cache, and then polled from within the main + server IO loop. + +5.9.2 Username (Ident) lookups + + Although there are numerous ident libraries (implementing the + "Identification Protocol" [IDENT]) for use and inclusion into other + programs, these caused problems since they operated in a synchronous + manner and resulted in frequent delays. Again the solution was to + write a set of routines which would cooperate with the rest of the + server and work using non-blocking IO. + +6. Current problems + + There are a number of recognized problems with this protocol, all of + which are hoped to be solved sometime in the near future during its + rewrite. Currently, work is underway to find working solutions to + these problems. + +6.1 Scalability + + It is widely recognized that this protocol does not scale + sufficiently well when used in a large arena. The main problem comes + from the requirement that all servers know about all other servers + and clients and that information regarding them be updated as soon as + it changes. It is also desirable to keep the number of servers low + so that the path length between any two points is kept minimal and + the spanning tree as strongly branched as possible. + + + + + + + +Kalt Informational [Page 21] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +6.2 Labels + + The current IRC protocol has 4 types of labels: the nickname, the + channel name, the server name and the service name. Each of the four + types has its own domain and no duplicates are allowed inside that + domain. Currently, it is possible for users to pick the label for + any of the first three, resulting in collisions. It is widely + recognized that this needs reworking, with a plan for unique names + for nicks that don't collide being desirable as well as a solution + allowing a cyclic tree. + +6.2.1 Nicknames + + The idea of the nickname on IRC is very convenient for users to use + when talking to each other outside of a channel, but there is only a + finite nickname space and being what they are, it's not uncommon for + several people to want to use the same nick. If a nickname is chosen + by two people using this protocol, either one will not succeed or + both will be removed by use of KILL (See Section 3.7.1 of "IRC Client + Protocol" [IRC-CLIENT]). + +6.2.2 Channels + + The current channel layout requires that all servers know about all + channels, their inhabitants and properties. Besides not scaling + well, the issue of privacy is also a concern. A collision of + channels is treated as an inclusive event (people from both nets on + channel with common name are considered to be members of it) rather + than an exclusive one such as used to solve nickname collisions. + + This protocol defines "Safe Channels" which are very unlikely to be + the subject of a channel collision. Other channel types are kept for + backward compatibility. + +6.2.3 Servers + + Although the number of servers is usually small relative to the + number of users and channels, they too are currently REQUIRED to be + known globally, either each one separately or hidden behind a mask. + +6.3 Algorithms + + In some places within the server code, it has not been possible to + avoid N^2 algorithms such as checking the channel list of a set of + clients. + + + + + + +Kalt Informational [Page 22] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + In current server versions, there are only few database consistency + checks, most of the time each server assumes that a neighbouring + server is correct. This opens the door to large problems if a + connecting server is buggy or otherwise tries to introduce + contradictions to the existing net. + + Currently, because of the lack of unique internal and global labels, + there are a multitude of race conditions that exist. These race + conditions generally arise from the problem of it taking time for + messages to traverse and effect the IRC network. Even by changing to + unique labels, there are problems with channel-related commands being + disrupted. + +7. Security Considerations + +7.1 Authentication + + Servers only have two means of authenticating incoming connections: + plain text password, and DNS lookups. While these methods are weak + and widely recognized as unsafe, their combination has proven to be + sufficient in the past: + + * public networks typically allow user connections with only few + restrictions, without requiring accurate authentication. + + * private networks which operate in a controlled environment often + use home-grown authentication mechanisms not available on the + internet: reliable ident servers [IDENT], or other proprietary + mechanisms. + + The same comments apply to the authentication of IRC Operators. + + It should also be noted that while there has been no real demand over + the years for stronger authentication, and no real effort to provide + better means to safely authenticate users, the current protocol + offers enough to be able to easily plug-in external authentication + methods based on the information that a client can submit to the + server upon connection: nickname, username, password. + +7.2 Integrity + + Since the PASS and OPER messages of the IRC protocol are sent in + clear text, a stream layer encryption mechanism (like "The TLS + Protocol" [TLS]) could be used to protect these transactions. + + + + + + + +Kalt Informational [Page 23] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +8. Current support and availability + + Mailing lists for IRC related discussion: + General discussion: ircd-users@irc.org + Protocol development: ircd-dev@irc.org + + Software implementations: + ftp://ftp.irc.org/irc/server + ftp://ftp.funet.fi/pub/unix/irc + ftp://coombs.anu.edu.au/pub/irc + + Newsgroup: alt.irc + +9. Acknowledgements + + Parts of this document were copied from the RFC 1459 [IRC] which + first formally documented the IRC Protocol. It has also benefited + from many rounds of review and comments. In particular, the + following people have made significant contributions to this + document: + + Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa + Ruokonen, Magnus Tjernstrom, Stefan Zehl. + +10. References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat + Protocol", RFC 1459, May 1993. + + [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, + April 2000. + + [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC + 2812, April 2000. + + + [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC + 2811, April 2000. + + [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data + Format Specification version 3.3", RFC 1950, May 1996. + + + + +Kalt Informational [Page 24] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + + [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format + Specification version 1.3", RFC 1951, May 1996. + + [GZIP] Deutsch, P., "GZIP file format specification version + 4.3", RFC 1952, May 1996. + + [IDENT] St. Johns, M., "The Identification Protocol", RFC 1413, + February 1993. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, + January 1999. + +11. Author's Address + + Christophe Kalt + 99 Teaneck Rd, Apt #117 + Ridgefield Park, NJ 07660 + USA + + EMail: kalt@stealth.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 25] + +RFC 2813 Internet Relay Chat: Server Protocol April 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kalt Informational [Page 26] + |