rfc2811.txt

中、英文RFC文档大全打包下载完全版 .

   is described below.  Servers MAY use a different logic, but that it
   is strongly RECOMMENDED that all servers use the same logic on a
   particular IRC network to maintain coherence as well as fairness.
   For the same reason, the "reop delay" SHOULD be uniform on all
   servers for a given IRC network.  As for the "channel delay", the
   value of the "reop delay" SHOULD be set considering many factors
   among which are the size (user wise) of the IRC network, and the
   usual duration of network splits.

   a) the reop mechanism is triggered after a random time following the
      expiration of the "reop delay".  This should limit the eventuality
      of the mechanism being triggered at the same time (for the same
      channel) on two separate servers.




Kalt                         Informational                     [Page 13]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   b) If the channel is small (five (5) users or less), and the "channel
      delay" for this channel has expired,
        Then reop all channel members if at least one member is local to
        the server.

   c) If the channel is small (five (5) users or less), and the "channel
      delay" for this channel has expired, and the "reop delay" has
      expired for longer than its value,
        Then reop all channel members.

   d) For other cases, reop at most one member on the channel, based on
      some method build into the server. If you don't reop a member, the
      method should be such that another server will probably op
      someone. The method SHOULD be the same over the whole network. A
      good heuristic could be just random reop.
      (The current implementation actually tries to choose a member
      local to the server who has not been idle for too long, eventually
      postponing action, therefore letting other servers have a chance
      to find a "not too idle" member.  This is over complicated due to
      the fact that servers only know the "idle" time of their local
      users)

6. Current problems

   There are a number of recognized problems with the way IRC channels
   are managed.  Some of these can be directly attributed to the rules
   defined in this document, while others are the result of the
   underlying "IRC Server Protocol" [IRC-SERVER].  Although derived from
   RFC 1459 [IRC], this document introduces several novelties in an
   attempt to solve some of the known problems.

6.1 Labels

   This document defines one of the many labels used by the IRC
   protocol.  Although there are several distinct namespaces (based on
   the channel name prefix), duplicates inside each of these are not
   allowed.  Currently, it is possible for users on different servers to
   pick the label which may result in collisions (with the exception of
   channels known to only one server where they can be averted).

6.1.1 Channel Delay

   The channel delay mechanism described in section 5.1 (Tracking
   Recently Used Channels) and used for channels prefixed with the
   character '#' is a simple attempt at preventing collisions from
   happening.  Experience has shown that, under normal circumstances, it





Kalt                         Informational                     [Page 14]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   is very efficient; however, it obviously has severe limitations
   keeping it from being an adequate solution to the problem discussed
   here.

6.1.2 Safe Channels

   "Safe channels" described in section 3.2 (Safe Channels) are a better
   way to prevent collisions from happening as it prevents users from
   having total control over the label they choose.  The obvious
   drawback for such labels is that they are not user friendly.
   However, it is fairly trivial for a client program to improve on
   this.

6.2 Mode Propagation Delays

   Because of network delays induced by the network, and because each
   server on the path is REQUIRED to check the validity of mode changes
   (e.g., user exists and has the right privileges), it is not unusual
   for a MODE message to only affect part of the network, often creating
   a discrepancy between servers on the current state of a channel.

   While this may seem easy to fix (by having only the original server
   check the validity of mode changes), it was decided not to do so for
   various reasons.  One concern is that servers cannot trust each
   other, and that a misbehaving servers can easily be detected.  This
   way of doing so also stops wave effects on channels which are out of
   synch when mode changes are issued from different directions.

6.3 Collisions And Channel Modes

   The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
   describes how channel data is exchanged when two servers connect to
   each other.  Channel collisions (either legitimate or not) are
   treated as inclusive events, meaning that the resulting channel has
   for members all the users who are members of the channel on either
   server prior to the connection.

   Similarly, each server sends the channel modes to the other one.
   Therefore, each server also receives these channel modes.  There are
   three types of modes for a given channel: flags, masks, and data.
   The first two types are easy to deal with as they are either set or
   unset.  If such a mode is set on one server, it MUST be set on the
   other server as a result of the connection.








Kalt                         Informational                     [Page 15]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   As topics are not sent as part of this exchange, they are not a
   problem.  However, channel modes 'l' and 'k' are exchanged, and if
   they are set on both servers prior to the connection, there is no
   mechanism to decide which of the two values takes precedence.  It is
   left up to the users to fix the resulting discrepancy.

6.4 Resource Exhaustion

   The mode based on masks defined in section 4.3 make the IRC servers
   (and network) vulnerable to a simple abuse of the system: a single
   channel operator can set as many different masks as possible on a
   particular channel.  This can easily cause the server to waste
   memory, as well as network bandwidth (since the info is propagated to
   other servers).  For this reason it is RECOMMENDED that a limit be
   put on the number of such masks per channels as mentioned in section
   4.3.

   Moreover, more complex mechanisms MAY be used to avoid having
   redundant masks set for the same channel.

7. Security Considerations

7.1 Access Control

   One of the main ways to control access to a channel is to use masks
   which are based on the username and hostname of the user connections.
   This mechanism can only be efficient and safe if the IRC servers have
   an accurate way of authenticating user connections, and if users
   cannot easily get around it.  While it is in theory possible to
   implement such a strict authentication mechanism, most IRC networks
   (especially public networks) do not have anything like this in place
   and provide little guaranty about the accuracy of the username and
   hostname for a particular client connection.

   Another way to control access is to use a channel key, but since this
   key is sent in plaintext, it is vulnerable to traditional man in the
   middle attacks.

7.2 Channel Privacy

   Because channel collisions are treated as inclusive events (See
   Section 6.3), it is possible for users to join a channel overriding
   its access control settings.  This method has long been used by
   individuals to "take over" channels by "illegitimately" gaining
   channel operator status on the channel.  The same method can be used
   to find out the exact list of members of a channel, as well as to
   eventually receive some of the messages sent to the channel.




Kalt                         Informational                     [Page 16]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


7.3 Anonymity

   The anonymous channel flag (See Section 4.2.1) can be used to render
   all users on such channel "anonymous" by presenting all messages to
   the channel as originating from a pseudo user which nickname is
   "anonymous".  This is done at the client-server level, and no
   anonymity is provided at the server-server level.

   It should be obvious to readers, that the level of anonymity offered
   is quite poor and insecure, and that clients SHOULD display strong
   warnings for users joining such channels.

8. Current support and availability

     Mailing lists for IRC related discussion:
       General discussion: [e-mail]
       Protocol development: [e-mail]

     Software implementations:
       ftp://ftp.irc.org/irc/server
       ftp://ftp.funet.fi/pub/unix/irc
       ftp://coombs.anu.edu.au/pub/irc

     Newsgroup: alt.irc

9. Acknowledgements

   Parts of this document were copied from the RFC 1459 [IRC] which
   first formally documented the IRC Protocol.  It has also benefited
   from many rounds of review and comments.  In particular, the
   following people have made significant contributions to this
   document:

   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   Ruokonen, Magnus Tjernstrom, Stefan Zehl.
















Kalt                         Informational                     [Page 17]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


10. References

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

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

   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
                April 2000.

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

   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
                2813, April 2000.

11. Author's Address

   Christophe Kalt
   99 Teaneck Rd, Apt #117
   Ridgefield Park, NJ 07660
   USA

   EMail: [e-mail]


























Kalt                         Informational                     [Page 18]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kalt                         Informational                     [Page 19]