List of Internet Relay Chat commands

Last updated

This is a list of all Internet Relay Chat commands from RFC 1459, RFC 2812, and extensions added to major IRC daemons. Most IRC clients require commands to be preceded by a slash ("/"). Some commands are actually sent to IRC bots; these are treated by the IRC protocol as ordinary messages, not as /-commands.

Contents

Conventions used here: Angle brackets ("<" and ">") are used here to indicate a placeholder for some value, and are not a literal part of a command. Square brackets ("[" and "]") are used to indicate that a value is optional.

User commands

ADMIN

Syntax:

ADMIN [<target>]

Instructs the server to return information about the administrators of the server specified by <target>, where <target> is either a server or a user. If <target> is omitted, the server should return information about the administrators of the current server. [1]

AWAY

Syntax:

AWAY [<message>]

Provides the server with a message to automatically send in reply to a PRIVMSG directed at the user, but not to a channel they are on. [2] If <message> is omitted, the away status is removed. Defined in RFC 1459.

CNOTICE

Syntax:

CNOTICE <nickname> <channel> :<message>

Sends a channel NOTICE message to <nickname> on <channel> that bypasses flood protection limits. The target nickname must be in the same channel as the client issuing the command, and the client must be a channel operator.

Normally an IRC server will limit the number of different targets a client can send messages to within a certain time frame to prevent spammers or bots from mass-messaging users on the network, however this command can be used by channel operators to bypass that limit in their channel. For example, it is often used by help operators that may be communicating with a large number of users in a help channel at one time.

This command is not formally defined in an RFC, but is in use by some IRC networks. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the CNOTICE keyword

CPRIVMSG

Syntax:

CPRIVMSG <nickname> <channel> :<message>

Sends a private message to <nickname> on <channel> that bypasses flood protection limits. The target nickname must be in the same channel as the client issuing the command, and the client must be a channel operator.

Normally an IRC server will limit the number of different targets a client can send messages to within a certain time frame to prevent spammers or bots from mass-messaging users on the network, however this command can be used by channel operators to bypass that limit in their channel. For example, it is often used by help operators that may be communicating with a large number of users in a help channel at one time.

This command is not formally defined in an RFC, but is in use by some IRC networks. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the CPRIVMSG keyword

CONNECT

Syntax:

CONNECT <target server> [<port> [<remote server>]] (RFC 1459)
CONNECT <target server> <port> [<remote server>] (RFC 2812)

Instructs the server <remote server> (or the current server, if <remote server> is omitted) to connect to <target server> on port <port>. [3] [4] This command should only be available to IRC operators. Defined in RFC 1459; the <port> parameter became mandatory in RFC 2812.

DIE

Syntax:

DIE

Instructs the server to shut down. [5] This command may only be issued by IRC server operators. Defined in RFC 2812.

ENCAP

Syntax:

:<source> ENCAP <destination> <subcommand> <parameters>

This command is for use by servers to encapsulate commands so that they will propagate across hub servers not yet updated to support them, and indicates the subcommand and its parameters should be passed unaltered to the destination, where it will be unencapsulated and parsed. This facilitates implementation of new features without a need to restart all servers before they are usable across the network. [6]

ERROR

Syntax:

ERROR <error message>

This command is for use by servers to report errors to other servers. It is also used before terminating client connections. [7] Defined in RFC 1459.

HELP

Syntax:

HELP

Requests the server to display the help file. This command is not formally defined in an RFC, but is in use by most[ which? ] major IRC daemons.

INFO

Syntax:

INFO [<target>]

Returns information about the <target> server, or the current server if <target> is omitted. [8] Information returned includes the server's version, when it was compiled, the patch level, when it was started, and any other information which may be considered to be relevant. Defined in RFC 1459.

INVITE

Syntax:

INVITE <nickname> <channel>

Invites <nickname> to the channel <channel>. [9] <channel> does not have to exist, but if it does, only members of the channel are allowed to invite other clients. If the channel mode i is set, only channel operators may invite other clients. Defined in RFC 1459.

