view release on metacpan or  search on metacpan

docs/rfc1459.html  view on Meta::CPAN

   Parameters: [<Quit message>]

   A client session is ended with a quit message.  The server must close
   the connection to a client which sends a QUIT message. If a "Quit
   Message" is given, this will be sent instead of the default message,
   the nickname.

   When netsplits (disconnecting of two servers) occur, the quit message

   is composed of the names of two servers involved, separated by a
   space.  The first name is that of the server which is still connected
   and the second name is that of the server that has become
   disconnected.

   If, for some other reason, a client connection is closed without  the
   client  issuing  a  QUIT  command  (e.g.  client  dies and EOF occurs
   on socket), the server is required to fill in the quit  message  with
   some sort  of  message  reflecting the nature of the event which
   caused it to happen.

   Numeric Replies:

           None.

   Examples:

   QUIT :Gone to have lunch        ; Preferred message format.

4.1.7 Server quit message

      Command: SQUIT
   Parameters: <server> <comment>

   The SQUIT message is needed to tell about quitting or dead servers.
   If a server wishes to break the connection to another server it must
   send a SQUIT message to the other server, using the the name of the
   other server as the server parameter, which then closes its
   connection to the quitting server.

   This command is also available operators to help keep a network of
   IRC servers connected in an orderly fashion.  Operators may also
   issue an SQUIT message for a remote server connection.  In this case,
   the SQUIT must be parsed by each server inbetween the operator and
   the remote server, updating the view of the network held by each
   server as explained below.

   The <comment> should be supplied by all operators who execute a SQUIT
   for a remote server (that is not connected to the server they are
   currently on) so that other operators are aware for the reason of
   this action.  The <comment> is also filled in by servers which may
   place an error or similar message here.

   Both of the servers which are on either side of the connection being
   closed are required to to send out a SQUIT message (to all its other
   server connections) for all other servers which are considered to be
   behind that link.

   Similarly, a QUIT message must be sent to the other connected servers
   rest of the network on behalf of all clients behind that link.  In
   addition to this, all channel members of a channel which lost a
   member due to the split must be sent a QUIT message.

   If a server connection is terminated prematurely (e.g. the server  on
   the  other  end  of  the  link  died),  the  server  which  detects
   this disconnection is required to inform the rest of  the  network
   that  the connection  has  closed  and  fill  in  the comment field
   with something appropriate.

   Numeric replies:

           ERR_NOPRIVILEGES                ERR_NOSUCHSERVER

   Example:

   SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
                                   been terminated because of "Bad Link".

   :Trillian SQUIT cm22.eng.umd.edu :Server out of control
                                    ; message from Trillian to disconnect
                                   "cm22.eng.umd.edu" from the net
                                    because "Server out of control".

4.2 Channel operations

   This group of messages is concerned with manipulating channels, their
   properties (channel modes), and their contents (typically clients).
   In implementing these, a number of race conditions are inevitable
   when clients at opposing ends of a network send commands which will
   ultimately clash.  It is also required that servers keep a nickname
   history to ensure that wherever a <nick> parameter is given, the
   server check its history in case it has recently been changed.

4.2.1 Join message

      Command: JOIN
   Parameters: <channel>{,<channel>} [<key>{,<key>}]

   The JOIN command is used by client to start listening a specific
   channel. Whether or not a client is allowed to join a channel is
   checked only by the server the client is connected to; all other
   servers automatically add the user to the channel when it is received
   from other servers.  The conditions which affect this are as follows:

           1.  the user must be invited if the channel is invite-only;

           2.  the user's nick/username/hostname must not match any
               active bans;

           3.  the correct key (password) must be given if it is set.

   These are discussed in more detail under the MODE command (see
   section 4.2.3 for more details).

   Once a user has joined a channel, they receive notice about all
   commands their server receives which affect the channel.  This
   includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE.  The
   JOIN command needs to be broadcast to all servers so that each server
   knows where to find the users who are on the channel.  This allows
   optimal delivery of PRIVMSG/NOTICE messages to the channel.

   If a JOIN is successful, the user is then sent the channel's topic