ngIRCd - Next Generation IRC Server
+ http://ngircd.barton.de/
- (c)2001-2003 by Alexander Barton,
- alex@barton.de, http://www.barton.de/
-
+ (c)2001-2012 Alexander Barton and Contributors.
ngIRCd is free software and published under the
terms of the GNU General Public License.
peer understands this flag, it will send "MODE +I" and "MODE +b"
commands after the server link has been established.
+- H: The server supports the "enhanced server handshake", see section II.2
+ for a detailed description.
+
+- M: Changing client "metadata" (hostname, real name, ...) using the
+ METADATA command is supported.
+
- o: IRC operators are allowed to change channel- and channel-user-modes
even if they aren't channel-operator of the affected channel.
+- S: The server supports the SERVICE command (on this link).
+
+- X: Server supports XOP channel modes (owner, admin, halfop) and supports
+ these user prefixes in CHANINFO commands, for example.
+
- Z: Compressed server links are supported by the server.
Example for a complete <flags> string: "ngircd|0.7.5:CZ".
defined in RFC 2813, section 4.1.1.
-II.2 Exchange channel-modes, topics, and persistent channels
+II.2 Enhanced Server Handshake
+
+The "enhanced server handshake" is used when both servers support this IRC+
+extension, which is indicated by the 'H' flag in the <serverflags> sent with
+the PASS command, see section II.1.
+
+It basically means, that after exchanging the PASS and SERVER commands the
+server is not registered in the network (as usual), but that IRC numerics
+are exchanged until the numeric 376 (ENDOFMOTD) is received. Afterwards the
+peer is registered in the network as with the regular IRC protocol.
+
+A server implementing the enhanced server handshake (and indicating this
+using 'H' in the <serverflags>) MUST ignore all unknown numerics to it
+silently.
+
+In addition, such a server should at least send the numeric 005 (ISUPPORT)
+to its peer, containing the following information. Syntax: <key>=<value>,
+one token per IRC parameter. If the server has to send more than 12 token
+it must send separate ISUPPORT numerics (this is a limitation of the IRC
+protocol which allows at max 15 arguments per command).
+
+ - NICKLEN: Maximum nickname length. Default: 9.
+ - CASEMAPPING: Case mapping used for nick- and channel name comparing.
+ Default: "ascii", the chars [a-z] are lowercase of [A-Z].
+ - PREFIX: List of channel modes a person can get and the respective prefix
+ a channel or nickname will get in case the person has it. The order of the
+ modes goes from most powerful to least powerful. Default: "(ov)@+"
+ - CHANTYPES: Supported channel prefixes. Default: "#".
+ - CHANMODES: List of channel modes for 4 types, separated by comma (","):
+ Mode that adds or removes a nick or address to a list, mode that changes
+ a setting (both have always has a parameter), mode that changes a setting
+ and only has a parameter when set, and mode that changes a setting and
+ never has a parameter. For example "bI,k,l,imnPst".
+ - CHANLIMIT: Maximum number of channels allowed to join by channel prefix,
+ for example "#:10".
+
+Please see <http://www.irc.org/tech_docs/005.html> for details.
+
+The information exchanged using ISUPPORT can be used to detect configuration
+incompatibilities (different maximum nickname length, for example) and
+therefore to disconnect the peer prior to registering it in the network.
+
+
+II.3 Exchange channel-modes, topics, and persistent channels
Command: CHANINFO
- Parameters: <channel> +<modes> <key> <maxusers> [<topic>]
+ Parameters: <channel> +<modes> [[<key> <limit>] <topic>]
Used by: servers only
CHANINFO is used by servers to inform each other about a channel: its
-modes, channel key, user limits and its topic. <topic> is optional.
+modes, channel key, user limits and its topic. The parameter combination
+<key> and <limit> is optional, as well as the <topic> parameter, so that
+there are three possible forms of this command:
+
+ CHANINFO <channel> +<modes>
+ CHANINFO <channel> +<modes> <topic>
+ CHANINFO <channel> +<modes> <key> <limit> <topic>
If the channel already exists on the server receiving the CHANINFO command,
it only adopts the <modes> (or the <topic>) if there are no modes (or topic)
channel mode). In this case <limit> should be "0".
---
-$Id: Protocol.txt,v 1.12 2004/04/25 15:44:10 alex Exp $
+II.4 Update webchat/proxy client information
+
+ Command: WEBIRC
+ Parameters: <password> <username> <hostname> <ip-address> [<ignored>]
+ Used by: unregistered clients only
+
+The WEBIRC command is used by some Web-to-IRC gateways to set the correct
+user name and host name of users instead of their own. It must be the very
+first command sent to the server, even before USER and NICK commands!
+
+The <password> must be set in the server configuration file to prevent
+unauthorized clients to fake their identity; it is an arbitrary string.
+
+Optionally, a 5th parameter is accepted to comply with an IRCv3 extension,
+see <https://github.com/ircv3/ircv3-ideas/issues/12>, but ignored.
+
+
+II.5 Client character encoding conversion
+
+ Command: CHARCONV
+ Parameters: <client-charset>
+ Used by: registered clients
+ Replies: RPL_IP_CHARCONV, ERR_IP_CHARCONV
+
+A client can set its character set encoding using the CHARCONV command:
+after receiving such a command, the server translates all message data
+received from the client using the set <client-charset> to the server
+encoding (UTF-8), and all message data which is to be sent to the client
+from the server encoding (UTF-8) to <client-charset>.
+
+The list of supported client character sets is implementation dependent.
+
+If a client sets its <client-charset> to the server encoding (UTF-8),
+it disables all conversions; the connection behaves as if no CHARCONV
+command has been sent at all in this session.
+
+
+II.6 Update client "metadata"
+
+ Command: METADATA
+ Parameters: <target> <key> <value>
+ Used by: servers only
+
+The METADATA command is used on server-links to update "metadata" information
+of clients, like the hostname, the info text ("real name"), or the user name.
+
+The server updates its client database according to the received <key> and
+<value> parameters, and passes the METADATA command on to all the other
+servers in the network that support this command (see section II.1 "Register
+new server link", <serverflag> "M"), even if it doesn't support the given
+<key> itself: unknown <key> names are ignored silently!
+
+The following <key> names are defined:
+
+ - "accountname": the account name of a client (can't be empty)
+ - "certfp": the certificate fingerprint of a client (can't be empty)
+ - "cloakhost": the cloaked hostname of a client
+ - "host": the hostname of a client (can't be empty)
+ - "info": info text ("real name") of a client
+ - "user": the user name of a client (can't be empty)
+
+
+III. Numerics used by IRC+ Protocol
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The IRC+ protocol uses numerics in the range 800-899 which aren't used by
+RFC 2812 and hopefully don't clash with other implementations ...
+
+Numerics 800-849 are used for status and success messages, and numerics
+850-899 are failure and error messages.
+
+
+III.1 IRC+ status and success numerics
+
+801 - RPL_IP_CHARCONV
+ %1 :Client encoding set"
+
+ %1 client character set
+
+
+III.2 IRC+ failure and error numerics
+
+851 - ERR_IP_CHARCONV
+ :Can't initialize client encoding
projects / ngircd-alex.git / blobdiff