ISON

Syntax:

ISON <nicknames>

Queries the server to see if the clients in the space-separated list <nicknames> are currently on the network. [10] The server returns only the nicknames that are on the network in a space-separated list. If none of the clients are on the network the server returns an empty list. Defined in RFC 1459.

JOIN

Syntax:

JOIN <channels> [<keys>]

Makes the client join the channels in the comma-separated list <channels>, specifying the passwords, if needed, in the comma-separated list <keys>. [11] If the channel(s) do not exist then they will be created. Defined in RFC 1459.

KICK

Syntax:

KICK <channel> <client> :[<message>]

Forcibly removes <client> from <channel>. [12] This command may only be issued by channel operators. Defined in RFC 1459.

KILL

Syntax:

KILL <client> <comment>

Forcibly removes <client> from the network. [13] This command may only be issued by IRC operators. Defined in RFC 1459.

KNOCK

Syntax:

KNOCK <channel> [<message>]

Sends a NOTICE to an invitation-only <channel> with an optional <message>, requesting an invite. This command is not formally defined by an RFC, but is supported by most[ which? ] major IRC daemons. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the KNOCK keyword.

Syntax:

LINKS [<remote server> [<server mask>]]

Lists all server links matching <server mask>, if given, on <remote server>, or the current server if omitted. [14] Defined in RFC 1459.

LIST

Syntax:

LIST [<channels> [<server>]]

Lists all channels on the server. [15] If the comma-separated list <channels> is given, it will return the channel topics. If <server> is given, the command will be forwarded to <server> for evaluation. Defined in RFC 1459.

LUSERS

Syntax:

LUSERS [<mask> [<server>]]

Returns statistics about the size of the network. [16] If called with no arguments, the statistics will reflect the entire network. If <mask> is given, it will return only statistics reflecting the masked subset of the network. If <target> is given, the command will be forwarded to <server> for evaluation. Defined in RFC 2812.

MODE

Syntax:

MODE <nickname> <flags> (user)
MODE <channel> <flags> [<args>]

The MODE command is dual-purpose. It can be used to set both user and channel modes. [17] Defined in RFC 1459.

MOTD

Syntax:

MOTD [<server>]

Returns the message of the day on <server> or the current server if it is omitted. [18] Defined in RFC 2812.

NAMES

Syntax:

NAMES [<channels>] (RFC 1459)
NAMES [<channels> [<server>]] (RFC 2812)

Returns a list of who is on the comma-separated list of <channels>, by channel name. [19] If <channels> is omitted, all users are shown, grouped by channel name with all users who are not on a channel being shown as part of channel "*". If <server> is specified, the command is sent to <server> for evaluation. [20] Defined in RFC 1459; the optional <server> parameter was added in RFC 2812.

The response contains all nicknames in the channel prefixed with the highest channel status prefix of that user, for example like this (with @ being the highest status prefix)

:irc.server.net 353 Phyre = #SomeChannel :@WiZ

If a client wants to receive all the channel status prefixes of a user and not only their current highest one, the IRCv3 multi-prefix extension can be enabled (@ is the channel operator prefix, and + the lower voice status prefix): [21]

:irc.server.net 353 Phyre = #SomeChannel :@+WiZ

See also NAMESX below for an alternate, older approach to achieve the same effect. However, by today most clients and servers support the new IRCv3 standard. [22]

NICK

Syntax:

NICK <nickname> [<hopcount>] (RFC 1459)
NICK <nickname> (RFC 2812)

Allows a client to change their IRC nickname. Hopcount is for use between servers to specify how far away a nickname is from its home server. [23] [24] Defined in RFC 1459; the optional <hopcount> parameter was removed in RFC 2812.

NOTICE

Syntax:

NOTICE <msgtarget> <message>

This command works similarly to PRIVMSG, except automatic replies must never be sent in reply to NOTICE messages. [25] Defined in RFC 1459.

OPER

Syntax:

OPER <username> <password>

