DareNET P10 - Revision history

Admin: /* Numerics */

2009-04-27T03:34:32Z

Numerics

← Older revision		Revision as of 03:34, 27 April 2009
Line 127:		Line 127:
	If one can parse short numerics, it must consider the short numeric SCC and extended numeric ASACC, and also the short numeric S and extended numeric AS, as being equivalent; both can identify the same thing.		If one can parse short numerics, it must consider the short numeric SCC and extended numeric ASACC, and also the short numeric S and extended numeric AS, as being equivalent; both can identify the same thing.

-	An implementation ~~coplies~~ with both standards if it can parse short numerics and extended numerics, and generates only extended numerics. This is true of ircd-darenet.	+	An implementation complies with both standards if it can parse short numerics and extended numerics, and generates only extended numerics. This is true of ircd-darenet.

	NOTE (1): universial-ircu can send 4 character numerics (SCCC). This is not valid according to this protocol definition, one must not send them. However, right now, one may parse them, if they are translated to ASCCC. Doing this allows a P10 implementation to link to universal. This may change later, 4 char numerics may later be used for something different, such as services.		NOTE (1): universial-ircu can send 4 character numerics (SCCC). This is not valid according to this protocol definition, one must not send them. However, right now, one may parse them, if they are translated to ASCCC. Doing this allows a P10 implementation to link to universal. This may change later, 4 char numerics may later be used for something different, such as services.

Admin: /* Syntax of a Line */

2009-04-27T03:31:11Z

Syntax of a Line

← Older revision		Revision as of 03:31, 27 April 2009
Line 143:		Line 143:
	* One must send only the short command token (detailed in the next section). One may parse both short and long command token, and if one does, they must be considered equivalent; for example, N = NICK. So, say if we were to say "receives a NICK line," it may actually be a N token.		* One must send only the short command token (detailed in the next section). One may parse both short and long command token, and if one does, they must be considered equivalent; for example, N = NICK. So, say if we were to say "receives a NICK line," it may actually be a N token.
	* Command tokens are uppercase. One must not send lowercase command tokens. One may parse them.		* Command tokens are uppercase. One must not send lowercase command tokens. One may parse them.
		+	* If source begins with a colon, it (except for the colon) is the name. Otherwise, it is a numeric. A P10 implementation must only send lines with a numeric source prefix.
		+	* If the source does not exist, and the command is KILL or SQUIT (or short token), the line must be parsed anyway with the directly linked server from which the message came as the source; otherwise, the line must be ignored.
		+	* If the source exists but the message comes from the wrong direction, it must be ignored.
		+	* A line may have up to 15 parameters. Parameters are separated by spaces.
		+	* The last parameter may be prefixed by a colon; this allows the last parameter to have spaces, or to have a length of 0 characters: <code><nowiki><source> <command> <param1> <paramN> :<last parameter></nowiki></code>. A parser must be able to parse lines with colon prefixed last parameter, and without. for example parameters "a b c" and "a b :c" are equivalent.

Admin: /* Syntax of a Line */

2009-04-27T03:25:46Z

Syntax of a Line

← Older revision		Revision as of 03:25, 27 April 2009
Line 139:		Line 139:
	The source, command and parameters are separated by spaces.		The source, command and parameters are separated by spaces.

-	<~~code~~><source> <command> [<parameters>]</~~code~~>	+	<pre><source> <command> [<parameters>]</pre>

	* One must send only the short command token (detailed in the next section). One may parse both short and long command token, and if one does, they must be considered equivalent; for example, N = NICK. So, say if we were to say "receives a NICK line," it may actually be a N token.		* One must send only the short command token (detailed in the next section). One may parse both short and long command token, and if one does, they must be considered equivalent; for example, N = NICK. So, say if we were to say "receives a NICK line," it may actually be a N token.
	* Command tokens are uppercase. One must not send lowercase command tokens. One may parse them.		* Command tokens are uppercase. One must not send lowercase command tokens. One may parse them.

Admin: /* Numerics */

2009-04-27T03:25:07Z

Numerics

← Older revision		Revision as of 03:25, 27 April 2009
Line 132:		Line 132:

	NOTE (2): An implementation can be or not be transparent to numerics -- sending them as it receives them, preserving short/extended. ircd-darenet is transparent to numerics. This means, it can't be between something which sends short numerics, and something which can't parse short numerics.		NOTE (2): An implementation can be or not be transparent to numerics -- sending them as it receives them, preserving short/extended. ircd-darenet is transparent to numerics. This means, it can't be between something which sends short numerics, and something which can't parse short numerics.
		+
		+	== Syntax of a Line ==
		+
		+	Space is character 32 ($20).
		+
		+	The source, command and parameters are separated by spaces.
		+
		+	<code><source> <command> [<parameters>]</code>
		+
		+	* One must send only the short command token (detailed in the next section). One may parse both short and long command token, and if one does, they must be considered equivalent; for example, N = NICK. So, say if we were to say "receives a NICK line," it may actually be a N token.
		+	* Command tokens are uppercase. One must not send lowercase command tokens. One may parse them.

