rfc2812.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,794 行 · 第 1/5 页

Network Working Group                                            C. Kalt
Request for Comments: 2812                                    April 2000
Updates: 1459
Category: Informational


                  Internet Relay Chat: Client Protocol

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

IESG NOTE:

   The IRC protocol itself enables several possibilities of transferring
   data between clients, and just like with other transfer mechanisms
   like email, the receiver of the data has to be careful about how the
   data is handled. For more information on security issues with the IRC
   protocol, see for example http://www.irchelp.org/irchelp/security/.

Abstract

   The IRC (Internet Relay Chat) protocol is for use with text based
   conferencing; the simplest client being any socket program capable of
   connecting to the server.

   This document defines the Client Protocol, and assumes that the
   reader is familiar with the IRC Architecture [IRC-ARCH].

Table of Contents

   1.  Labels .....................................................   3
      1.1  Servers ................................................   3
      1.2  Clients ................................................   3
         1.2.1  Users .............................................   4
            1.2.1.1  Operators ....................................   4
         1.2.2  Services ..........................................   4
      1.3  Channels ...............................................   4
   2.  The IRC Client Specification ...............................   5
      2.1  Overview ...............................................   5
      2.2  Character codes ........................................   5
      2.3  Messages ...............................................   5



Kalt                         Informational                      [Page 1]

RFC 2812          Internet Relay Chat: Client Protocol        April 2000


         2.3.1  Message format in Augmented BNF ...................   6
      2.4  Numeric replies ........................................   8
      2.5  Wildcard expressions ...................................   9
   3.  Message Details ............................................   9
      3.1  Connection Registration ................................  10
         3.1.1  Password message ..................................  10
         3.1.2  Nick message ......................................  10
         3.1.3  User message ......................................  11
         3.1.4  Oper message ......................................  12
         3.1.5  User mode message .................................  12
         3.1.6  Service message ...................................  13
         3.1.7  Quit ..............................................  14
         3.1.8  Squit .............................................  15
      3.2  Channel operations .....................................  15
         3.2.1  Join message ......................................  16
         3.2.2  Part message ......................................  17
         3.2.3  Channel mode message ..............................  18
         3.2.4  Topic message .....................................  19
         3.2.5  Names message .....................................  20
         3.2.6  List message ......................................  21
         3.2.7  Invite message ....................................  21
         3.2.8  Kick command ......................................  22
      3.3  Sending messages .......................................  23
         3.3.1  Private messages ..................................  23
         3.3.2  Notice ............................................  24
      3.4  Server queries and commands ............................  25
         3.4.1  Motd message ......................................  25
         3.4.2  Lusers message ....................................  25
         3.4.3  Version message ...................................  26
         3.4.4  Stats message .....................................  26
         3.4.5  Links message .....................................  27
         3.4.6  Time message ......................................  28
         3.4.7  Connect message ...................................  28
         3.4.8  Trace message .....................................  29
         3.4.9  Admin command .....................................  30
         3.4.10 Info command ......................................  31
      3.5  Service Query and Commands .............................  31
         3.5.1  Servlist message ..................................  31
         3.5.2  Squery ............................................  32
      3.6  User based queries .....................................  32
         3.6.1  Who query .........................................  32
         3.6.2  Whois query .......................................  33
         3.6.3  Whowas ............................................  34
      3.7  Miscellaneous messages .................................  34
         3.7.1  Kill message ......................................  35
         3.7.2  Ping message ......................................  36
         3.7.3  Pong message ......................................  37
         3.7.4  Error .............................................  37



Kalt                         Informational                      [Page 2]

RFC 2812          Internet Relay Chat: Client Protocol        April 2000


   4.  Optional features ..........................................  38
      4.1  Away ...................................................  38
      4.2  Rehash message .........................................  39
      4.3  Die message ............................................  39
      4.4  Restart message ........................................  40
      4.5  Summon message .........................................  40
      4.6  Users ..................................................  41
      4.7  Operwall message .......................................  41
      4.8  Userhost message .......................................  42
      4.9  Ison message ...........................................  42
   5.  Replies ....................................................  43
      5.1  Command responses ......................................  43
      5.2  Error Replies ..........................................  53
      5.3  Reserved numerics ......................................  59
   6.  Current implementations ....................................  60
   7.  Current problems ...........................................  60
      7.1  Nicknames ..............................................  60
      7.2  Limitation of wildcards ................................  61
      7.3  Security considerations ................................  61
   8.  Current support and availability ...........................  61
   9.  Acknowledgements ...........................................  61
   10.  References ................................................  62
   11.  Author's Address ..........................................  62
   12.  Full Copyright Statement ..................................  63

1. Labels

   This section defines the identifiers used for the various components
   of the IRC protocol.

1.1 Servers

   Servers are uniquely identified by their name, which has a maximum
   length of sixty three (63) characters.  See the protocol grammar
   rules (section 2.3.1) for what may and may not be used in a server
   name.

1.2 Clients

   For each client all servers MUST have the following information: a
   netwide unique identifier (whose format depends on the type of
   client) and the server which introduced the client.









Kalt                         Informational                      [Page 3]

RFC 2812          Internet Relay Chat: Client Protocol        April 2000


1.2.1 Users

   Each user is distinguished from other users by a unique nickname
   having a maximum length of nine (9) characters.  See the protocol
   grammar rules (section 2.3.1) for what may and may not be used in a
   nickname.

   While the maximum length is limited to nine characters, clients
   SHOULD accept longer strings as they may become used in future
   evolutions of the protocol.

