Network Working Group L. Hardy
Internet-Draft E. Brocklesby
Expires: July 2, 2005 ircd-ratbox
K. Mitchell
Undernet IRC Network
January 2005
IRC RPL_ISUPPORT Numeric Definition
draft-hardy-irc-isupport-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IRC (Internet Relay Chat) is a long-standing protocol for real-time
chatting. Servers often provide features that are backward
compatible with older clients, but do not provide a reliable method
for making clients aware of what extensions exist. This memo
presents a method for servers to advertise such extensions to
Hardy, et al. Expires July 2, 2005 [Page 1]
Internet-Draft IRC RPL_ISUPPORT January 2005
clients.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problems to be Solved . . . . . . . . . . . . . . . . . . . 5
3. The RPL_ISUPPORT numeric . . . . . . . . . . . . . . . . . . 6
4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 CASEMAPPING . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 CHANLIMIT . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 CHANMODES . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 CHANNELLEN . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 CHANTYPES . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6 CNOTICE . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7 CPRIVMSG . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.8 ELIST . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.9 EXCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.10 INVEX . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.11 MAXLIST . . . . . . . . . . . . . . . . . . . . . . . . 12
4.12 MODES . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.13 NETWORK . . . . . . . . . . . . . . . . . . . . . . . . 13
4.14 NICKLEN . . . . . . . . . . . . . . . . . . . . . . . . 13
4.15 PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.16 SAFELIST . . . . . . . . . . . . . . . . . . . . . . . . 14
4.17 SILENCE . . . . . . . . . . . . . . . . . . . . . . . . 14
4.18 STATUSMSG . . . . . . . . . . . . . . . . . . . . . . . 14
4.19 TARGMAX . . . . . . . . . . . . . . . . . . . . . . . . 15
4.20 TOPICLEN . . . . . . . . . . . . . . . . . . . . . . . . 15
4.21 WATCH . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Differences to existing implementations . . . . . . . . . . 17
5.1 Conflicts with RFC2812 . . . . . . . . . . . . . . . . . . 17
5.2 Traditional EXCEPTS/INVEX usage . . . . . . . . . . . . . 17
5.3 MAXBANS . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4 MAXCHANNELS . . . . . . . . . . . . . . . . . . . . . . . 17
5.5 MAXTARGETS . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6 WALLCHOPS . . . . . . . . . . . . . . . . . . . . . . . . 18
Hardy, et al. Expires July 2, 2005 [Page 2]
Internet-Draft IRC RPL_ISUPPORT January 2005
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B. ABNF Description of Capabilities . . . . . . . . . . . . . . 24
C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 26
Hardy, et al. Expires July 2, 2005 [Page 3]
Internet-Draft IRC RPL_ISUPPORT January 2005
1. Introduction
The IRC protocol, as originally documented by RFC 1459 [2] and
updated by RFC 2812 [3], is a simple, text-based conferencing
protocol, involving a number of users spread across a number of
interconnected servers. These users may chat with other individual
users, or may chat with groups of users on "channels"--what other
chat systems refer to as "rooms" or "chat rooms". These channels
have various "modes" which can alter the behaviour of the channel.
Over the years, various modifications to the basic IRC protocol have
been made by IRC server programmers. These modifications may amongst
other things, introduce features available to users and remove some
features that were available to users. Due to the wildly varying
nature between IRC servers of what features are supported and how the
protocol differs from RFC 1459 [2] and RFC 2119 [1], it is
problematic for clients to determine just how a server differs from
these specifications.
A de facto standard emerged in the community, originally implemented
by the Undernet's IRC server software based on the 005 numeric from
DALnet's IRC server. This standard allows the server to advertise to
the client upon connection which extensions to the protocol are
supported. This reply, termed RPL_ISUPPORT, uses the non-standard
numeric 005.
Unfortunately, whilst the numeric itself has become a de-facto
standard, differences have emerged between the meaning of extensions
advertised. This memo attempts to standardise the format of the
RPL_ISUPPORT numeric, as well as standardising the definition of
extensions given within this numeric.
Hardy, et al. Expires July 2, 2005 [Page 4]
Internet-Draft IRC RPL_ISUPPORT January 2005
2. Problems to be Solved
The IRC protocol is no longer standardised in many aspects. This
means that various IRC daemons support features others do not, and
clients need a reliable method of determining which features a server
supports. The de-facto standard that emerged to counter this has
itself suffered from a lack of standards.
The solution to these problems is to formally define a method for
servers to advertise to clients the features it supports, and to
formally define the features advertised. The client may then rely on
this method for reliably determining what features a server supports.
Hardy, et al. Expires July 2, 2005 [Page 5]
Internet-Draft IRC RPL_ISUPPORT January 2005
3. The RPL_ISUPPORT numeric
The extension for informing clients about available features is
implemented by the addition of one numeric, RPL_ISUPPORT, which
contains a list of features supported by the server. Clients SHOULD
NOT assume a server supports a feature unless it has been advertised
in RPL_ISUPPORT.
In ABNF [4] notation:
isupport = [ ":" servername SP ] "005" SP nick SP
1*13( token SP ) ":are supported by this server"
token = *1"-" parameter / parameter *1( "=" value )
parameter = 1*20letter
value = *letpun
letter = ALPHA / DIGIT
punct = %d33-47 / %d58-64 / %d91-96 / %d123-126
letpun = letter / punct
where SP is as designated in Appendix A of RFC 2234 [4], and
servername and nick are as designated in section 2.3.1 of RFC 1459
[2]. As with other local numerics, when RPL_ISUPPORT is delivered
remotely, it MUST be converted into a "105" numeric before delivery
to the client.
A token is of the form "-PARAMETER", "PARAMETER" or
"PARAMETER=VALUE". A server MAY send an empty value field and a
parameter MAY have a default value. A server MUST send the parameter
in upper-case text. Unless otherwise stated, when a parameter
contains a value, the value MUST be treated as being case sensitive.
The value MAY contain multiple fields, if this is the case the fields
MUST be delimited with a comma character (',').
Due to the increasingly modular nature of IRC server software, it is
possible that the status of features previously advertised to clients
in RPL_ISUPPORT can change. When this happens, a server SHOULD
reissue the RPL_ISUPPORT numeric with the relevant parameters that
have changed. If a feature becomes unavailable, the server MUST
prefix the parameter with the dash character ('-') when issuing the
updated RPL_ISUPPORT.
As RFC 1459 [2] limits the maximum parameters of any reply to 15, the
maximum amount of extensions that may be advertised is 13. To
counter this, a server MAY issue multiple RPL_ISUPPORT numerics. A
server MUST issue the RPL_ISUPPORT numeric after client registration
has completed. It MUST be issued after the RPL_WELCOME (XXX -
reference?) welcome and MUST be issued before any further commands
Hardy, et al. Expires July 2, 2005 [Page 6]
Internet-Draft IRC RPL_ISUPPORT January 2005
from the client are processed.
Hardy, et al. Expires July 2, 2005 [Page 7]
Internet-Draft IRC RPL_ISUPPORT January 2005
4. Parameters
Servers MAY send parameters that are not covered in this
specification.
4.1 CASEMAPPING
CASEMAPPING=string
The CASEMAPPING parameter is used to indicate what method is used by
the server to compare equality of case-insensitive strings. Possible
values are:
o "ascii": The ASCII characters 97 to 122 (decimal) are defined as
the lower-case characters of ASCII 65 to 90 (decimal). No other
character equivalency is defined.
o "rfc1459": The ASCII characters 97 to 126 (decimal) are defined as
the lower-case characters of ASCII 65 to 94 (decimal). No other
character equivalency is defined.
o "strict-rfc1459": The ASCII characters 97 to 125 (decimal) are
defined as the lower-case characters of ASCII 65 to 93 (decimal).
no other character equivalency is defined.
The value MUST be specified. Whilst RFC 1459 [2] defines character
equivalency in terms of "strict-rfc1459" encoding, this is believed
to be a mistake as the majority of IRC server implementations treat
character equivalency in terms of "rfc1459" encoding with the tilde
character ('~') and caret character ('^') being equivalent.
An example CASEMAPPING token:
CASEMAPPING=rfc1459
4.2 CHANLIMIT
CHANLIMIT=prefix:number[,prefix:number[,...]]
The CHANLIMIT parameter is used to indicate the maximum amount of
channels that a client may join. The value is a series of
"prefix:number" pairs, where "prefix" refers to one or more prefix
characters defined in the PREFIX (Section 4.15) token, and "number"
indicates how many channels of the given type combined may be joined.
The number parameter MAY be omitted if no limit is placed on the
number of channels.
A client SHOULD NOT make any assumptions about how many channels
other clients may join based on the CHANLIMIT parameter.
Hardy, et al. Expires July 2, 2005 [Page 8]
Internet-Draft IRC RPL_ISUPPORT January 2005
An example CHANLIMIT token:
CHANLIMIT=#+:25,&:
Indicates that a client may join up to 25 channels with the prefix
'#' and '+', and an unlimited amount of channels with the '&' prefix.
4.3 CHANMODES
CHANMODES=A,B,C,D
The CHANMODES parameter is used to indicate the channel modes
available and the arguments they take. There are four categories of
modes, defined as follows:
o Type A: Modes that add or remove an address to or from a list.
These modes MUST always have a parameter when sent from the server
to a client. A client MAY issue the mode without an argument to
obtain the current contents of the list.
o Type B: Modes that change a setting on a channel. These modes
MUST always have a parameter.
o Type C: Modes that change a setting on a channel. These modes
MUST have a parameter when being set, and MUST NOT have a
parameter when being unset.
o Type D: Modes that change a setting on a channel. These modes
MUST NOT have a parameter.
To allow for future extensions, a server MAY send additional types,
delimeted by the comma character (','). The behaviour of any
additional types is undefined.
The IRC server MUST NOT list modes in the CHANMODES parameter that
are contained within the PREFIX (Section 4.15) parameter. However,
for completeness, modes within the PREFIX (Section 4.15) parameter
may be treated as type B modes.
An example CHANMODES token:
CHANMODES=b,k,l,imnpst
4.4 CHANNELLEN
CHANNELLEN=number
The CHANNELLEN parameter specifies the maximum length of a channel
name that a client may join. A client elsewhere on the network MAY
join a channel with a name length of higher value. The value MUST be
specified and MUST be numeric.
Hardy, et al. Expires July 2, 2005 [Page 9]
Internet-Draft IRC RPL_ISUPPORT January 2005
An example CHANNELLEN token:
CHANNELLEN=50
Limits the length of a channel name that a user may join to 50
characters.
4.5 CHANTYPES
CHANTYPES=[string]
Special characters used as prefixes are reserved to differentiate
channels from other namespaces within the IRC protocol. The
CHANTYPES parameter specifies these characters.
The value is OPTIONAL and when is not specified indicates that no
channel types are supported.
An example CHANTYPES token:
CHANTYPES=&#
Denotes the ampersand ('&') and hash ('#') characters as channel
prefixes.
4.6 CNOTICE
CNOTICE
The CNOTICE parameter indicates that the server supports the
"CNOTICE" command. An extension for the NOTICE command, as defined
in RFC 1459 [2] section 4.4.2, it allows users with a specific status
in a channel to issue a NOTICE command to a user within that channel,
free of certain restrictions a server MAY apply to NOTICE.
The CNOTICE parameter MUST NOT be specified with a value.
An example CNOTICE token:
CNOTICE
4.7 CPRIVMSG
CPRIVMSG
The CPRIVMSG parameter indicates that the server supports the
"CPRIVMSG" command. An extension for the PRIVMSG command, as defined
in RFC 1459 [2] section 4.4.1, it allows users with a specific status
in a channel to issue a PRIVMSG command to a user within that
channel, free of certain restrictions a server MAY apply to PRIVMSG.
The CPRIVMSG parameter MUST NOT be specified with a value.
Hardy, et al. Expires July 2, 2005 [Page 10]
Internet-Draft IRC RPL_ISUPPORT January 2005
An example CPRIVMSG token:
CPRIVMSG
4.8 ELIST
ELIST=string
The ELIST parameter indicates that the server supports search
extensions to the LIST command. The value is required, and is a
non-delimited set of letters which each denote an extension. The
following extensions, which a client MUST treat as being case
insensitive are defined:
o C: Searching based on creation time, via the "C<val" and "C>val"
modifiers to search for a channel creation time that is lower or
higher than val respectively.
o M: Searching based on mask.
o N: Searching based on !mask.
o P: To explain
o T: Searching based on topic time, via the "T<val" and "T>val"
modifiers to search for a topic time that is lower or higher than
val respectively.
o U: Searching based on user count within the channel, via the
"<val" and ">val" modifiers to search for a channel that has less
than or more than val users respectively.
An example ELIST token:
ELIST=CMNTU
4.9 EXCEPTS
EXCEPTS[=letter]
The EXCEPTS parameter indicates that the server supports "ban
exceptions", as defined in RFC 2811 [5] section 4.3.1. The value is
OPTIONAL and when is not specified indicates that that the letter 'e'
is used as the channel mode for ban exceptions. When the value is
specified, it indicates the letter which is used for ban exceptions.
An example EXCEPTS token:
EXCEPTS
Hardy, et al. Expires July 2, 2005 [Page 11]
Internet-Draft IRC RPL_ISUPPORT January 2005
4.10 INVEX
INVEX[=letter]
The INVEX parameter indicates that the server supports "invite
exceptions", as defined in RFC 2811 [5] section 4.3.2. The value is
OPTIONAL and when is not specified indicates that the letter 'I' is
used as the channel mode for invite exceptions. When the value is
specified, it indicates the letter which is used for invite
exceptions.
An example INVEX token:
INVEX
4.11 MAXLIST
MAXLIST=mode:number[,mode:number[,...]]
The MAXLIST parameter limits how many "variable" modes of type A that
have been defined in the CHANMODES (Section 4.3) token a client may
set in total on a channel. The value MUST be specified and is a set
of "mode:number" pairs, where "mode" refers to a type A mode defined
in the CHANMODES (Section 4.3) token and "number" indicates how many
of the given modes combined a client may issue on a channel.
A client MUST NOT make any assumptions about how many of the given
modes may actually exist on the channel. The limit applies only to
the client setting new modes of the given types.
Example MAXLIST tokens:
MAXLIST=beI:25
Indicates that a client may set up to a total of 25 of a combination
of "+b", "+e" and "+I" modes.
MAXLIST=b:25,eI:50
Indicates that a client may set up to a total of 25 "+b" modes and up
to a total of 50 of a combination of "+e" and "+I" modes.
4.12 MODES
MODES=[number]
The MODES parameter limits how many "variable" modes may be set on a
channel by a single MODE command from a client. A "variable" mode is
defined as being type A, B and C as defined for the CHANMODES
(Section 4.3) parameter, and the channel modes specified in the
PREFIX (Section 4.15) parameter.
A client SHOULD NOT issue more "variable" modes than this in a single
Hardy, et al. Expires July 2, 2005 [Page 12]
Internet-Draft IRC RPL_ISUPPORT January 2005
MODE command. A server MAY however issue more "variable" modes than
this value in a single MODE command. The value is OPTIONAL and when
is not specified indicates that no limit is placed upon "variable"
modes. The value, if specified, MUST be numeric.
An example MODES token:
MODES=3
Limits the number of "variable" modes from a client to the server to
3 per MODE command.
4.13 NETWORK
NETWORK=string
The NETWORK parameter is for informational purposes only and defines
the name of the IRC network that the client is connected to. The
value MUST be specified. A client SHOULD NOT use the value to make
assumptions about supported features on the server.
An example NETWORK token:
NETWORK=EFnet
Indicates the client is connected to the EFnet IRC network.
4.14 NICKLEN
NICKLEN=number
The NICKLEN parameter specifies the maximum length of a nickname that
a client can use. A client elsewhere on the network MAY use a nick
length of higher value. The value MUST be specified and MUST be
numeric.
An example NICKLEN token:
NICKLEN=9
Limits the length of a nickname to 9 characters
4.15 PREFIX
PREFIX=[(modes)prefixes]
Within channels, clients can have various different statuses, denoted
by single character "prefixes". The PREFIX parameter specifies these
prefixes and the channel mode character that it is mapped to. There
is a one-to-one mapping between prefixes and channel modes. The
prefixes are in descending order, from the prefix that gives the most
privileges to the prefix that gives the least.
The value is OPTIONAL and when it is not specified indicates that no
Hardy, et al. Expires July 2, 2005 [Page 13]
Internet-Draft IRC RPL_ISUPPORT January 2005
prefixes are supported.
An example PREFIX token:
PREFIX=(ov)@+
Denotes the at character ('@') as mapping to the channel mode denoted
by the letter 'o', and the plus character ('+') as mapping to the
channel mode denoted by the letter 'v'.
4.16 SAFELIST
SAFELIST
The SAFELIST parameter indicates that the client may request a "LIST"
command from the server, without being disconnected by the large
volume of data the LIST command generates. The SAFELIST parameter
MUST NOT be specified with a value.
An example SAFELIST token:
SAFELIST
4.17 SILENCE
SILENCE=number
The SILENCE parameter indicates the maximum number of entries a user
may have in their silence list. The value is OPTIONAL and if it is
not specified indicates SILENCE support is not available.
Whilst a formal definition of the SILENCE command is outside the
scope of this document, it is generally a list of masks of equivalent
form to those defined as type A in the CHANMODES (Section 4.3)
parameter. Any messages, as defined in RFC 2812 [3] section 3.3,
that originate from another client matching the given mask, with a
destination of the client itself will be dropped by the server.
An example SILENCE token:
SILENCE=15
Indicates a client may have upto 15 masks in their silence list.
4.18 STATUSMSG
STATUSMSG=string
The STATUSMSG parameter indicates that the server supports a method
for the client to send a message via the NOTICE command to those
people on a channel with the specified status.
The value MUST be specified and MUST be a non-delimited list of
Hardy, et al. Expires July 2, 2005 [Page 14]
Internet-Draft IRC RPL_ISUPPORT January 2005
prefixes that have been defined in the PREFIX (Section 4.15)
parameter. The server MUST NOT advertise a character in STATUSMSG
which is also present in CHANTYPES (Section 4.5).
An example STATUSMSG token:
STATUSMSG=@+
Presuming the hash character ('#') is defined within the CHANTYPES
(Section 4.5) parameter, allows the client to send a NOTICE command
to "@#channel" and "+#channel".
4.19 TARGMAX
TARGMAX=[cmd:number,cmd:number,...]
Certain commands from a client MAY contain multiple targets,
delimited by a comma character (','). The TARGMAX parameter defines
the maximum number of targets allowed for commands which accept
multiple targets. The value is OPTIONAL and is a set of "cmd:number"
pairs, where "cmd" refers to a command the client MAY send to the
server, and "number" refers to the maximum targets for this command.
A client MUST treat the "cmd" field as case insensitive.
If the number is not specified for a particular command, then the
command does not have a limit on the number of targets. The server
MUST specify all commands available to the user which support
multiple targets.
If the TARGMAX parameter is not advertised, or a value is not sent
then a client SHOULD assume that no commands except the "JOIN" and
"PART" commands accept multiple parameters.
An example TARGMAX token:
TARGMAX=PRIVMSG:3,WHOIS:1,JOIN:
Indicates that a client could issue 3 targets to a PRIVMSG command, 1
target to a WHOIS command and an unlimited amount of targets to a
JOIN command.
4.20 TOPICLEN
TOPICLEN=number
The TOPICLEN parameter specifies the maximum length of a topic,
defined in RFC 1459 [2] section 4.2.4 that a client may set on a
channel. A channel on the network MAY have a topic with a longer
length. The value MUST be specified and MUST be numeric.
Hardy, et al. Expires July 2, 2005 [Page 15]
Internet-Draft IRC RPL_ISUPPORT January 2005
An example TOPICLEN token:
TOPICLEN=120
Limits the length of a topic to 120 characters.
4.21 WATCH
WATCH=number
The WATCH parameter indicates the maximum number of nicknames a user
may have in their watch list. The value MUST be specified.
Whilst a formal definition of the WATCH command is outside the scope
of this document, it is generally used a method for clients to have
the server notify them when a given nickname joins or leaves the
network. It is designed to replace repetitive use by clients of the
ISON command, as defined in RFC 1459 [2] section 5.8.
An example WATCH token:
WATCH=100
Indicates that a client may have upto 100 nicks in their watch list.
Hardy, et al. Expires July 2, 2005 [Page 16]
Internet-Draft IRC RPL_ISUPPORT January 2005
5. Differences to existing implementations
A number of differences exist between this specification and existing
implementations in current IRC server software.
5.1 Conflicts with RFC2812
RFC 2812 [3] section 5.1, defines a numeric reply "RPL_BOUNCE" with
the associated numeric "005". This conflicts with the numeric
defined within this document for RPL_ISUPPORT. As RFC 2812 [3] is an
Informational RFC and 005 has been widely adopted as the de-facto
standard numeric for RPL_ISUPPORT, this is not seen as problematic.
Moreover, the only server implementation known to implement RFC 2812
[3] moved the RPL_BOUNCE numeric to 010 and adopted the RPL_ISUPPORT
numeric as 005.
5.2 Traditional EXCEPTS/INVEX usage
The EXCEPTS (Section 4.9) and INVEX (Section 4.10) parameters
traditionally take no argument. Whilst they indicate the presence of
these features on the server, they rely on these features using the
+e and +I channel modes respectively. The argument value described
provides extra flexibility whilst retaining backwards compatibility.
5.3 MAXBANS
The MAXBANS parameter was replaced by the MAXLIST (Section 4.11)
parameter. MAXBANS was considered non-useful, because of its
ambiguous meaning; two of the largest IRC networks for example could
not agree whether "MAXBANS=n" was equivalent to "MAXLIST=beI:n" or
"MAXLIST=b:n,e:n,I:n". MAXLIST is also considered considerably more
flexible and can more accurately define the servers behaviour.
5.4 MAXCHANNELS
The MAXCHANNELS parameter was replaced by the CHANLIMIT (Section 4.2)
parameter. Some IRC server implementations did not apply any limits
to server-local "&" channels, the MAXCHANNELS parameter did not
reflect this and so the CHANLIMIT (Section 4.2) parameter was
introduced to replace MAXCHANNELS, as it can more accurately define
the server implementation.
5.5 MAXTARGETS
The MAXTARGETS parameter was replaced by the TARGMAX (Section 4.19)
parameter. As which commands MAXTARGETS applied to is unclear and
different target limits can often apply to different commands, it was
believed the TARGMAX parameter could more accurately define which
Hardy, et al. Expires July 2, 2005 [Page 17]
Internet-Draft IRC RPL_ISUPPORT January 2005
commands may contain multiple targets.
5.6 WALLCHOPS
The WALLCHOPS parameter was replaced by the STATUSMSG (Section 4.18)
parameter. It is believed the STATUSMSG (Section 4.18) parameter is
more flexible. Some IRC server implementations also implemented a
"WALLCHOPS" command, and it was unclear whether the parameter
indicated support for this command or not. This behaviour is still
unclear.
Hardy, et al. Expires July 2, 2005 [Page 18]
Internet-Draft IRC RPL_ISUPPORT January 2005
6. IANA Considerations
This memo does not raise any IANA considerations.
Hardy, et al. Expires July 2, 2005 [Page 19]
Internet-Draft IRC RPL_ISUPPORT January 2005
7. Security Considerations
This memo does not raise any security considerations.
Hardy, et al. Expires July 2, 2005 [Page 20]
Internet-Draft IRC RPL_ISUPPORT January 2005
8. Acknowledgments
The authors gratefully acknowledges the contributions of Bill Fenner
("fenestro"), Perry Lorier ("Isomer"), Kurt Roeckx ("Q") and John
Midgley ("CrazyEddy") in the preparation of this document.
This document is heavily based on a previous document entitled "The
005 numeric".
9 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC
1459, May 1993.
[3] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
April 2000.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[5] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811,
April 2000.
[6] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
Authors' Addresses
Lee Hardy
ircd-ratbox development team
EMail: lee@leeh.co.uk
URI: http://www.leeh.co.uk
Edward Brocklesby
ircd-ratbox development team
57 Williamson Way
Oxford OX4 4TU
UK
Hardy, et al. Expires July 2, 2005 [Page 21]
Internet-Draft IRC RPL_ISUPPORT January 2005
Kevin L. Mitchell
Undernet IRC Network
38 Eighth St., Apt. 7
Cambridge, Massachusetts 02141
US
Phone: +1-617-230-1021
EMail: klmitch@mit.edu
URI: http://www.mit.edu/~klmitch/
Hardy, et al. Expires July 2, 2005 [Page 22]
Internet-Draft IRC RPL_ISUPPORT January 2005
Appendix A. Examples
The following examples show various RPL_ISUPPORT messages from
various IRC server software.
Example network
:server 005 nickname foo
Hardy, et al. Expires July 2, 2005 [Page 23]
Internet-Draft IRC RPL_ISUPPORT January 2005
Appendix B. ABNF Description of Capabilities
This section summarizes the ABNF [4] description of the RPL_ISUPPORT
extension.
Hardy, et al. Expires July 2, 2005 [Page 24]
Internet-Draft IRC RPL_ISUPPORT January 2005
Appendix C. ChangeLog
Note to RFC Editor: This section may be removed on publication as an
RFC.
Here is a log of changes to this document:
2005-01-28 LH Initial draft written, borrowing heavily from the old
i-d by Edward Brocklesby.
2005-01-29 LH
* Fleshed out information on CPRIVMSG, CNOTICE, WATCH and SILENCE
tokens.
* Added CHANNELLEN token.
* Added TOPICLEN token.
* Added TARGMAX token.
2005-02-02 LH
* Documented differences to traditional EXCEPTS/INVEX usage.
* Added the old WALLCHOPS token under differences.
* Added the old MAXBANS token under differences.
* Added the old MAXTARGETS token under differences.
* Added the old MAXCHANNELS token under differences.
2005-02-03 LH
* "Add r remote" to "Add or remove" in CHANMODES.
* Make SILENCE= indicate its unsupported.
* Remove some stuff from STATUSMSG thats beyond the scope of this
document.
* Clarify ETRACE modifiers.
Hardy, et al. Expires July 2, 2005 [Page 25]
Internet-Draft IRC RPL_ISUPPORT January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hardy, et al. Expires July 2, 2005 [Page 26]