Admin: /* P10 Base64 */

2009-04-27T03:17:18Z

P10 Base64

← Older revision		Revision as of 03:17, 27 April 2009
Line 86:		Line 86:
	== P10 Base64 ==		== P10 Base64 ==

-	The P10 protocol uses a base64 notation for numerics to uniquely identify a client or server, and for the IP parameter in the N token. he Base64 character set used in ircd-darenet (ircu) is included below, this defines all valid characters allowed in a Base64 numeric with "A" representing 0 and "]" representing 63.	+	The P10 protocol uses a base64 notation for numerics to uniquely identify a client or server, and for the IP parameter in the N token. The Base64 character set used in ircd-darenet (ircu) is included below, this defines all valid characters allowed in a Base64 numeric with "A" representing 0 and "]" representing 63.

	<code>ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789[]</code>		<code>ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789[]</code>
Line 95:		Line 95:

	Note: P10 base64 strings are case significant. Whenever this document mentions "base64", read it as "P10 base64".		Note: P10 base64 strings are case significant. Whenever this document mentions "base64", read it as "P10 base64".
		+
		+	== Numerics ==
		+
		+	As mentioned earlier, the P10 protocol uses a scheme of "numerics" to uniquely identify a client or server within the network. Each server has its own unique numeric (0 -> 4095) and each client has its own numeric within that server (0 -> 262,143). The numeric is a base64 string or 2 concatenated base64 strings.
		+
		+	Server numerics consist of 2 characters, with the minimum, 0, being represented by "AA", and the maximum, 4095, being represented by "]]". Client numerics are 3 characters long, with the minimum, 0, being represented by "AAA", and the maximum, 262,143, being represented by "]]]". The unique identifier of a client on the network consists of a combination of both the server and client numeric in the format SSCCC.
		+
		+	A server has a "max client numeric." This is sent in SERVER messages (detailed later in this document). A client numeric on a server, ANDed with the max server numeric, must be unique. For example, if server YY's max client numeric is YYA]] (4095), clients YYBXX and YYCXC can't exist at the same time, doing this would cause a "numeric collision," which is a protocol violation. But, such numerics which occupy the same "slot" are not identical - a message sent to use YYBXX in this example must not reach user YYCXX.
		+
		+	Described above are "extended numerics", as used on DareNET.
		+
		+	'''Short Numerics'''
		+
		+	P10 short numerics use 1 char for server numerics, allowing 64 servers on the net, and a 3 chars for client numerics: server numeric + 2 characters for the client on that server, allowing 4096 clients on one server.
		+
		+	* SS = extended numerics, server.
		+	* SSCCC = extended numerics, client
		+	* S = short numerics server
		+	* SCC = short numerics client.
		+
		+	In any example numeric with S and C, interpret "S" as a character of the server number, "C" as the client on the server.
		+
		+	'''Extended vs Short'''
		+
		+	We've covered two different standards which are not compatible with each other, so let's break it down a bit more:
		+
		+	Extended Numerics Only: The P10 protocol, as used by DareNET (and most other networks, including Undernet), one must parse and send extended numerics. One may parse short numerics. One must not generate short numerics.
		+
		+	General Purpose P10 (mixed short/extended numerics): One must parse both short and extended numerics, and may generate both short and extended numerics. This also implies that any numeric which is ASACC or AS may be sent as a short numeric.
		+
		+	If one can parse short numerics, it must consider the short numeric SCC and extended numeric ASACC, and also the short numeric S and extended numeric AS, as being equivalent; both can identify the same thing.
		+
		+	An implementation coplies with both standards if it can parse short numerics and extended numerics, and generates only extended numerics. This is true of ircd-darenet.
		+
		+	NOTE (1): universial-ircu can send 4 character numerics (SCCC). This is not valid according to this protocol definition, one must not send them. However, right now, one may parse them, if they are translated to ASCCC. Doing this allows a P10 implementation to link to universal. This may change later, 4 char numerics may later be used for something different, such as services.
		+
		+	NOTE (2): An implementation can be or not be transparent to numerics -- sending them as it receives them, preserving short/extended. ircd-darenet is transparent to numerics. This means, it can't be between something which sends short numerics, and something which can't parse short numerics.

