[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                      E. Brocklesby
INTERNET-DRAFT                                                  May 2003
Expires: November 2003

                  IRC RPL_ISUPPORT Numeric Definition
                    draft-brocklesby-irc-isupport-02

Status of this Document

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 document is a product of an individual.  Comments are solicited
   and should be addressed to the author.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

     This memo presents a way for the server to unobtrusively advertise
     the ways in which it differs from the IRC (Internet Relay Chat)
     specification defined in RFC 1459 [6]. It is a primary goal to
     implement this in a way which is completely backwards-compatible
     with the original protocol, and also with current non-standard
     implementations of the ISUPPORT numeric.







Brocklesby                                                      [Page 1]


INTERNET-DRAFT           Expires: November 2003                 May 2003


                           Table of Contents


1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . .   2
 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .   2
 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .   2
2. Protocol outline. . . . . . . . . . . . . . . . . . . . . . . . .   2
3. Currently defined parameters. . . . . . . . . . . . . . . . . . .   4
 3.1. PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
 3.2. CHANTYPES. . . . . . . . . . . . . . . . . . . . . . . . . . .   5
 3.3. CHANMODES. . . . . . . . . . . . . . . . . . . . . . . . . . .   5
 3.4. MODES. . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
 3.5. MAXCHANNELS. . . . . . . . . . . . . . . . . . . . . . . . . .   7
 3.6. NICKLEN. . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 3.7. MAXLIST. . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 3.8. NETWORK. . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 3.9. EXCEPTS. . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 3.10. INVEX . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
 3.11. STATUSMSG . . . . . . . . . . . . . . . . . . . . . . . . . .   9
 3.12. CASEMAPPING . . . . . . . . . . . . . . . . . . . . . . . . .   9
 3.13. SAFELIST. . . . . . . . . . . . . . . . . . . . . . . . . . .  10
 3.14. TOPICLEN. . . . . . . . . . . . . . . . . . . . . . . . . . .  10
 3.15. KICKLEN . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
 3.16. CHANNELLEN. . . . . . . . . . . . . . . . . . . . . . . . . .  11
 3.17. CHARSET . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
 3.18. CHIDLEN . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
 3.19. STD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
4. Differences to existing implementations . . . . . . . . . . . . .  13
 4.1. PREFIX parameter without value . . . . . . . . . . . . . . . .  13
 4.2. EXCEPTS and INVEX value argument . . . . . . . . . . . . . . .  13
 4.3. STATUSMSG. . . . . . . . . . . . . . . . . . . . . . . . . . .  13
 4.4. Conflicts with RFC 2812. . . . . . . . . . . . . . . . . . . .  14
 4.5. Default value for CASEMAPPING. . . . . . . . . . . . . . . . .  14
5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . .  14
6. References. . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
 6.1. Normative. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
 6.2. Informative. . . . . . . . . . . . . . . . . . . . . . . . . .  15
7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .  15
8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

1.1.  Terminology

     Original IRC protocol: The original IRC protocol as described in
     RFC 1459 [6].





Brocklesby                                        Section 1.1.  [Page 2]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
     this document are to be interpreted as described in RFC 2119 [1].

     The ABNF syntax used in this document is defined in RFC 2234 [2].

     The term "character" is this document is used to mean an octet, as
     defined in RFC 1459 [6], section 2.2.

1.2.  Motivation

     Since the publication of RFC 1459 [6] in 1993, a number of changes
     and extensions have been made to the IRC protocol.  This has led to
     a problem whereby clients are unable to correctly interpret some
     server replies, because the reply, channel mode, and so on may have
     different meanings on different implementations of the IRC server.
     It is also difficult for the client to ascertain which protocol
     extensions may be available on a specific server.  A de facto
     standard has emerged in the community, originally implemented by
     the Undernet's IRC server software based on the 005 numeric from
     DALnet's IRC server, which allows the server to advertise to the
     client upon connection which protocol extensions it supports.  This
     reply, termed RPL_ISUPPORT, uses the non-standard numeric 005.

     Unfortunately, since there is no standard document describing the
     ISUPPORT numeric, differences have emerged between implementations
     in IRC server software; it is believed that this reduces the
     potential usefulness of the feature.  This memo attempts to
     standardise the format and content of the ISUPPORT method in an
     extensible way, such that IRC clients can use the information
     provided to the maximum extent.

2.  Protocol outline

     The ISUPPORT numeric consists of a series of parameters, each of
     which maps to a protocol extension supported by the IRC server.  A
     parameter may have an associated value, typically a numeric or
     string value, which provides additional information on the
     extension.

     The format of the ISUPPORT numeric is the same as other server
     numeric replies currently used.  A client which does not understand
     the numeric may ignore it; however, it is recommended that IRC
     clients understand ISUPPORT, in order to allow users the full
     benefit of features implemented by the IRC server.  The ABNF
     grammar for the numeric is as follows:





Brocklesby                                          Section 2.  [Page 3]


INTERNET-DRAFT           Expires: November 2003                 May 2003


       isupport = ":" servername SP "005" SP nickname SP
               1*13( token SP ) ":are supported by this server"

       token = *1"-" parameter / parameter *1( "=" value )
       parameter = 1*20letter
       value = *20letpun
       letter = ALPHA / DIGIT
       punct = %d33-47 / %d58-64 / %d91-96 / %d123-126
       letpun = letter / punct

     The format of the postfix descriptive text is not fixed, and may be
     any string subject to the requirements of RFC 1459 [6] regarding
     numeric replies.  Servername and nickname are as defined in RFC
     1459 [6].

     The server MUST send the parameter in upper-case text, and it is
     RECOMMENDED that clients treat parameter in a case-insensitive
     manner.  Unless otherwise stated, the parameter's value is case
     sensitive.

     RFC 1459 [6] defines a maximum of 15 parameters to any reply,
     including the nickname and the text; therefore, only 13
     capabilities are possible per reply.

     In order to allow flexibility in the protocol, and future
     expansion, the server may send more than one ISUPPORT reply per
     connection.  It is RECOMMENDED that consecutive ISUPPORT replies
     are sent adjacent to each other.  The client MUST support receiving
     multiple ISUPPORT replies, and should merge them to produce the
     final list of supported protocol extensions.  While it is
     recommended that the server attempt to send 13 tokens per line
     before sending multiple replies, this is not required.

     A token is of the form "PARAMETER[=[VALUE]]" or "-PARAMETER".
     Absence of a parameter implies that the default value should be
     used; unless otherwise specified in the definition of that token,
     this default value is undefined.  Except as explicitly stated in
     its definition, a parameter should not be sent unless it changes
     this default value, or the default value is vague, badly defined,
     or differs between IRC server implementations.  When in doubt, the
     parameter should be sent.  If a parameter which accepts a VALUE
     specifier is given without any VALUE parameter, it should be
     ignored by the client and the default value used as if it was not
     specified, except as explicitly stated below.  A token with a null
     value, of the form "TOKEN=", should be treated as having an empty
     value specifier.  If the parameter does not allow an empty value
     specifier, the client should ignore the entire token, as if it was
     not specified.



Brocklesby                                          Section 2.  [Page 4]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     The form "-PARAMETER" is used to negate a previously specified
     parameter; that is, revert to the behaviour that would occur if the
     parameter had not been specified. This is intended to allow servers
     to change their capabilities without disconnecting clients. Both
     parameter with and without a value argument may be negated;
     however, the value argument should not be given.  It is not
     required to negate a parameter in order to change its value, the
     server should merely re-advertise the parameter with the new value.

     The server may negate tokens which have not been previously
     advertised to the client; in this case, the client should ignore
     the negation.

     The server may not advertise and negate the same parameter in one
     ISUPPORT numeric reply, nor may it advertise the same parameter
     with different value specifiers.  The client's behaviour in this
     case is undefined.

3.  Currently defined parameters

     A number of parameters are currently used in the IRC community, and
     it is believed to be beneficial to standardise these.  They are
     listed below, with relevant information.

     Note that it is intended and expected that future documents will
     update and extend the set of defined parameters; this is not meant
     to be an exhaustive list.

3.1.  PREFIX

     PREFIX=[(modes)prefixes]

     The PREFIX parameter specifies a list of channel status flags (the
     "modes" section) that clients may have on channels, followed by a
     mapping to the equivalent channel status flags ("prefixes"), which
     are used in NAMES and WHO replies.  There is a one to one mapping
     between each mode and prefix; for example, (ab)&* maps the channel
     mode 'a' to the channel status flag '&', and channel mode 'b' to
     the channel status flag '*'.  The order of the modes is from that
     which gives most privileges on the channel, to that which gives the
     least.

     Example: PREFIX=(ohv)@%+ maps channel mode 'o' to status '@', 'h'
          to status '%', and 'v' to status +.

     The default value for PREFIX is "PREFIX=(ov)@+", which corresponds
     to RFC 1459 [6]. It should not be specified if the server provides
     only these modes.  If a server provides ANY additional status



Brocklesby                                        Section 3.1.  [Page 5]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     flags, it should also provide (ov)@+ (assuming they are applicable
     to the server).  The PREFIX parameter may be advertised with a null
     value specifier;
      this indicates that no prefixes are supported by the IRC server.

     Note that PREFIX does NOT specify whether or not the server sends
     multiple prefix characters for a user in NAMES replies.

3.2.  CHANTYPES

     CHANTYPES=chars

     The CHANTYPES parameter specifies the valid characters to begin a
     channel name.


     Example: CHANTYPES=+#& defines that channels names may begin with
          either +, #, or &; for example, #mychannel.

     The default value for CHANTYPES is "CHANTYPES=#&", which
     corresponds to RFC 1459 [6]. It should not be specified if the
     server supports exactly these channel types.  The CHANTYPES token
     requires a non-null value specifier; if no value is given, or it is
     null, the client should ignore the entire token.

3.3.  CHANMODES

     CHANMODES[=A,B,C,D]

     The CHANMODES specifies the modes that may be set on a channel.
     These modes are split into four categories, as follows:

     Type A: Modes that add or remove an address to or from a list.
          These modes always take a parameter when sent by the server to
          a client; when sent by a client, they may be specified without
          a parameter, which requests the server to display the current
          contents of the correspending list on the channel to the
          client.

     Type B: Modes that change a setting on the channel.  These modes
          always take a parameter.

     Type C: Modes that change a setting on the channel.  These modes
          take a parameter only when set; the parameter is absent when
          the mode is removed.

     Type D: Modes that change a setting on the channel.  These modes
          never take a parameter.



Brocklesby                                        Section 3.3.  [Page 6]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     If the server sends any addition types after these 4, the client
     should ignore them; this is intended to allow future extension of
     this token.

     The IRC server should not list modes in CHANMODES which are also
     present in the PREFIX parameter; however, for completeness, modes
     described in PREFIX may be treated as type B modes.

     If the server sends a mode which is missing from both CHANMODES and
     PREFIX, the client should treat it as a type D mode. However, this
     is a protocol violation by the server.


     Example: CHANMODES=b,k,l,imnpst

     The CHANMODES token requires a non-null value specifier; if no
     value is given, or it is null, the client should ignore the entire
     token.  There is no default value for the CHANMODES token.

3.4.  MODES

     MODES=number

     This parameter specifies the maximum number of "variable" modes
     which may by set on a channel by a single MODE command from a
     client.  A "variable" mode is defined as being type A, B and C
     modes as defined for CHANMODES, and channel modes specified in the
     PREFIX parameter.


     Example: MODES=3 indicates that 3 modes may be set with a MODE
          command.

     The default value for the MODES parameter is 3, which corresponds
     to RFC 1459 [6]. The MODES token require a non-null numeric value
     specifier; if no value is given, the value is null, or the value is
     not numeric, the client should ignore the entire token.

3.5.  MAXCHANNELS

     MAXCHANNELS=number

     This parameter specifies the maximum number of channels that a
     client may join.  This should include all types of channels
     available on the server (as indicated by CHANTYPES).






Brocklesby                                        Section 3.5.  [Page 7]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     Example: MAXCHANNELS=10 indicates that a client may join up to 10
          channels.

     It is not specified whether or not MAXCHANNELS applies to 'server
     local' channels.  Note also that clients on other (non-local)
     servers may be on more than this number of channels.

     The default value for the MAXCHANNELS parameter is 10, which
     corresponds to RFC 1459 [6]. The MAXCHANNELS token require a non-
     null numeric value specifier; if no value is given, the value is
     null, or the value is not numeric, the client should ignore the
     entire token.

3.6.  NICKLEN

     NICKLEN=number

     This parameter specifies the maximum nickname length that any
     client on the network may have.


     Example: NICKLEN=9 indicates that clients may have nicknames up to
          9 characters in length.

     The NICKLEN token require a non-null numeric value specifier; if no
     value is given, the value is null, or the value is not numeric, the
     client should ignore the entire token.  The default value for
     NICKLEN is 9, which corresponds to RFC 1459 [6].

3.7.  MAXLIST

     MAXLIST=mode:num[,mode:num,...]

     This parameter specifies the maximum numbers of 'list modes' (for
     example, bans) that a client may set on a channel at one time.
     Note that this should only be interpreted as applying to new modes
     which are set by clients -- it should not be used to infer the
     maximum length of any mode lists returned by the server.

     The parameter is a series of mode-number pairs, each of which
     species one or more type A modes, along with the maximum size of
     the associated list for those modes.  Modes which are specified in
     the same pair share the same maximum size; so for example, given
     "b:25,eI:50", it would be possible to set up to 25 "+b" modes, and
     up to 50 of a combination of "+e" and "+I" modes (for example 30
     "+e" and 20 "+I" modes, making up a total of 50).





Brocklesby                                        Section 3.7.  [Page 8]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     Example: MAXLIST=b:25 indicates that 25 bans may be set on a
          channel at one time.

     The MAXLIST token requires a non-null value specifier; if no value
     is given, or it is null, the client should ignore the entire token.
     There is no default value for the MAXLIST token.

3.8.  NETWORK

     NETWORK=name

     The NETWORK parameter defines the name of the IRC network that the
     client is connected to.


     Example: NETWORK=EFnet indicates that the client is connected to
          the EFnet IRC network.

     Note that this parameter is intended only for user display
     purposes; the client SHOULD NOT assume further capabilities or
     features of the IRC server based on the value of the NETWORK
     parameter.  The NETWORK token requires a non-null value specifier;
     if no value is given, or it is null, the client should ignore the
     entire token.  There is no default value for the NETWORK token.

3.9.  EXCEPTS

     EXCEPTS[=modechar]

     The EXCEPTS parameter indicates that the server supports "ban
     exceptions" (channel mode +e), as defined in RFC 2811 [3], sections
     4.3.1.  The optional value argument to EXCEPTS indicates which
     channel mode is used for ban exceptions. If no value is specified,
     or it is null, it is assumed that mode +e is used.

3.10.  INVEX

     INVEX[=modechar]

     The INVEX parameter indicates that the server supports "invite
     exceptions", as defined in RFC 2811 [3], section 4.3.2.  The
     optional value argument to INVEX indicates which channel mode is
     used for invite exceptions.  If no value is specified or the value
     is null, it is assumed that mode +I is used.  If the value is
     greater than one character in length, or does not correspond to a
     valid mode, the client should ignore the entire token.





Brocklesby                                       Section 3.10.  [Page 9]


INTERNET-DRAFT           Expires: November 2003                 May 2003


3.11.  STATUSMSG

     STATUSMSG=string

     The server supports a method of sending a notice message to only
     those people on a channel with the specified status.  This is done
     via a NOTICE command, with the channel prefixed by the desired
     status flag as the target; for example:

     NOTICE @#channel :Hi there

     The server should deliver the message to all users on the specified
     channel with equal or higher status on the channel as the status
     flag indicates; for example, a message to "+#channel" would deliver
     the message to all users with voice and channel operator privileges
     on #channel, assuming that the server supported the PREFIX value
     (ov)@+.

     The required value argument to STATUSMSG indicates which prefixes
     (from the PREFIX parameter) are valid status values for use in
     NOTICE commands.

     The STATUSMSG token requires a non-null value specifier; if no
     value is given, or it is null, the client should ignore the entire
     token.

3.12.  CASEMAPPING

     CASEMAPPING=string

     The CASEMAPPING parameter allows the server to specify which method
     it uses to compare case equality.  Possible values are:

     "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.

     "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.

     "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.

     Note that the only difference between "rfc1459" and "strict-
     rfc1459" is that the characters "~" and "^" are not considered
     equivalent in the "strict-rfc1459" encoding.  This is believed to



Brocklesby                                      Section 3.12.  [Page 10]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     be an mistake in the specification of character equivalency in RFC
     1459 [6]; the majority of IRC server implementations known to the
     author treat these characters as equivalent (however, see section
     4.5).

     The CASEMAPPING token requires a non-null value specifier; if no
     value is given, or it is null, the client should ignore the entire
     token.

     The default value for CASEMAPPING is "rfc1459".  While this differs
     from the historical definition in RFC 1459 [6], it is believed to
     reflect current IRC server implementations, and is as such more
     useful.

3.13.  SAFELIST

     SAFELIST

     The SAFELIST parameter indicates that the client may request a
     "LIST" command from the server, without being disconnected due to
     the large amount of data generated by the command.

     The SAFELIST token must not be specified with a value; if a value
     is given, the client should treat the token as if it was specified
     without a value.

3.14.  TOPICLEN

     TOPICLEN=number

     The TOPICLEN parameter specifies the maximum length of the topic
     specified in the TOPIC command for a channel.  Note that it only
     specifies the length of topic that may be set -- the server is free
     to return topics longer than this length to the client.

     The TOPICLEN token require a non-null numeric value specifier; if
     no value is given, the value is null, or the value is not numeric,
     the client should ignore the entire token.  There is no default
     value for the TOPICLEN token.

3.15.  KICKLEN

     KICKLEN=number

     The KICKLEN parameter specifies the maximum length of a KICK
     message that a client may use.  Note that it only specifies the
     length the client should send to the server -- the server may send
     KICK messages with a length longer than this value.



Brocklesby                                      Section 3.15.  [Page 11]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     The KICKLEN token require a non-null numeric value specifier; if no
     value is given, the value is null, or the value is not numeric, the
     client should ignore the entire token.  There is no default value
     for the KICKLEN token.

3.16.  CHANNELLEN

     CHANNELLEN=number

     The CHANNELLEN parameter specifies the maximum length of the name
     of a channel that may be created by a client.  The server may make
     known to the client a channel with a name longer than that
     specified in this value -- that is, the client may not depend on a
     channel's name never being longer than this.

     The CHANNELLEN token require a non-null numeric value specifier; if
     no value is given, the value is null, or the value is not numeric,
     the client should ignore the entire token.  The default value for
     CHANNELLEN is 200; this corresponds to RFC 1459 [6].

3.17.  CHARSET

     CHARSET=string

     The CHARSET parameter is used to indicate which regional language
     encoding is used in server replies (numerics) and NOTICE commands
     to the user.  It does not apply to nicknames, channel names, client
     to client messages or any other text.

     Possible values for the CHARSET parameter are:

          "ascii": All server messages will be sent in 7-bit US-ASCII
               format.

          "utf-8": All server messages will be sent in Unicode UTF-8
               encoding.

          "iso_xxxx_x": All server messages will be sent in the
               specified ISO regional language encoding; for example
               "iso_8859_15".

     Any other value corresponding to a character set defined in the
     IANA Character Set Registrations document may also be sent.

     The value argument for the CHARSET parameter is case-insensitive
     within the US-ASCII character set.





Brocklesby                                      Section 3.17.  [Page 12]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     The CHARSET token requires a non-null value specifier; if no value
     is given, or it is null, the client should ignore the entire token.
     The default value for the CHARSET parameter is "ascii".

3.18.  CHIDLEN

     CHIDLEN=number

     The CHIDLEN parameter specifies the length of the "ID" portion of
     "safe" channels specified in RFC 2811 [3].


     Example: CHIDLEN=5 means the client should expect IDs which are 5
          characters in length; for example "!JNB4Sircd", where "JNB4S"
          is the ID and "ircd" is the channel's short name.

     The CHIDLEN token require a non-null numeric value specifier; if no
     value is given, the value is null, or the value is not numeric, the
     client should ignore the entire token.  The default value for
     CHIDLEN is 5; this corresponds to RFC 2811 [3].

3.19.  STD

     STD=version[,version[,...]]

     The STD parameter indicates which form(s) of the ISUPPORT numeric
     are used by the server.  Currently, one only possible value is
     defined; that is "i-d", which refers to this document.

     The STD parameter is intended to be extensible, so that if later
     standards emerge which update this document, the server may be able
     to advertise this.  The "version" string is free-form subject to
     the requirements in section 2, however, protocol updates defined in
     RFCs should be named "rfcxxxx", where "xxxx" is the relevant RFC
     number.

     A server may support any number of STD versions. However, in order
     to reduce space being needlessly wasted by this parameter, care
     should be taken before adding another version. It is expected that
     most new features may be advertised simply by additional
     parameters, in which case a new version string is not required.

     The STD token requires a non-null value specifier; if no value is
     given, or it is null, the client should ignore the entire token.
     The default value for the STD parameter is none; that is, no
     standardised ISUPPORT is available.





Brocklesby                                      Section 3.19.  [Page 13]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     Note that it is expected that the "i-d" string will be replaced
     with an equivalent "rfcxxxx" parameter if this document is
     standardised.

4.  Differences to existing implementations

     A number of differences exist between the ISUPPORT defined in this
     document and traditional implementations of the ISUPPORT numeric.

4.1.  PREFIX parameter without value

     The PREFIX parameter is traditionally not sent without a value
     parameter; indeed, the author is not aware of any IRC server
     implementations where this would be appropriate. However, it is
     believed that this support is desired to allow extra flexibility,
     while retaining compatibility with traditional PREFIX
     implementations.

4.2.  EXCEPTS and INVEX value argument

     EXCEPTS and INVEX traditionally take no argument -- while they
     indicate presence of these features on the server, they do not
     specify the channel mode which is associated with these features.
     It is believed that the argument value described here provides
     extra flexibility while retaining backwards compatibility.

4.3.  STATUSMSG

     The STATUSMSG parameter replaces the traditional WALLCHOPS
     parameter used by some current implementations.  It is believed
     that the name STATUSMSG better reflects the functionality; since
     the argument to STATUSMSG is not optional, it would break backwards
     compatibility to use the name WALLCHOPS. It was not considered
     beneficial to allow a STATUSMSG flag without a value.

4.4.  Conflicts with RFC 2812

     RFC 2812 [4], section 5.1, defines a numeric reply "RPL_BOUNCE",
     with the associated number "005".  While this conflicts with the
     ISUPPORT numeric, it is considered that ISUPPORT has received much
     more widespread support, and is the de facto standard for use of
     the 005 numeric.  It is believed that the use of 005 as RPL_BOUNCE
     is being deprecated.

     RFC 2812 [4] is an Informational RFC and does not not specify an
     Internet standard.





Brocklesby                                       Section 4.4.  [Page 14]


INTERNET-DRAFT           Expires: November 2003                 May 2003


4.5.  Default value for CASEMAPPING

     The default value for CASEMAPPING ("rfc1459") was chosen because it
     reflects the prevailing implementations of the IRC server software
     currently in use. While some IRC servers have moved to the "ascii"
     case mapping, those known to the author indicate this via
     CASEMAPPING=ascii; therefore this is not believed to introduce any
     compatibility problems.

5.  Acknowledgements

     The author gratefully acknowledges the contributions of Bill
     Fenner, Perry Lorier and Kurt Roeckx in the preparation of this
     document.

     This document is heavily based on a previous document entitled "The
     005 numeric" [5].

6.  References

6.1.  Normative

     [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels", RFC 2119, March 1997.

     [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
          Specifications: ABNF", RFC 2234, November 1997.

     [3] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811,
          April 2000.

     [4] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
          April 2000.

6.2.  Informative

     [5] Roeckx, K., "The 005 numeric", September 2002.

     [6] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC
          1459, May 1993.

7.  Author's Address

     Edward Brocklesby
     57 Williamson Way
     Oxford  OX4 4TU
     UK




Brocklesby                                         Section 7.  [Page 15]


INTERNET-DRAFT           Expires: November 2003                 May 2003


     Phone: +44 1865 452230
     EMail: ejb@lythe.org.uk

8.  Full Copyright Statement

     Copyright (C) The Internet Society (2003). All Rights Reserved.

     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implementation may be prepared, copied,
     published and distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice and this
     paragraph are included on all such copies and derivative works.
     However, this document itself may not be modified in any way, such
     as by removing the copyright notice or references to the Internet
     Society or other Internet organizations, except as needed for the
     purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards process
     must be followed, or as required to translate it into languages
     other than English.

     The limited permissions granted above are perpetual and will not be
     revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS 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.





















Brocklesby                                         Section 8.  [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/