Network Working Group D. Oakley, Ed. Internet-Draft ircdocs Obsoletes: 1459, 2810, 2811, 2812 (if J. Allnutt approved) Kiwi IRC Intended status: Informational May 28, 2017 Expires: November 29, 2017 Internet Relay Chat Client Protocol draft-oakley-irc-client-latest Abstract The Internet Relay Chat (IRC) protocol has been designed over a number of years, with multitudes of implementations and use cases appearing. This document describes the IRC Client-Server protocol. IRC is a text-based chat protocol which has proven itself valuable and useful. It is well-suited to running on many machines in a distributed fashion. A typical setup involves multiple servers connected in a distributed network. Messages are delivered through this network and state is maintained across it for the connected clients and active channels. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 29, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Oakley & Allnutt Expires November 29, 2017 [Page 1] Internet-Draft irc-client May 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IRC Concepts . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Architectural . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1. Servers . . . . . . . . . . . . . . . . . . . . . . . 3 3. Normative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The Internet Relay Chat (IRC) protocol has been designed over a number of years, with multitudes of implementations and use cases appearing. This document describes the IRC Client-Server protocol. IRC is a text-based chat protocol which has proven itself valuable and useful. It is well-suited to running on many machines in a distributed fashion. A typical setup involves multiple servers connected in a distributed network. Messages are delivered through this network and state is maintained across it for the connected clients and active channels. 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 [RFC2119]. 2. IRC Concepts This section describes concepts behind the implementation and organisation of the IRC protocol, which are useful in understanding how it works. 2.1. Architectural A typical IRC network consists of servers and clients connected to those servers, with a good mix of IRC operators and channels. This section goes through each of those, what they are and a brief overview of them. Oakley & Allnutt Expires November 29, 2017 [Page 2] Internet-Draft irc-client May 2017 2.1.1. Servers Servers form the backbone of IRC, providing a point to which clients may connect and talk to each other, and a point for other servers to connect to, forming an IRC network. The most common network configuration for IRC servers is that of a spanning tree, where each server acts as a central node for the rest of the network it sees. Other topologies are being experimented with, but right there are no others widely used in production. [ Server 15 ] [ Server 13 ] [ Server 14 ] / \ / / \ / [ Server 11 ] ------ [ Server 1 ] [ Server 12 ] / \ / / \ / [ Server 2 ] [ Server 3 ] / \ \ / \ \ [ Server 4 ] [ Server 5 ] [ Server 6 ] / | \ / / | \ / / | \____ / / | \ / [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ] : [ etc. ] : Figure 1: Format of a typical IRC network There have been several terms created over time to describe the roles of different servers on an IRC network. Some of the most common terms are as follows: o *Hub*: A hub is a server that connects to multiple other servers. For instance, in the figure above, Server 2, Server 3, and Server 4 would be examples of hub servers. o *Core Hub*: A core hub is typically a hub server that connects fairly major parts of the IRC network together. What is considered a core hub will change depending on the size of a network and what the administrators of the network consider important. For instance, in the figure above, Server 1, Server 2, and Server 3 may be considered core hubs by the network administrators. Oakley & Allnutt Expires November 29, 2017 [Page 3] Internet-Draft irc-client May 2017 o *Leaf*: A leaf is a server that is only connected to a single other server on the network. Typically, leafs are the primary servers that handle client connections. In the figure above, Servers 7, 8, 10, 13, 14, and others would be considered leaf servers. o *Services*: A services server is a special type of server that extends the capabilities of the server software on the network (ie, they provide _services_ to the network). Services are not used on all networks, and the capabilities typically provided by them may be built-into server software itself rather than being provided by a separate software package. Features usually handled by services include client account registration (as are typically used for SASL authentication), channel registration (allowing client accounts to 'own' channels), and further modifications and extensions to the IRC protocol. 'Services' themselves are *not* specified in any way by the protocol. What they provide depends entirely on the software packages being run. A trend these days is to hide the real structure of a network from regular users. Networks that implement this may restrict or modify commands like "MAP" so that regular users see every other server on the network as linked directly to the current server. When this is done, servers that do not handle client connections may also be hidden from users (hubs hidden in this way can be called 'hidden hubs'). Generally, IRC operators can always see the true structure of a network. These terms are not generally used in IRC protocol documentation, but may be used by the administrators of a network in order to differentiate the servers they run and their roles. 3. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Daniel Oakley (editor) ircdocs Email: daniel@danieloaks.net Oakley & Allnutt Expires November 29, 2017 [Page 4] Internet-Draft irc-client May 2017 Jack Allnutt Kiwi IRC Email: jack@allnutt.eu Oakley & Allnutt Expires November 29, 2017 [Page 5]