1.2.1.1 Operators

   To allow a reasonable amount of order to be kept within the IRC
   network, a special class of users (operators) is allowed to perform
   general maintenance functions on the network.  Although the powers
   granted to an operator can be considered as 'dangerous', they are
   nonetheless often necessary.  Operators SHOULD be able to perform
   basic network tasks such as disconnecting and reconnecting servers as
   needed.  In recognition of this need, the protocol discussed herein
   provides for operators only to be able to perform such functions.
   See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).

   A more controversial power of operators is the ability to remove a
   user from the connected network by 'force', i.e., operators are able
   to close the connection between any client and server.  The
   justification for this is very delicate since its abuse is both
   destructive and annoying, and its benefits close to inexistent.  For
   further details on this type of action, see section 3.7.1 (KILL).

1.2.2 Services

   Each service is distinguished from other services by a service name
   composed of a nickname and a server name.  As for users, the nickname
   has a maximum length of nine (9) characters.  See the protocol
   grammar rules (section 2.3.1) for what may and may not be used in a
   nickname.

1.3 Channels

   Channels names are strings (beginning with a '&', '#', '+' or '!'
   character) of length up to fifty (50) characters.  Apart from the
   requirement that the first character is either '&', '#', '+' or '!',
   the only restriction on a channel name is that it SHALL NOT contain
   any spaces (' '), a control G (^G or ASCII 7), a comma (',').  Space
   is used as parameter separator and command is used as a list item
   separator by the protocol).  A colon (':') can also be used as a
   delimiter for the channel mask.  Channel names are case insensitive.



Kalt                         Informational                      [Page 4]

RFC 2812          Internet Relay Chat: Client Protocol        April 2000


   See the protocol grammar rules (section 2.3.1) for the exact syntax
   of a channel name.

   Each prefix characterizes a different channel type.  The definition
   of the channel types is not relevant to the client-server protocol
   and thus it is beyond the scope of this document.  More details can
   be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].

2. The IRC Client Specification

2.1 Overview

   The protocol as described herein is for use only with client to
   server connections when the client registers as a user.

2.2 Character codes

   No specific character set is specified. The protocol is based on a
   set of codes which are composed of eight (8) bits, making up an
   octet.  Each message may be composed of any number of these octets;
   however, some octet values are used for control codes, which act as
   message delimiters.

   Regardless of being an 8-bit protocol, the delimiters and keywords
   are such that protocol is mostly usable from US-ASCII terminal and a
   telnet connection.

   Because of IRC's Scandinavian origin, the characters {}|^ are
   considered to be the lower case equivalents of the characters []\~,
   respectively. This is a critical issue when determining the
   equivalence of two nicknames or channel names.

2.3 Messages

   Servers and clients send each other messages, which may or may not
   generate a reply.  If the message contains a valid command, as
   described in later sections, the client should expect a reply as
   specified but it is not advised to wait forever for the reply; client
   to server and server to server communication is essentially
   asynchronous by nature.

   Each IRC message may consist of up to three main parts: the prefix
   (OPTIONAL), the command, and the command parameters (maximum of
   fifteen (15)).  The prefix, command, and all parameters are separated
   by one ASCII space character (0x20) each.






Kalt                         Informational                      [Page 5]

RFC 2812          Internet Relay Chat: Client Protocol        April 2000


   The presence of a prefix is indicated with a single leading ASCII
   colon character (':', 0x3b), which MUST be the first character of the
   message itself.  There MUST be NO gap (whitespace) between the colon
   and the prefix.  The prefix is used by servers to indicate the true
   origin of the message.  If the prefix is missing from the message, it
   is assumed to have originated from the connection from which it was
   received from.  Clients SHOULD NOT use a prefix when sending a
   message; if they use one, the only valid prefix is the registered
   nickname associated with the client.

   The command MUST either be a valid IRC command or a three (3) digit
   number represented in ASCII text.

   IRC messages are always lines of characters terminated with a CR-LF
   (Carriage Return - Line Feed) pair, and these messages SHALL NOT
   exceed 512 characters in length, counting all characters including
   the trailing CR-LF. Thus, there are 510 characters maximum allowed
   for the command and its parameters.  There is no provision for
   continuation of message lines.  See section 6 for more details about
   current implementations.

2.3.1 Message format in Augmented BNF

   The protocol messages must be extracted from the contiguous stream of
   octets.  The current solution is to designate two characters, CR and
   LF, as message separators.  Empty messages are silently ignored,
   which permits use of the sequence CR-LF between messages without
   extra problems.

   The extracted message is parsed into the components <prefix>,
   <command> and list of parameters (<params>).

    The Augmented BNF representation for this is:

    message    =  [ ":" prefix SPACE ] command [ params ] crlf
    prefix     =  servername / ( nickname [ [ "!" user ] "@" host ] )
    command    =  1*letter / 3digit
    params     =  *14( SPACE middle ) [ SPACE ":" trailing ]
               =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]

    nospcrlfcl =  %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
                    ; any octet except NUL, CR, LF, " " and ":"
    middle     =  nospcrlfcl *( ":" / nospcrlfcl )
    trailing   =  *( ":" / " " / nospcrlfcl )

    SPACE      =  %x20        ; space character
    crlf       =  %x0D %x0A   ; "carriage return" "linefeed"




Kalt                         Informational                      [Page 6]

RFC 2812          Internet Relay Chat: Client Protocol        April 2000


   NOTES:
      1) After extracting the parameter list, all parameters are equal
         whether matched by <middle> or <trailing>. <trailing> is just a
         syntactic trick to allow SPACE within the parameter.

      2) The NUL (%x00) character is not special in message framing, and
         basically could end up inside a parameter, but it would cause
         extra complexities in normal C string handling. Therefore, NUL
         is not allowed within messages.

   Most protocol messages specify additional semantics and syntax for
   the extracted parameter strings dictated by their position in the
   list.  For example, many server commands will assume that the first
   parameter after the command is the list of targets, which can be
   described with:

  target     =  nickname / server