Authenticates a user as an IRC operator on that server/network. [26] Defined in RFC 1459.

PART

Syntax:

PART <channels> [<message>]

Causes a user to leave the channels in the comma-separated list <channels>. [27] Defined in RFC 1459.

PASS

Syntax:

PASS <password>

Sets a connection password. [28] This command must be sent before the NICK/USER registration combination. Defined in RFC 1459.

PING

Syntax:

PING <server1> [<server2>]

Tests the presence of a connection. [29] A PING message results in a PONG reply. If <server2> is specified, the message gets passed on to it. Defined in RFC 1459.

PONG

Syntax:

PONG <server1> [<server2>]

This command is a reply to the PING command and works in much the same way. [30] Defined in RFC 1459.

PRIVMSG

Syntax:

PRIVMSG <msgtarget> :<message>

Sends <message> to <msgtarget>, which is usually a user or channel. [31] Defined in RFC 1459.

QUIT

Syntax:

QUIT [<message>]

Disconnects the user from the server. [32] Defined in RFC 1459.

REHASH

Syntax:

REHASH

Causes the server to re-read and re-process its configuration file(s). [33] This command can only be sent by IRC operators. Defined in RFC 1459.

RULES

Syntax:

RULES

Requests the server rules. This command is not formally defined in an RFC, but is used by most[ which? ] major IRC daemons.

SERVER

Syntax:

SERVER <servername> <hopcount> <info>

The server message is used to tell a server that the other end of a new connection is a server. [34] This message is also used to pass server data over the whole network. <hopcount> details how many hops (server connections) away <servername> is. <info> contains addition human-readable information about the server.

Defined in RFC 1459.

SERVICE

Syntax:

SERVLIST

SQUERY

Syntax:

SQUERY <servicename> <text>

Identical to PRIVMSG except the recipient must be a service. [35] Defined in RFC 2812.

SQUIT

Syntax:

SQUIT <server> <comment>

Causes <server> to quit the network. [36] Defined in RFC 1459.

SETNAME

Syntax:

SETNAME <new real name>

Allows a client to change the "real name" specified when registering a connection.

This command is not formally defined by an RFC, but is in use by some IRC daemons. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the SETNAME keyword

SILENCE

Syntax:

SILENCE [+/-<hostmask>]

Adds or removes a host mask to a server-side ignore list that prevents matching users from sending the client messages. More than one mask may be specified in a space-separated list, each item prefixed with a "+" or "-" to designate whether it is being added or removed. Sending the command with no parameters returns the entries in the client's ignore list.

This command is not formally defined in an RFC, but is supported by most[ which? ] major IRC daemons. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the SILENCE keyword and the maximum number of entries a client may have in its ignore list. For example:

:irc.server.net 005 WiZ WALLCHOPS WATCH=128 SILENCE=15 MODES=12 CHANTYPES=#

STATS

Syntax:

STATS <query> [<server>]

Returns statistics about the current server, or <server> if it's specified. [37] Defined in RFC 1459.

SUMMON

Syntax:

SUMMON <user> [<server>] (RFC 1459)
SUMMON <user> [<server> [<channel>]] (RFC 2812)

Gives users who are on the same host as <server> a message asking them to join IRC. [38] [39] Defined in RFC 1459; the optional <channel> parameter was added in RFC 2812.

TIME

Syntax:

TIME [<server>]

Returns the local time on the current server, or <server> if specified. [40] Defined in RFC 1459.

TOPIC

Syntax:

TOPIC <channel> [<topic>]

Allows the client to query or set the channel topic on <channel>. [41] If <topic> is given, it sets the channel topic to <topic>. If channel mode +t is set, only a channel operator may set the topic. Defined in RFC 1459.

TRACE

Syntax:

TRACE [<target>]

Trace a path across the IRC network to a specific server or client, in a similar method to traceroute. [42] Defined in RFC 1459.

USER

Syntax:

USER <username> <hostname> <servername> <realname> (RFC 1459)
USER <user> <mode> <unused> <realname> (RFC 2812)

