File: PROTOCOL

package info (click to toggle)
dircproxy 1.0.3-1
  • links: PTS
  • area: main
  • in suites: woody
  • size: 1,108 kB
  • ctags: 738
  • sloc: ansic: 9,451; sh: 2,672; makefile: 113; perl: 70
file content (58 lines) | stat: -rw-r--r-- 2,194 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
IRC protocol notes
------------------

IRC has been for a long time notoriously under-documented.
The original RFC was RFC1459 ("Internet Relay Chat Protocol") and
was written way back in May 1993.  Since that time the IRC protocol
has changed quite a bit, especially in respect to the numeric codes
sent to clients by the server.

These have been recently updated to the modern 2.10 IRC protocol
as used by the IRCnet network.  They do differ in a few places,
and where they do, dircproxy follows the new RFCs.

For reference, the new RFCs are as follows:

	RFC2810  Internet Relay Chat: Architecture
        RFC2811  Internet Relay Chat: Channel Management
        RFC2812  Internet Relay Chat: Client Protocol
        RFC2813  Internet Relay Chat: Server Protocol


Noteworthy differences
======================

RFC1459 says that parameters 2 and 3 of the USER command should be
the hostname of the client, and of the server.	With the advent of
DNS and ident checking etc, these have been redundant for a while.
RFC2812 changes the meaning of these parameters, defining the
second parameter to be a bit mask of modes to set on connection,
and the third to be unused.

dircproxy completely ignores the 3rd parameter, and performs an
atoi() on the second.  If the second isn't 0 then it assumes the
client follows RFC2812 and treats the bits accordingly.

dircproxy always sends "0" as the second parameter and "*" as the
third to any server it connects to.


Modern servers send four numerics upon connection, 001 thru 004.
These provide information about the server.  These were not defined
in RFC1459 but are defined in RFC2812.

dircproxy requires these parameters to be sent by the server so
it knows when the connection is completed.  All servers send them
anyway, so this should not cause a problem.


RFC1459 says parameters in commands can be separated by one or
more spaces.  RFC2812 says they are separated by only ONE space
(thus allowing for empty parameters).

dircproxy follows RFC2812 by default, however if this causes problems
for you then define the OLD_RFC1459_PARAM_SPACE in dircproxy.h


Copyright (C) 2002 Scott James Remnant <scott@netsplit.com>.
All Rights Reserved.