mirror of
				https://github.com/osmarks/ngircd.git
				synced 2025-10-31 14:02:59 +00:00 
			
		
		
		
	 47ca178a21
			
		
	
	47ca178a21
	
	
	
		
			
			- New configuration option "MaxNickLength" to specify the allowed maximum length of user nick names. Note: must be unique in an IRC network! - Enhanced the IRC+ protocol to support an enhanced "server handshake" and enable server to recognice numeric 005 (ISUPPORT) and 376 (ENDOFMOTD). See doc/Protocol.txt for details.
		
			
				
	
	
		
			165 lines
		
	
	
		
			6.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			165 lines
		
	
	
		
			6.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 
 | |
|                      ngIRCd - Next Generation IRC Server
 | |
| 
 | |
|                         (c)2001-2007 Alexander Barton,
 | |
|                     alex@barton.de, http://www.barton.de/
 | |
| 
 | |
|                ngIRCd is free software and published under the
 | |
|                    terms of the GNU General Public License.
 | |
| 
 | |
|                               -- Protocol.txt --
 | |
| 
 | |
| 
 | |
| I. Compatibility
 | |
| ~~~~~~~~~~~~~~~~
 | |
| 
 | |
| The ngIRCd implements the Internet Relay Chat (IRC) protocol version 2.10
 | |
| as defined in RFC ("request for comment") 1459 and 2810-2813. These (and
 | |
| probably further relevant RFCs) are listed in doc/RFC.txt.
 | |
| 
 | |
| Unfortunately, even the "original" ircd doesn't follow these specifications
 | |
| in all details. But because the ngIRCd should be a fully compatible
 | |
| replacement for this server ("ircd") it tries to emulate these differences.
 | |
| 
 | |
| If you don't like this behavior please ./configure the ngIRCd using the
 | |
| "--enable-strict-rfc" command line option. But keep in mind: not all IRC
 | |
| clients are compatible with a server configured that way, some can't even
 | |
| connect at all! Therefore this option usually isn't desired for "normal
 | |
| server operation".
 | |
| 
 | |
| 
 | |
| II. The IRC+ Protocol
 | |
| ~~~~~~~~~~~~~~~~~~~~~
 | |
| 
 | |
| Starting with version 0.5.0, the ngIRCd extends the original IRC protocol
 | |
| as defined in RFC 2810-2813. This enhanced protocol is named "IRC+". It is
 | |
| backwards compatible to the "plain" IRC protocol and will only be used by
 | |
| the ngIRCd if it detects that the peer supports it as well.
 | |
| 
 | |
| The "PASS" command is used to detect the protocol and peer versions see
 | |
| RFC 2813 (section 4.1.1) and below.
 | |
| 
 | |
| 
 | |
| II.1 Register new server link
 | |
| 
 | |
|      Command: PASS
 | |
|   Parameters: <password> <version> <flags> [<options>]
 | |
|      Used by: servers only (with these parameters)
 | |
| 
 | |
| <password> is the password for this new server link as defined in the server
 | |
| configuration which is sent to the peer or received from it.
 | |
| 
 | |
| <version> consists of two parts and is at least 4, at most 14 characters
 | |
| long: the first four bytes contain the IRC protocol version number, whereas
 | |
| the first two bytes represent the major version, the last two bytes the
 | |
| minor version (the string "0210" indicates version 2.10, e.g.).
 | |
| 
 | |
| The following optional(!) 10 bytes contain an implementation-dependent
 | |
| version number. Servers supporting the IRC+ protocol as defined in this
 | |
| document provide the string "-IRC+" here.
 | |
| 
 | |
| Example for <version>: "0210-IRC+".
 | |
| 
 | |
| <flags> consists of two parts separated with the character "|" and is at
 | |
| most 100 bytes long. The first part contains the name of the implementation
 | |
| (ngIRCd sets this to "ngircd", the original ircd to "IRC", e.g.). The second
 | |
| part is implementation-dependent and should only be parsed if the peer
 | |
| supports the IRC+ protocol as well. In this case the following syntax is
 | |
| used: "<serverversion>[:<serverflags>]".
 | |
| 
 | |
| <serverversion> is an ASCII representation of the clear-text server version
 | |
| number, <serverflags> indicates the supported IRC+ protocol extensions (and
 | |
| may be empty!).
 | |
| 
 | |
| The following <serverflags> are defined at the moment:
 | |
| 
 | |
| - C: The server supports the CHANINFO command.
 | |
| 
 | |
| - L: INVITE- and BAN-lists should be synchronized between servers: if the
 | |
|      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.
 | |
| 
 | |
| - o: IRC operators are allowed to change channel- and channel-user-modes
 | |
|      even if they aren't channel-operator of the affected channel.
 | |
| 
 | |
| - Z: Compressed server links are supported by the server.
 | |
| 
 | |
| Example for a complete <flags> string: "ngircd|0.7.5:CZ".
 | |
| 
 | |
| The optional parameter <options> is used to propagate server options as
 | |
| defined in RFC 2813, section 4.1.1.
 | |
| 
 | |
| 
 | |
| 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 nick name 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> <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.
 | |
| 
 | |
| 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)
 | |
| already set. It there are already values set the server ignores the
 | |
| corresponding parameter.
 | |
| 
 | |
| If the channel doesn't exists at all it will be created.
 | |
| 
 | |
| The parameter <key> must be ignored if a channel has no key (the parameter
 | |
| <modes> doesn't list the "k" channel mode). In this case <key> should
 | |
| contain "*" because the parameter <key> is required by the CHANINFO syntax
 | |
| and therefore can't be omitted. The parameter <limit> must be ignored when
 | |
| a channel has no user limit (the parameter <modes> doesn't list the "l"
 | |
| channel mode). In this case <limit> should be "0".
 | |
| 
 | |
| 
 | |
| -- 
 | |
| $Id: Protocol.txt,v 1.14 2007/11/21 12:16:35 alex Exp $
 |