This command is used at the beginning of a connection to specify the username, hostname, real name and initial user modes of the connecting client. [43] [44] <realname> may contain spaces, and thus must be prefixed with a colon. Defined in RFC 1459, modified in RFC 2812.

USERHOST

Syntax:

USERHOST <nickname> [<nickname> <nickname> ...]

Returns a list of information about the nicknames specified. [45] Defined in RFC 1459.

USERIP

Syntax:

USERIP <nickname>

Requests the direct IP address of the user with the specified nickname. This command is often used to obtain the IP of an abusive user to more effectively perform a ban. It is unclear what, if any, privileges are required to execute this command on a server.

This command is not formally defined by an RFC, but is in use by some IRC daemons. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the USERIP keyword.

USERS

Syntax:

USERS [<server>]

Returns a list of users and information about those users in a format similar to the UNIX commands who, rusers and finger. [46] Defined in RFC 1459.

VERSION

Syntax:

VERSION [<server>]

Returns the version of <server>, or the current server if omitted. [47] Defined in RFC 1459.

WALLOPS

Syntax:

WALLOPS <message>

Sends <message> to all operators connected to the server (RFC 1459), or all users with user mode 'w' set (RFC 2812). [48] [49] Defined in RFC 1459.

WATCH

Syntax:

WATCH [+/-<nicknames>]

Adds or removes a user to a client's server-side friends list. More than one nickname may be specified in a space-separated list, each item prefixed with a "+" or "-" to designate whether it is being added or removed. Sending the command with no parameters returns the entries in the client's friends list.

This command is not formally defined in an RFC, but is supported by most[ which? ] major IRC daemons. Support is indicated in a RPL_ISUPPORT reply (numeric 005) with the WATCH keyword and the maximum number of entries a client may have in its friends list. For example:

:irc.server.net 005 WiZ WALLCHOPS WATCH=128 SILENCE=15 MODES=12 CHANTYPES=#

WHO

Syntax:

WHO [<name> ["o"]]

Returns a list of users who match <name>. [50] If the flag "o" is given, the server will only return information about IRC operators. Defined in RFC 1459.

WHOIS

Syntax:

WHOIS [<server>] <nicknames>

Returns information about the comma-separated list of nicknames masks <nicknames>. [51] If <server> is given, the command is forwarded to it for processing. Defined in RFC 1459.

WHOWAS

Syntax:

WHOWAS <nickname> [<count> [<server>]]

Used to return information about a nickname that is no longer in use (due to client disconnection, or nickname changes). [52] If given, the server will return information from the last <count> times the nickname has been used. If <server> is given, the command is forwarded to it for processing. In RFC 2812, <nickname> can be a comma-separated list of nicknames. [53]

Defined in RFC 1459.

See also

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">Internet Relay Chat</span> Protocol for real-time Internet chat and messaging

Internet Relay Chat (IRC) is a text-based chat system for instant messaging. IRC is designed for group communication in discussion forums, called channels, but also allows one-on-one communication via private messages as well as chat and data transfer, including file sharing.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

<span class="mw-page-title-main">Network Time Protocol</span> Standard protocol for synchronizing time across devices

The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

An IRCd, short for Internet Relay Chat daemon, is server software that implements the IRC protocol, enabling people to talk to each other via the Internet. It is distinct from an IRC bot that connects outbound to an IRC channel.

Client-to-client protocol (CTCP) is a special type of communication between Internet Relay Chat (IRC) clients.

<span class="mw-page-title-main">IRC script</span> Way of shortening commands while connected to an IRC network

IRC scripts are a way of shortening commands and responding automatically to certain events while connected to an IRC network. There are many different scripting languages for different types of IRC clients: ircII, BitchX, HexChat, mIRC, Visual IRC, Bersirc, and others have their own scripting languages, many of which share common features and syntax and therefore are easily portable from one IRC client to another.