Admin: /* Garbage */

2009-04-27T02:52:02Z

Garbage

← Older revision		Revision as of 02:52, 27 April 2009
Line 83:		Line 83:

	Any data between the last EOL and the end of the stream. It must not be parsed as a line.		Any data between the last EOL and the end of the stream. It must not be parsed as a line.
		+
		+	== P10 Base64 ==
		+
		+	The P10 protocol uses a base64 notation for numerics to uniquely identify a client or server, and for the IP parameter in the N token. he Base64 character set used in ircd-darenet (ircu) is included below, this defines all valid characters allowed in a Base64 numeric with "A" representing 0 and "]" representing 63.
		+
		+	<code>ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789[]</code>
		+
		+	They are from now referred to as the P10 base64 characters.
		+
		+	A P10 base64 string is a sequence of P10 base64 characters, with a minimum length of 1 character. it must not contain any other character. If the string has a length of more than one character, the string begins with the most significant character and ends with the least significant character.
		+
		+	Note: P10 base64 strings are case significant. Whenever this document mentions "base64", read it as "P10 base64".

Admin: /* Garbage */

2009-04-27T02:45:13Z

Garbage

← Older revision		Revision as of 02:45, 27 April 2009
Line 82:		Line 82:
	=== Garbage ===		=== Garbage ===

-	Any data between the last EOL and the end of the stream. It ''must not'' be parsed as a line.	+	Any data between the last EOL and the end of the stream. It must not be parsed as a line.

Admin: /* Line */

2009-04-27T02:45:00Z

Line

← Older revision		Revision as of 02:45, 27 April 2009
Line 74:		Line 74:
	=== Line ===		=== Line ===

-	A sequence of characters, minimum length 1 byte, maximum length 510 bytes, not including the EOL. If a parser encounters a line with a length of 0 bytes, it ''must'' be silently ignored, and it ''must not'' do anything else. A line which is longer than the maximum length is disallowed.	+	A sequence of characters, minimum length 1 byte, maximum length 510 bytes, not including the EOL. If a parser encounters a line with a length of 0 bytes, it must be silently ignored, and it must not do anything else. A line which is longer than the maximum length is disallowed.

	NULL, CR and LF are disallowed in a line, any other character is allowed.		NULL, CR and LF are disallowed in a line, any other character is allowed.

-	NOTE on NULL character: A parser can encounter a line which contains a NULL character. It ''may'' terminate the line at the first NULL character (remove anything after and including the first NULL character from the line).	+	NOTE on NULL character: A parser can encounter a line which contains a NULL character. It may terminate the line at the first NULL character (remove anything after and including the first NULL character from the line).

	=== Garbage ===		=== Garbage ===

	Any data between the last EOL and the end of the stream. It ''must not'' be parsed as a line.		Any data between the last EOL and the end of the stream. It ''must not'' be parsed as a line.

Admin: /* Line termination (EOL) */

2009-04-27T02:44:38Z

Line termination (EOL)

← Older revision		Revision as of 02:44, 27 April 2009
Line 68:		Line 68:
	=== Line termination (EOL) ===		=== Line termination (EOL) ===

-	When sending, line termination may be either <CRLF> or <LF>. It ''must not'' be anything else.	+	When sending, line termination may be either <CRLF> or <LF>. It must not be anything else.

-	The parser ''must'' accept <LF> and <CRLF> as line termination. It ''may'' accept any other sequence of <CR> and <LF> as EOL. It ''must not'' parse anything else as "line termination."	+	The parser must accept <LF> and <CRLF> as line termination. It may accept any other sequence of <CR> and <LF> as EOL. It must not parse anything else as "line termination."

	=== Line ===		=== Line ===

Admin: /* Line */

2009-04-27T02:44:11Z

Line

← Older revision		Revision as of 02:44, 27 April 2009
Line 74:		Line 74:
	=== Line ===		=== Line ===

-	A sequence of characters, minimum length 1 byte, maximum length 510 bytes, ''not'' including the EOL. If a parser encounters a line with a length of 0 bytes, it ''must'' be silently ignored, and it ''must not'' do anything else. A line which is longer than the maximum length is disallowed.	+	A sequence of characters, minimum length 1 byte, maximum length 510 bytes, not including the EOL. If a parser encounters a line with a length of 0 bytes, it ''must'' be silently ignored, and it ''must not'' do anything else. A line which is longer than the maximum length is disallowed.

	NULL, CR and LF are disallowed in a line, any other character is allowed.		NULL, CR and LF are disallowed in a line, any other character is allowed.