Flooding or scrolling on an IRC network is a method of disconnecting users from an IRC server, exhausting bandwidth which causes network latency ('lag'), or just disrupting users. Floods can either be done by scripts or by external programs.

MSN Chat was the Microsoft Network version of IRCX, which replaced Microsoft Chat, a set of Exchange-based IRCX servers first available in the Microsoft Comic Chat client, although Comic Chat was not required to connect.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

The Ident Protocol, specified in RFC 1413, is an Internet protocol that helps identify the user of a particular TCP connection. One popular daemon program for providing the ident service is identd.

A Uniform Resource Locator (URL), colloquially known as an address on the Web, is a reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI), although many people use the two terms interchangeably. URLs occur most commonly to reference web pages (HTTP/HTTPS) but are also used for file transfer (FTP), email (mailto), database access (JDBC), and many other applications.

References

  1. ↑ Admin command. p. 31. sec. 4.3.7. doi: 10.17487/RFC1459 . RFC 1459.
  2. ↑ Away. pp. 38 – 39. sec. 5.1. doi: 10.17487/RFC1459 . RFC 1459.
  3. ↑ Connect message. pp. 29 – 30. sec. 4.3.5. doi: 10.17487/RFC1459 . RFC 1459.
  4. ↑ Connect message. pp. 28 – 29. sec. 3.4.7. doi: 10.17487/RFC2812 . RFC 2812.
  5. ↑ Die message. p. 39. sec. 4.3. doi: 10.17487/RFC2812 . RFC 2812.
  6. ↑ "Archived copy". Archived from the original on 5 June 2013. Retrieved 6 December 2012.{{cite web}}: CS1 maint: archived copy as title (link)
  7. ↑ Error. p. 38. sec. 4.6.4. doi: 10.17487/RFC1459 . RFC 1459.
  8. ↑ Info command. pp. 31 – 32. sec. 4.3.8. doi: 10.17487/RFC1459 . RFC 1459.
  9. ↑ Invite message. p. 25. sec. 4.2.7. doi: 10.17487/RFC1459 . RFC 1459.
  10. ↑ Ison message. p. 42. sec. 5.8. doi: 10.17487/RFC1459 . RFC 1459.
  11. ↑ Join message. pp. 19 – 20. sec. 4.2.1. doi: 10.17487/RFC1459 . RFC 1459.
  12. ↑ Kick command. pp. 25 – 26. sec. 4.2.8. doi: 10.17487/RFC1459 . RFC 1459.
  13. ↑ Kill message. p. 36. sec. 4.6.1. doi: 10.17487/RFC1459 . RFC 1459.
  14. ↑ Links message. pp. 28 – 29. sec. 4.3.3. doi: 10.17487/RFC1459 . RFC 1459.
  15. ↑ List message. pp. 24 – 25. sec. 4.2.6. doi: 10.17487/RFC1459 . RFC 1459.
  16. ↑ Lusers message. pp. 25 – 26. sec. 3.4.2. doi: 10.17487/RFC2812 . RFC 2812.
  17. ↑ Mode message. pp. 21 – 23. sec. 4.2.3. doi: 10.17487/RFC1459 . RFC 1459.
  18. ↑ Motd message. p. 25. sec. 3.4.1. doi: 10.17487/RFC2812 . RFC 2812.
  19. ↑ Names message. p. 24. sec. 4.2.5. doi: 10.17487/RFC1459 . RFC 1459.
  20. ↑ Names message. pp. 20 – 21. sec. 3.2.5. doi: 10.17487/RFC2812 . RFC 2812.
  21. ↑ Andrew Northall. "IRCv3 – Welcome". atheme.org. ircv3.net. Archived from the original on 9 January 2015. Retrieved 21 February 2016.
  22. ↑ Andrew Northall. "IRCv3 – Welcome". atheme.org. Archived from the original on 17 February 2015. Retrieved 21 February 2016.
  23. ↑ Nick message. pp. 14 – 15. sec. 4.1.2. doi: 10.17487/RFC1459 . RFC 1459.
  24. ↑ Nick message. pp. 10 – 11. sec. 3.1.2. doi: 10.17487/RFC2812 . RFC 2812.
  25. ↑ Notice. p. 33. sec. 4.4.2. doi: 10.17487/RFC1459 . RFC 1459.
  26. ↑ Oper. p. 17. sec. 4.1.5. doi: 10.17487/RFC1459 . RFC 1459.
  27. ↑ Part message. pp. 20 – 21. sec. 4.2.2. doi: 10.17487/RFC1459 . RFC 1459.
  28. ↑ Password message. p. 14. sec. 4.1.1. doi: 10.17487/RFC1459 . RFC 1459.
  29. ↑ Ping message. p. 37. sec. 4.6.2. doi: 10.17487/RFC1459 . RFC 1459.
  30. ↑ Pong message. pp. 37 – 38. sec. 4.6.3. doi: 10.17487/RFC1459 . RFC 1459.
  31. ↑ Private messages. pp. 32 – 33. sec. 4.4.1. doi: 10.17487/RFC1459 . RFC 1459.
  32. ↑ Quit. pp. 17 – 18. sec. 4.1.6. doi: 10.17487/RFC1459 . RFC 1459.
  33. ↑ Rehash message. p. 39. sec. 5.2. doi: 10.17487/RFC1459 . RFC 1459.
  34. ↑ Server message. pp. 16 – 17. sec. 4.1.4. doi: 10.17487/RFC1459 . RFC 1459.
  35. ↑ Squery. p. 32. sec. 3.5.2. doi: 10.17487/RFC2812 . RFC 2812.
  36. ↑ Server quit message. pp. 18 – 19. sec. 4.1.7. doi: 10.17487/RFC1459 . RFC 1459.
  37. ↑ Stats message. pp. 27 – 28. sec. 4.3.2. doi: 10.17487/RFC1459 . RFC 1459.
  38. ↑ Summon message. p. 40. sec. 5.4. doi: 10.17487/RFC1459 . RFC 1459.
  39. ↑ Summon message. p. 40. sec. 4.5. doi: 10.17487/RFC2812 . RFC 2812.
  40. ↑ Time message. p. 29. sec. 4.3.4. doi: 10.17487/RFC1459 . RFC 1459.
  41. ↑ Topic message. pp. 23 – 24. sec. 4.2.4. doi: 10.17487/RFC1459 . RFC 1459.
  42. ↑ Trace message. pp. 30 – 31. sec. 4.3.6. doi: 10.17487/RFC1459 . RFC 1459.
  43. ↑ User message. pp. 15 – 16. sec. 4.1.3. doi: 10.17487/RFC1459 . RFC 1459.
  44. ↑ User message. p. 11. sec. 3.1.3. doi: 10.17487/RFC2812 . RFC 2812.
  45. ↑ Userhost message. p. 42. sec. 5.7. doi: 10.17487/RFC1459 . RFC 1459.
  46. ↑ Users. pp. 40 – 41. sec. 5.5. doi: 10.17487/RFC1459 . RFC 1459.
  47. ↑ Version message. pp. 26 – 27. sec. 4.3.1. doi: 10.17487/RFC1459 . RFC 1459.
  48. ↑ Operwall message. p. 41. sec. 5.6. doi: 10.17487/RFC1459 . RFC 1459.
  49. ↑ Operwall message. pp. 41 – 42. sec. 4.7. doi: 10.17487/RFC2812 . RFC 2812.
  50. ↑ Who query. pp. 33 – 34. sec. 4.5.1. doi: 10.17487/RFC1459 . RFC 1459.
  51. ↑ Whois query. pp. 34 – 35. sec. 4.5.2. doi: 10.17487/RFC1459 . RFC 1459.
  52. ↑ Whowas. p. 35. sec. 4.5.3. doi: 10.17487/RFC1459 . RFC 1459.
  53. ↑ Whowas. p. 34. sec. 3.6.3. doi: 10.17487/RFC2812 . RFC 2812.

Bibliography

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.