├── lib
    ├── addstyle.sed
    ├── style-special.css
    └── style.css
├── .gitignore
├── README.md
├── draft-oakley-irc-client-latest.mkd
├── dist
    ├── draft-oakley-irc-client-latest.txt
    ├── draft-oakley-irc-client-latest.xml
    ├── draft-oakley-irc-client-latest.html
    └── draft-oakley-irc-ctcp-latest.txt
├── draft-oakley-irc-ctcp-latest.mkd
├── versions
    └── ctcp
    │   ├── draft-oakley-irc-ctcp-00.mkd
    │   ├── draft-oakley-irc-ctcp-01.mkd
    │   ├── draft-oakley-irc-ctcp-02.mkd
    │   ├── draft-oakley-irc-ctcp-00.txt
    │   └── draft-oakley-irc-ctcp-01.txt
└── info
    ├── grawity-sasl-20150304.md
    └── rfc2810.txt


/lib/addstyle.sed:
--------------------------------------------------------------------------------
 1 | /<style[^>]*>/,/<\/style>/{
 2 |   /<style[^>]*>/{
 3 |     h
 4 |     s/<style[^>]*>.*//
 5 |     p
 6 |     i\
 7 | <style type="text/css">/*<![CDATA[*/
 8 |     # Unfortunately, r appends after the current line.  If the end of the style
 9 |     # pattern is on this line, then this will mean that the end of the line
10 |     # will appear before the style.  That's terrible.  See below.
11 |     r lib/style.css
12 |     r lib/style-special.css
13 |     a\
14 |   /*]]>*/</style>
15 |     g
16 |   }
17 |   # Save the last line for later.
18 |   /<\/style>/h
19 |   d
20 | }
21 | # This recovers a saved line and prints it.
22 | x
23 | /<\/style>/{
24 |   s/.*<\/style>//
25 |   p
26 | }
27 | x
28 | 
29 | 


--------------------------------------------------------------------------------
/lib/style-special.css:
--------------------------------------------------------------------------------
 1 | /* my special additions to the default I-D template style */
 2 | 
 3 | /* I like open-sans, sorta riffing on the style I'm using on modern already */
 4 | @import url('https://modern.ircdocs.horse/css/open-sans.css');
 5 | body {
 6 |     font: 16px/22px "Open Sans", sans-serif;
 7 | }
 8 | #title, h1, h2, h3, h4, h5, h6 {
 9 |     font-family: "Open Sans", sans-serif;
10 | }
11 | 
12 | /* I'll only do these for screen viewing because they do expand the text.
13 |    and leaving the doc smoller for printing feels sensible/responsible. */
14 | @media screen {
15 |     /* give the text and headings some more room to breathe */
16 |     p + p {
17 |         margin-top: 11px;
18 |     }
19 |     h2 {
20 |         margin-top: 20px;
21 |     }
22 |     h3 {
23 |         margin-top: 20px;
24 |     }
25 | 
26 |     /* make the pre boxes feel more open and happier */
27 |     pre {
28 |     padding: 8px 5px;
29 |     border-radius: 4px;
30 |     }
31 | }
32 | 


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
 1 | ### Windows ###
 2 | # Windows image file caches
 3 | Thumbs.db
 4 | ehthumbs.db
 5 | 
 6 | # Folder config file
 7 | Desktop.ini
 8 | 
 9 | # Recycle Bin used on file shares
10 | $RECYCLE.BIN/
11 | 
12 | # Windows Installer files
13 | *.cab
14 | *.msi
15 | *.msm
16 | *.msp
17 | 
18 | # Windows shortcuts
19 | *.lnk
20 | 
21 | 
22 | ### OSX ###
23 | .DS_Store
24 | .AppleDouble
25 | .LSOverride
26 | 
27 | # Icon must end with two \r
28 | Icon
29 | 
30 | 
31 | # Thumbnails
32 | ._*
33 | 
34 | # Files that might appear in the root of a volume
35 | .DocumentRevisions-V100
36 | .fseventsd
37 | .Spotlight-V100
38 | .TemporaryItems
39 | .Trashes
40 | .VolumeIcon.icns
41 | 
42 | # Directories potentially created on remote AFP share
43 | .AppleDB
44 | .AppleDesktop
45 | Network Trash Folder
46 | Temporary Items
47 | .apdisk
48 | 
49 | 
50 | ### Linux ###
51 | *~
52 | 
53 | # KDE directory preferences
54 | .directory
55 | 
56 | # Linux trash folder which might appear on any partition or disk
57 | .Trash-*
58 | 
59 | 
60 | ### IRC ###
61 | /.refcache/
62 | /src/middle.xml
63 | /src/back.xml
64 | tracker.log
65 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # IRC RFCs
 2 | 
 3 | I'm trying to write an update to the outdated [RFC 1459](https://tools.ietf.org/html/rfc1459) and [RFC 2812](https://tools.ietf.org/html/rfc2812) specifications.
 4 | 
 5 | Newest builds are available here:
 6 | 
 7 | <!-- - IRC Client: [HTML](https://rawgit.com/ircdocs/irc-rfcs/master/dist/draft-oakley-irc-client-latest.html) / [Text](https://rawgit.com/ircdocs/irc-rfcs/master/dist/draft-oakley-irc-client-latest.txt) -->
 8 | - IRC CTCP: [HTML](https://cdn.jsdelivr.net/gh/ircdocs/irc-rfcs@master/dist/draft-oakley-irc-ctcp-latest.html) / [Text](https://cdn.jsdelivr.net/gh/ircdocs/irc-rfcs@master/dist/draft-oakley-irc-ctcp-latest.txt) (I'll fix the html link a bit later, the txt link works though)
 9 | 
10 | The 'drafts' in this repo are mostly based off my [Modern docs](https://modern.ircdocs.horse/). The CTCP I-D is something I'm working on, but the IRC Client Protocol document is probably not going to be worked on for a very long time (I think that info's better conveyed in the [Modern doc](https://modern.ircdocs.horse/) and more recent documentation attempts like [devdocs](https://dd.ircdocs.horse)).
11 | 
12 | 
13 | ## Why?
14 | 
15 | RFC 1459 and RFC 2812 are the first place that new IRC software authors look when they want to implement IRC. And why wouldn't they – those are the latest RFCs for it!
16 | 
17 | However, IRC has changed a lot since those specs were published. Today, there are many different documents that you need to look at to fully understand how the protocol works in practice. I've got a page [here](https://ircdocs.horse/specs/) that tries to go through the useful ones, and [this living specification](https://modern.ircdocs.horse/) which attempts to produce a workable spec to use day-to-day.
18 | 
19 | However, having an updated specification that's gone through the IETF process and is a proper RFC would:
20 | 
21 | - Help us standardise the defacto solutions that have been in use for years, and prevent fragmentation from those by newer software.
22 | - Give people a better core standard which they can refer to, which is an RFC and describes the protocol as it really works.
23 | 
24 | These documents don't describe things that will be, or things that should happen after the spec is published. These documents describe how things work right now in specific detail.
25 | 
26 | 
27 | ## Documents
28 | 
29 | I'm going to split this into a few separate documents, each describing a separate part of IRC as it stands today. Here, I'll go through what each one covers, what it explicitly doesn't, and the status of it.
30 | 
31 | ### Client Protocol
32 | 
33 | This is the big one, the replacement for RFC 1459 and RFC 2812 on the whole. It'll probably include:
34 | 
35 | - Core client protocol.
36 | - `RPL_ISUPPORT`
37 | - Basic message tags (at least describing them as part of the IRC framing).
38 | 
39 | This document is being actively worked on as the main [Modern Client Protocol Doc](https://modern.ircdocs.horse/). I'm **not working on the client protocol spec here** until that linked Modern document is at a point where I'm relatively happy removing the WIP tag from it.
40 | 
41 | <!-- [HTML](https://rawgit.com/DanielOaks/irc-rfcs/master/dist/draft-oakley-irc-client-latest.html) / [Text](https://rawgit.com/DanielOaks/irc-rfcs/master/dist/draft-oakley-irc-client-latest.txt) -->
42 | 
43 | ### Client-to-Client Protocol (CTCP)
44 | 
45 | This describes how CTCP works today, ignoring a lot of the quoting that was specified in older documents but not actually implemented by any widely-used clients. It describes:
46 | 
47 | - Core CTCP protocol.
48 | - Commonly-used or seen CTCP messages.
49 | 
50 | I'm **working on this document currently**, most of that work being copyediting and editing in general. I'm thinking about using this as a 'test bed' for seeing how I can go getting clients to look over and validate it, and for seeing how the IETF responds to IRC specifications.
51 | 
52 | [HTML](https://rawgit.com/DanielOaks/irc-rfcs/master/dist/draft-oakley-irc-ctcp-latest.html) / [Text](https://rawgit.com/DanielOaks/irc-rfcs/master/dist/draft-oakley-irc-ctcp-latest.txt)
53 | 
54 | 
55 | ## S2S Note
56 | 
57 | The server to server protocol is explicitly not being covered here.
58 | 
59 | [RFC 2812](https://tools.ietf.org/html/rfc2812) says the following: "At the time of writing, the only current implementation of this protocol is the IRC server, version 2.10". Today, that's not the case. You have lots and lots of different IRCds, and lots of different server protocols in use because of it. TS6, a bunch of custom TS6 flavours, TS5, P10, InspIRCd's protocol. We're primarily aiming to document and specify what is being used today, and there simply isn't a single server protocol in use today.
60 | 
61 | Especially given that there are servers (and competing IRC protocol efforts) experimenting with topologies other than the standard spanning-tree, and even their own newly-designed protocols between servers, I don't think it makes sense to try to specify a new version of the server protocol at this point. I think it's best to leave this to server authors themselves and relevant server spec documents sometime later as the technology grows and experiments, as what we specify would probably just be ignored or quickly become irrelevant.
62 | 
63 | 
64 | ## Building
65 | 
66 | To build this, install [kramdown-rfc2629](https://github.com/cabo/kramdown-rfc2629) and then use the relevant `build-*.sh` script. That script will put the xml, txt and html files in the `dist/` directory.
67 | 
68 | As noted below, when submitting changes only include the source file changes. Don't include the newly-built `dist/` changes. This helps when merging and resolving conflicts.
69 | 
70 | 
71 | ## Contributing
72 | 
73 | When putting in a pull request, ***ONLY*** submit a change for the source files. ***DO NOT*** include the new `dist/` files in your pull request. This is to prevent a million conflicts if we have three PRs sitting in the waiting queue and try to merge all of them at once (particularly the .txt files). We can generate new `dist/` files after we merge things into the repo.
74 | 
75 | **NOTE:** `lib/addstyle.sed` and `lib/style.css` have been taken from Martin Thompson's [I-D Template](https://github.com/martinthomson/i-d-template) repository.
76 | 


--------------------------------------------------------------------------------
/draft-oakley-irc-client-latest.mkd:
--------------------------------------------------------------------------------
 1 | ---
 2 | coding: utf-8
 3 | 
 4 | title: Internet Relay Chat Client Protocol
 5 | abbrev: irc-client
 6 | docname: draft-oakley-irc-client-latest
 7 | 
 8 | submissionType: independent
 9 | category: info
10 | 
11 | stand_alone: yes
12 | pi: [toc, sortrefs, symrefs, comments]
13 | 
14 | obsoletes: 1459, 2810, 2811, 2812
15 | 
16 | author:
17 |   -
18 |     ins: D. Oakley
19 |     name: Daniel Oakley
20 |     role: editor
21 |     org: ircdocs
22 |     email: daniel@danieloaks.net
23 |   -
24 |     ins: J. Allnutt
25 |     name: Jack Allnutt
26 |     org: Kiwi IRC
27 |     email: jack@allnutt.eu
28 | 
29 | --- abstract
30 | 
31 | 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.
32 | 
33 | 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.
34 | 
35 | --- middle
36 | 
37 | # Introduction
38 | 
39 | 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.
40 | 
41 | 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.
42 | 
43 | 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}}.
44 | 
45 | 
46 | # IRC Concepts
47 | 
48 | This section describes concepts behind the implementation and organisation of the IRC protocol, which are useful in understanding how it works.
49 | 
50 | 
51 | ## Architectural
52 | 
53 | 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.
54 | 
55 | ### Servers
56 | 
57 | 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.
58 | 
59 | 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.
60 | 
61 | ~~~
62 |                           [ Server 15 ]  [ Server 13 ] [ Server 14 ]
63 |                                 /                \         /
64 |                                /                  \       /
65 |        [ Server 11 ] ------ [ Server 1 ]       [ Server 12 ]
66 |                              /        \          /
67 |                             /          \        /
68 |                  [ Server 2 ]          [ Server 3 ]
69 |                    /       \                      \
70 |                   /         \                      \
71 |           [ Server 4 ]    [ Server 5 ]         [ Server 6 ]
72 |            /    |    \                           /
73 |           /     |     \                         /
74 |          /      |      \____                   /
75 |         /       |           \                 /
76 | [ Server 7 ] [ Server 8 ] [ Server 9 ]   [ Server 10 ]
77 | 
78 |                                  :
79 |                               [ etc. ]
80 |                                  :
81 | ~~~
82 | {: #figops artwork-align="center" title="Format of a typical IRC network"}
83 | 
84 | 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:
85 | 
86 | - **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.
87 | - **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.
88 | - **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.
89 | - **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.
90 | 
91 | 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.
92 | 
93 | 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.
94 | 
95 | 


--------------------------------------------------------------------------------
/dist/draft-oakley-irc-client-latest.txt:
--------------------------------------------------------------------------------
  1 | 
  2 | 
  3 | 
  4 | 
  5 | Network Working Group                                     D. Oakley, Ed.
  6 | Internet-Draft                                                   ircdocs
  7 | Obsoletes: 1459, 2810, 2811, 2812 (if                         J. Allnutt
  8 |            approved)                                            Kiwi IRC
  9 | Intended status: Informational                              May 28, 2017
 10 | Expires: November 29, 2017
 11 | 
 12 | 
 13 |                   Internet Relay Chat Client Protocol
 14 |                      draft-oakley-irc-client-latest
 15 | 
 16 | Abstract
 17 | 
 18 |    The Internet Relay Chat (IRC) protocol has been designed over a
 19 |    number of years, with multitudes of implementations and use cases
 20 |    appearing.  This document describes the IRC Client-Server protocol.
 21 | 
 22 |    IRC is a text-based chat protocol which has proven itself valuable
 23 |    and useful.  It is well-suited to running on many machines in a
 24 |    distributed fashion.  A typical setup involves multiple servers
 25 |    connected in a distributed network.  Messages are delivered through
 26 |    this network and state is maintained across it for the connected
 27 |    clients and active channels.
 28 | 
 29 | Status of This Memo
 30 | 
 31 |    This Internet-Draft is submitted in full conformance with the
 32 |    provisions of BCP 78 and BCP 79.
 33 | 
 34 |    Internet-Drafts are working documents of the Internet Engineering
 35 |    Task Force (IETF).  Note that other groups may also distribute
 36 |    working documents as Internet-Drafts.  The list of current Internet-
 37 |    Drafts is at http://datatracker.ietf.org/drafts/current/.
 38 | 
 39 |    Internet-Drafts are draft documents valid for a maximum of six months
 40 |    and may be updated, replaced, or obsoleted by other documents at any
 41 |    time.  It is inappropriate to use Internet-Drafts as reference
 42 |    material or to cite them other than as "work in progress."
 43 | 
 44 |    This Internet-Draft will expire on November 29, 2017.
 45 | 
 46 | Copyright Notice
 47 | 
 48 |    Copyright (c) 2017 IETF Trust and the persons identified as the
 49 |    document authors.  All rights reserved.
 50 | 
 51 |    This document is subject to BCP 78 and the IETF Trust's Legal
 52 |    Provisions Relating to IETF Documents
 53 | 
 54 | 
 55 | 
 56 | Oakley & Allnutt        Expires November 29, 2017               [Page 1]
 57 | 
 58 | Internet-Draft                 irc-client                       May 2017
 59 | 
 60 | 
 61 |    (http://trustee.ietf.org/license-info) in effect on the date of
 62 |    publication of this document.  Please review these documents
 63 |    carefully, as they describe your rights and restrictions with respect
 64 |    to this document.
 65 | 
 66 | Table of Contents
 67 | 
 68 |    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 69 |    2.  IRC Concepts  . . . . . . . . . . . . . . . . . . . . . . . .   2
 70 |      2.1.  Architectural . . . . . . . . . . . . . . . . . . . . . .   2
 71 |        2.1.1.  Servers . . . . . . . . . . . . . . . . . . . . . . .   3
 72 |    3.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
 73 |    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4
 74 | 
 75 | 1.  Introduction
 76 | 
 77 |    The Internet Relay Chat (IRC) protocol has been designed over a
 78 |    number of years, with multitudes of implementations and use cases
 79 |    appearing.  This document describes the IRC Client-Server protocol.
 80 | 
 81 |    IRC is a text-based chat protocol which has proven itself valuable
 82 |    and useful.  It is well-suited to running on many machines in a
 83 |    distributed fashion.  A typical setup involves multiple servers
 84 |    connected in a distributed network.  Messages are delivered through
 85 |    this network and state is maintained across it for the connected
 86 |    clients and active channels.
 87 | 
 88 |    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 89 |    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 90 |    document are to be interpreted as described in [RFC2119].
 91 | 
 92 | 2.  IRC Concepts
 93 | 
 94 |    This section describes concepts behind the implementation and
 95 |    organisation of the IRC protocol, which are useful in understanding
 96 |    how it works.
 97 | 
 98 | 2.1.  Architectural
 99 | 
100 |    A typical IRC network consists of servers and clients connected to
101 |    those servers, with a good mix of IRC operators and channels.  This
102 |    section goes through each of those, what they are and a brief
103 |    overview of them.
104 | 
105 | 
106 | 
107 | 
108 | 
109 | 
110 | 
111 | 
112 | Oakley & Allnutt        Expires November 29, 2017               [Page 2]
113 | 
114 | Internet-Draft                 irc-client                       May 2017
115 | 
116 | 
117 | 2.1.1.  Servers
118 | 
119 |    Servers form the backbone of IRC, providing a point to which clients
120 |    may connect and talk to each other, and a point for other servers to
121 |    connect to, forming an IRC network.
122 | 
123 |    The most common network configuration for IRC servers is that of a
124 |    spanning tree, where each server acts as a central node for the rest
125 |    of the network it sees.  Other topologies are being experimented
126 |    with, but right there are no others widely used in production.
127 | 
128 |                              [ Server 15 ]  [ Server 13 ] [ Server 14 ]
129 |                                    /                \         /
130 |                                   /                  \       /
131 |           [ Server 11 ] ------ [ Server 1 ]       [ Server 12 ]
132 |                                 /        \          /
133 |                                /          \        /
134 |                     [ Server 2 ]          [ Server 3 ]
135 |                       /       \                      \
136 |                      /         \                      \
137 |              [ Server 4 ]    [ Server 5 ]         [ Server 6 ]
138 |               /    |    \                           /
139 |              /     |     \                         /
140 |             /      |      \____                   /
141 |            /       |           \                 /
142 |    [ Server 7 ] [ Server 8 ] [ Server 9 ]   [ Server 10 ]
143 | 
144 |                                     :
145 |                                  [ etc. ]
146 |                                     :
147 | 
148 |                  Figure 1: Format of a typical IRC network
149 | 
150 |    There have been several terms created over time to describe the roles
151 |    of different servers on an IRC network.  Some of the most common
152 |    terms are as follows:
153 | 
154 |    o  *Hub*: A hub is a server that connects to multiple other servers.
155 |       For instance, in the figure above, Server 2, Server 3, and Server
156 |       4 would be examples of hub servers.
157 | 
158 |    o  *Core Hub*: A core hub is typically a hub server that connects
159 |       fairly major parts of the IRC network together.  What is
160 |       considered a core hub will change depending on the size of a
161 |       network and what the administrators of the network consider
162 |       important.  For instance, in the figure above, Server 1, Server 2,
163 |       and Server 3 may be considered core hubs by the network
164 |       administrators.
165 | 
166 | 
167 | 
168 | Oakley & Allnutt        Expires November 29, 2017               [Page 3]
169 | 
170 | Internet-Draft                 irc-client                       May 2017
171 | 
172 | 
173 |    o  *Leaf*: A leaf is a server that is only connected to a single
174 |       other server on the network.  Typically, leafs are the primary
175 |       servers that handle client connections.  In the figure above,
176 |       Servers 7, 8, 10, 13, 14, and others would be considered leaf
177 |       servers.
178 | 
179 |    o  *Services*: A services server is a special type of server that
180 |       extends the capabilities of the server software on the network
181 |       (ie, they provide _services_ to the network).  Services are not
182 |       used on all networks, and the capabilities typically provided by
183 |       them may be built-into server software itself rather than being
184 |       provided by a separate software package.  Features usually handled
185 |       by services include client account registration (as are typically
186 |       used for SASL authentication), channel registration (allowing
187 |       client accounts to 'own' channels), and further modifications and
188 |       extensions to the IRC protocol.  'Services' themselves are *not*
189 |       specified in any way by the protocol.  What they provide depends
190 |       entirely on the software packages being run.
191 | 
192 |    A trend these days is to hide the real structure of a network from
193 |    regular users.  Networks that implement this may restrict or modify
194 |    commands like "MAP" so that regular users see every other server on
195 |    the network as linked directly to the current server.  When this is
196 |    done, servers that do not handle client connections may also be
197 |    hidden from users (hubs hidden in this way can be called 'hidden
198 |    hubs').  Generally, IRC operators can always see the true structure
199 |    of a network.
200 | 
201 |    These terms are not generally used in IRC protocol documentation, but
202 |    may be used by the administrators of a network in order to
203 |    differentiate the servers they run and their roles.
204 | 
205 | 3.  Normative References
206 | 
207 |    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
208 |               Requirement Levels", BCP 14, RFC 2119,
209 |               DOI 10.17487/RFC2119, March 1997,
210 |               <http://www.rfc-editor.org/info/rfc2119>.
211 | 
212 | Authors' Addresses
213 | 
214 |    Daniel Oakley (editor)
215 |    ircdocs
216 | 
217 |    Email: daniel@danieloaks.net
218 | 
219 | 
220 | 
221 | 
222 | 
223 | 
224 | Oakley & Allnutt        Expires November 29, 2017               [Page 4]
225 | 
226 | Internet-Draft                 irc-client                       May 2017
227 | 
228 | 
229 |    Jack Allnutt
230 |    Kiwi IRC
231 | 
232 |    Email: jack@allnutt.eu
233 | 
234 | 
235 | 
236 | 
237 | 
238 | 
239 | 
240 | 
241 | 
242 | 
243 | 
244 | 
245 | 
246 | 
247 | 
248 | 
249 | 
250 | 
251 | 
252 | 
253 | 
254 | 
255 | 
256 | 
257 | 
258 | 
259 | 
260 | 
261 | 
262 | 
263 | 
264 | 
265 | 
266 | 
267 | 
268 | 
269 | 
270 | 
271 | 
272 | 
273 | 
274 | 
275 | 
276 | 
277 | 
278 | 
279 | 
280 | Oakley & Allnutt        Expires November 29, 2017               [Page 5]
281 | 


--------------------------------------------------------------------------------
/dist/draft-oakley-irc-client-latest.xml:
--------------------------------------------------------------------------------
  1 | <?xml version="1.0" encoding="utf-8"?>
  2 |   <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  3 |   <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.1.2 -->
  4 | 
  5 | <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  6 | ]>
  7 | 
  8 | <?rfc toc="yes"?>
  9 | <?rfc sortrefs="yes"?>
 10 | <?rfc symrefs="yes"?>
 11 | <?rfc comments="yes"?>
 12 | 
 13 | <rfc docName="draft-oakley-irc-client-latest" category="info" submissionType="independent" obsoletes="1459, 2810, 2811, 2812">
 14 | 
 15 |   <front>
 16 |     <title abbrev="irc-client">Internet Relay Chat Client Protocol</title>
 17 | 
 18 |     <author initials="D." surname="Oakley" fullname="Daniel Oakley" role="editor">
 19 |       <organization>ircdocs</organization>
 20 |       <address>
 21 |         <email>daniel@danieloaks.net</email>
 22 |       </address>
 23 |     </author>
 24 |     <author initials="J." surname="Allnutt" fullname="Jack Allnutt">
 25 |       <organization>Kiwi IRC</organization>
 26 |       <address>
 27 |         <email>jack@allnutt.eu</email>
 28 |       </address>
 29 |     </author>
 30 | 
 31 |     <date year="2017" month="May" day="28"/>
 32 | 
 33 |     
 34 |     
 35 |     
 36 | 
 37 |     <abstract>
 38 | 
 39 | 
 40 | <t>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.</t>
 41 | 
 42 | <t>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.</t>
 43 | 
 44 | 
 45 | 
 46 |     </abstract>
 47 | 
 48 | 
 49 |   </front>
 50 | 
 51 |   <middle>
 52 | 
 53 | 
 54 | <section anchor="introduction" title="Introduction">
 55 | 
 56 | <t>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.</t>
 57 | 
 58 | <t>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.</t>
 59 | 
 60 | <t>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 <xref target="RFC2119"/>.</t>
 61 | 
 62 | </section>
 63 | <section anchor="irc-concepts" title="IRC Concepts">
 64 | 
 65 | <t>This section describes concepts behind the implementation and organisation of the IRC protocol, which are useful in understanding how it works.</t>
 66 | 
 67 | <section anchor="architectural" title="Architectural">
 68 | 
 69 | <t>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.</t>
 70 | 
 71 | <section anchor="servers" title="Servers">
 72 | 
 73 | <t>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.</t>
 74 | 
 75 | <t>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.</t>
 76 | 
 77 | <figure title="Format of a typical IRC network" anchor="figops"><artwork align="center"><![CDATA[
 78 |                           [ Server 15 ]  [ Server 13 ] [ Server 14 ]
 79 |                                 /                \         /
 80 |                                /                  \       /
 81 |        [ Server 11 ] ------ [ Server 1 ]       [ Server 12 ]
 82 |                              /        \          /
 83 |                             /          \        /
 84 |                  [ Server 2 ]          [ Server 3 ]
 85 |                    /       \                      \
 86 |                   /         \                      \
 87 |           [ Server 4 ]    [ Server 5 ]         [ Server 6 ]
 88 |            /    |    \                           /
 89 |           /     |     \                         /
 90 |          /      |      \____                   /
 91 |         /       |           \                 /
 92 | [ Server 7 ] [ Server 8 ] [ Server 9 ]   [ Server 10 ]
 93 | 
 94 |                                  :
 95 |                               [ etc. ]
 96 |                                  :
 97 | ]]></artwork></figure>
 98 | 
 99 | <t>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:</t>
100 | 
101 | <t><list style="symbols">
102 |   <t><spanx style="strong">Hub</spanx>: 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.</t>
103 |   <t><spanx style="strong">Core Hub</spanx>: 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.</t>
104 |   <t><spanx style="strong">Leaf</spanx>: 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.</t>
105 |   <t><spanx style="strong">Services</spanx>: A services server is a special type of server that extends the capabilities of the server software on the network (ie, they provide <spanx style="emph">services</spanx> 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 <spanx style="strong">not</spanx> specified in any way by the protocol. What they provide depends entirely on the software packages being run.</t>
106 | </list></t>
107 | 
108 | <t>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 <spanx style="verb">MAP</spanx> 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.</t>
109 | 
110 | <t>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.</t>
111 | 
112 | </section>
113 | </section>
114 | </section>
115 | 
116 | 
117 |   </middle>
118 | 
119 |   <back>
120 | 
121 |     <references title='Normative References'>
122 | 
123 | 
124 | 
125 | 
126 | 
127 | <reference  anchor="RFC2119" target='http://www.rfc-editor.org/info/rfc2119'>
128 | <front>
129 | <title>Key words for use in RFCs to Indicate Requirement Levels</title>
130 | <author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
131 | <date year='1997' month='March' />
132 | <abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
133 | </front>
134 | <seriesInfo name='BCP' value='14'/>
135 | <seriesInfo name='RFC' value='2119'/>
136 | <seriesInfo name='DOI' value='10.17487/RFC2119'/>
137 | </reference>
138 | 
139 | 
140 | 
141 | 
142 |     </references>
143 | 
144 | 
145 | 
146 | 
147 |   </back>
148 | 
149 | <!-- ##markdown-source:
150 | H4sIAGO1K1kAA+1YXW8btxJ931/B6zw4MSS1dpI2MVCghpM27rXjXNtBcZEE
151 | LXeXklhTywXJtaKbj9/eM0NytbIdJ/e9AiytqOFw5szhfHg8HheVrXUz2xdd
152 | mI6fFEXQwah9cdQE5RoVxJkyciUO5zKIQ6NVE8QrZ4OtrClkWTp1tS+0q8YV
153 | /1bUtmrkAvtrJ6dhbOWlUavxWmBsZFA+FIXvyoX2XtvmYtVCXje1ahXeoKSC
154 | zMy6Fa1OLWSDbOo/pLENBFfKF63eF29gw0h464JTU4+n1SI+VHaxgBb/rihs
155 | 6a1ROHBf7D56/HQk9p7sfs/vu/y+VxSyC3Pr9gshxvgTOBHCzybilC3npejQ
156 | M9loZYbrzhJQqtbBOl6wbsZgAATPC2ohtQEWvPXn+AFI/ATAbp7420QcGNN0
157 | IQyO/E1WlxvLfMC/9VKLo7PD4Ql/QfJnGSUnqiuK8XgsZOmDkxXAvpirWwN6
158 | H2oeiDbFU8ylF6VSjaiV17NG1cJeKSekaLpFiQc7BfrSAeOlDnOx6AzI0kGY
159 | ftGL1igCXgYE1QuETHReiUp6CMi2xU7wbCIu5toLQNSRMB1VOV1CJJCRZ4eJ
160 | ZeNz5ejwbNykKOhHbJUiqPdhXEJvLSpyo3dgOdfVnN3A0hUc0cErMxVX0nSy
161 | NCobNe3MRBwF0rZUxox9pwOUBStc1zSwUthGLGSzwls11w2s0w0OrjUQ1WVH
162 | wlPp53AUcRNh1epKGuFV6FpIXllzhS2MD0DBOrniwcymURVtvqENgVladzkR
163 | J8p7OSPEnAI4RmMnmTZ3tpvN8QmbkzB7g7sRFDkCIgB7TVGTlbMeJgcxtY5x
164 | XZ8cr2EMD7gB9YQhfjV+Emmz0HVtVFHcI8o4W3cVBfQfEv1Dom8kERHlUq0E
165 | 1NdebJ28Pr/YGsVP8fKUn8+e/+f10dnzZ/R8/uLg+Lh/yBLnL05fHz9bP613
166 | Hp6enDx/+Yw3Q+vBf/FJhmydvro4On15cLxFyIQNghAOCEwJJ4nBrVPkBkKc
167 | mcNofvjwr7NfDvd2d59++gQ/6AYQlWxTqTZ4cgw6veL7MOBclQSgHmGuGatN
168 | IrN9SN4oAD4ugOuZqpl4o8Q8sjXSi2zqUBIdF0Bi1NwuKSIUOM8W3hMHDuQK
169 | MKpz0hTFmkikOwcZJnoQhe9YJhLZlAO5Di1QQkH0Pd/SNZViZm2N3PCeVJBq
170 | 2yonUfmSohx+sQHSzPKdjLRTuAbRcegnb3HrAMKKPWYqidJpNeWEcaXVMqG0
171 | mJCj90S8zIhDeiBiLhjGEuWvRHeQbBvxzdWMmBStRczJrwhvdnmB/JXc5sOD
172 | NJckFa2EVjdKRkUFdAt4uQcQwllBsCO2hk9shtCn+7CwPnBnAlAGQZnqGcLG
173 | UJF+2pe1awIOCMElKXwrY0pBs8PQ4T5HS6M43UJPfJaigndggmhsrfqr69Bz
174 | Zc7l48EjrxQidspeBdtaY2c6ZY1S0XHqPaKsicegBhFhJJBqhNOzOceOAoe/
175 | xkZokAk10s2K+Ms3qu3rB3D4/Pkz9yy3v96k+Irdx+Ld8OtDfF1/eyTe3aEk
176 | vr67vvB2/dPXNt/Yu97d711bswvbxvwaLJL51+T2vmZ1f+zbwdqdWwaG9ntu
177 | 2dHbsNebNVx9eLthWfnbW36j5Vv2rO35hk39+Y+iVf33xwMr+8UfNo3kkz7e
178 | cVKUGmyJtn28y7rNHcmZj8nyP/C6c0N2/uPg15sHfVf0Lv04JPWT4ZenjMCa
179 | Ot/D+a8yXux/ReSNUKGafMPdgSa6px/2xT0kJ9tSNuB8MZYG7dxPW5RflNsS
180 | PCf+tPULsl7OUrdUnq1PnP+QI+bySsXG0Cs4BjGoWaD0OCVD7hIDcg3l1Vxc
181 | Y/LCnMWVq9bTKVQ1oU+SXFo30q04twuVU90w68bTuNRQ5TDGLv0+Ol6xs/Oi
182 | K3d29tGDzbsyNocpq3ICTjme833fjW1UgokACjTHoUxXSM/cfiD5UnLHcSVc
183 | G/XXsH96GOtLfxGWtjM1tSjqvaTugV0mi/IpbOuhhcre4Iq+JasT+si+crDt
184 | mg9TqZ2hjvQvWNwitH7YiuTSEOxMkYMT8Tvt1j42EDV3kXJ96lIbw6V/Rm0m
185 | je+p7SWFXv9PRV4MW81c9YWsUS2peY1NxLXilM+jRgojvmzC/wPy7hDuAcgP
186 | ueqXauhOdgbt22rDhE0DI/rHSk4j8gZPN7miiZJmtdlPQQSwXCNNRqnn7UUO
187 | 34h1R6qSRIsCLN1q3XbQQcAcQ1pqZvJxNDJhJPkyMF78OBJPRoL+CbIL/u0+
188 | ivDk4p0ZOICH/dxgIKnSlfIRB5++ZbciJK2qNN3wVavWLWe0HGMXeBIntUq2
189 | stRGB616BiRZb6dhSRBs4iTua3jDXWPs8ZTYySbsxOa1l30wEdnW1KWE2JhQ
190 | 1gBxk5iPGNywZ32f0kl1Ysgis6jstAljNIf2htVpZgR35tHxJnVUQ13EHdxB
191 | mr36jS1aWYxuYDvSIgLoYXLHVsSQ88YedN1UBrNz5oGsKtvh06lZJC41lvdl
192 | 4lLvD4NAreH5wfmxoP+AYTN+I/EHo9zLX9dCGZM82DyL0+K2XTbb/QzwIAI6
193 | 7Rw7v7DI20l7HBaYAp6/pogN56CJ2M5h22a4geRVCuHODoK4sxMJNtVpCMaI
194 | vaSIrNJ9yXp+7yeMzJWYpLwgfx01qjlXXYPfp2hhkp/wTIWqwxTBYFTLVezO
195 | rZiTzthf0+QeXEdj2LWsN3V2QVh2RjqCnurFy0S9lDXysBinVmIXNexOY7Kw
196 | CcAV1zFJxht9qcSfJwev/oTdUcOGemrrBdXY1V0Zh8qg0c0lMKyBRRWARopG
197 | 1blBlSUcVRqoeaZucAM3klFt+W59MSexR9J4HsCBWQ11jEo09z5n37SeR3cK
198 | aMW3RhBpYeV2kiDpbdztX1VDbQQlzM15lLZJs6QwERLkESKjvhCfOKAhrusG
199 | gZyZZe39LDPkaP+fBWZ1HIpSUmDxRMWbNW5NC2i0rubBa93YaMoF6yzoI3vB
200 | wpyitIvtEKz+G9hrmbe8FwAA
201 | 
202 | -->
203 | 
204 | </rfc>
205 | 
206 | 


--------------------------------------------------------------------------------
/draft-oakley-irc-ctcp-latest.mkd:
--------------------------------------------------------------------------------
  1 | ---
  2 | title: "Internet Relay Chat: Client-to-Client Protocol (CTCP)"
  3 | abbrev: IRC CTCP
  4 | docname: draft-oakley-irc-ctcp-latest
  5 | category: info
  6 | updates: 1459, 2812
  7 | 
  8 | ipr: trust200902
  9 | submissionType: independent
 10 | 
 11 | stand_alone: yes
 12 | pi:
 13 |   rfcedstyle: yes
 14 |   toc: yes
 15 |   tocindent: yes
 16 |   sortrefs: yes
 17 |   symrefs: yes
 18 |   strict: yes
 19 |   comments: yes
 20 |   inline: yes
 21 |   text-list-symbols: -o*+
 22 |   docmapping: yes
 23 | 
 24 | author:
 25 |   -
 26 |     ins: M. Mikulėnas
 27 |     name: Mantas Mikulėnas
 28 |     organization: Independent
 29 |     email: grawity@gmail.com
 30 |   -
 31 |     ins: D. Oakley
 32 |     name: Daniel Oakley
 33 |     organization: ircdocs
 34 |     role: editor
 35 |     email: daniel@danieloaks.net
 36 | 
 37 | --- abstract
 38 | 
 39 | This document describes the Client-to-Client Protocol (CTCP), which lets Internet Relay Chat (IRC) clients send each other messages that get displayed or responded to in special ways. CTCP has been widely implemented, with most clients supporting it natively. This document outlines how to implement CTCP and the most common messages.
 40 | 
 41 | This document updates RFCs 1459 and 2812.
 42 | 
 43 | --- middle
 44 | 
 45 | # Introduction
 46 | 
 47 | The core Internet Relay Chat (IRC) protocol as described in {{!RFC1459}} and {{!RFC2812}} does not provide a way to exchange computer-readable information directly between clients. The Client-to-Client Protocol (CTCP) lets them exchange messages that get processed, displayed or responded to in special ways.
 48 | 
 49 | CTCP can be used to request special formatting on messages, query other clients for metadata, and help initiate file transfers with other clients among other uses. This document covers the subset of CTCP which is commonly implemented, and clients implementing this specification are compatible with those implementing the protocol as described by older documents.
 50 | 
 51 | 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}}.
 52 | 
 53 | 
 54 | # Protocol Structure
 55 | 
 56 | CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies are sent with NOTICE command. To indicate a CTCP query or reply, the body of the message (the second parameter) begins with the CTCP delimiter.
 57 | 
 58 | Queries MAY be sent to channels. Replies MUST always be sent to the querying client only, not the channel.
 59 | 
 60 | Many servers implement filters so that only specific CTCP commands can be sent to channels. When this is done, channel operators can typically enable and disable this filtering with a channel mode.
 61 | 
 62 | 
 63 | # Message Syntax
 64 | 
 65 | The ABNF {{!RFC5234}} for CTCP message bodies is as follows:
 66 | 
 67 | ~~~abnf
 68 |   delim    = %x01
 69 | 
 70 |   command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
 71 |                 ; any octet except NUL, delim, CR, LF, and SP
 72 | 
 73 |   params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
 74 |                 ; any octet except NUL, delim, CR, and LF
 75 | 
 76 |   body     = delim command [ SP params ] [ delim ]
 77 | ~~~
 78 | {: artwork-align="center" artwork-name="syntax"}
 79 | 
 80 | Commands are case-insensitive. When creating new CTCP commands, authors SHOULD use only alphanumeric characters for ease of implementation.
 81 | 
 82 | The final CTCP delimiter SHOULD be sent on outgoing messages for compatibility reasons, but software MUST accept incoming messages which lack it.
 83 | 
 84 | In message examples throughout this document, the CTCP delimiter is shown as `\x01`.
 85 | 
 86 | Here are two examples of valid CTCP queries and replies:
 87 | 
 88 | ~~~
 89 |   :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
 90 |   :bob!b@localhost NOTICE alice :\x01VERSION Snak for Mac 4.13\x01
 91 | 
 92 |   :alice!a@localhost PRIVMSG #ircv3 :\x01PING 1473523796 918320
 93 |   :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
 94 | ~~~
 95 | 
 96 | 
 97 | # Messages
 98 | 
 99 | There is not a formal registry of CTCP message names, and CTCP responses are uniquely flexible. Clients that receive either unexpected messages or known messages with unexpected values SHOULD ignore them and send no response to the querying user.
100 | 
101 | 
102 | # Acknowledgements
103 | 
104 | Thanks to the IRCv3 group for giving feedback on this specification, and to Khaled Mardam-Bey for advice on client flood protection.
105 | 
106 | Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who wrote and revised related specifications.
107 | 
108 | Special thanks to dequis, Sadie Powell and James Wheare for help with this and related work.
109 | 
110 | 
111 | # Security Considerations
112 | 
113 | CTCP messages are completely untrusted data and clients MUST NOT assume that they are well-formed or complete.
114 | 
115 | Older CTCP specifications describe quoting methods which are complex and not widely implemented. Implementations SHOULD NOT implement "low-level quoting" or "CTCP-level quoting" when parsing messages.
116 | 
117 | CTCP requests can be abused to flood clients off the server they are connected to. Clients SHOULD ignore or delay excessive incoming requests to protect against this.
118 | 
119 | Older CTCP specifications describe including more than one CTCP message inside a single PRIVMSG or NOTICE command. Implementations SHOULD NOT implement this form of CTCP parsing as it is not widely-implemented and may result in an implementation that can be more easily flooded off the server they are connected to.
120 | 
121 | 
122 | # IANA Considerations
123 | 
124 | This document has no actions for IANA.
125 | 
126 | 
127 | --- back
128 | 
129 | 
130 | # Message List
131 | 
132 | This section is not exhaustive, and only lists those CTCP messages which are widely implemented across the IRC ecosystem. Clients MUST ONLY send params on a query if a params section is listed here.
133 | 
134 | The Query and Reply lines below represent variables by surrounding them with angle brackets.
135 | 
136 | 
137 | ## ACTION
138 | 
139 | ~~~
140 | Query:  ACTION <text>
141 | Reply:  None
142 | ~~~
143 | 
144 | Clients which implement this message MUST display \<text\> as a third-person action or emote. Users typically use the `/me` command in their IRC clients to send this message.
145 | 
146 | If \<text\> is empty, clients SHOULD still include a single space after `ACTION` (i.e. an empty params section) to help ensure compatibility. Clients SHOULD correctly parse incoming ACTION messages with or without the params section. Leading spaces in \<text\> SHOULD NOT be stripped before being displayed to users.
147 | 
148 | ACTION is universally implemented and very commonly used. Clients MUST implement this CTCP message to effectively use IRC.
149 | 
150 | Examples:
151 | 
152 | ~~~
153 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
154 | 
155 |   Formatted:  * dan does it!
156 | ~~~
157 | 
158 | ~~~
159 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION \x01
160 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION\x01
161 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION
162 | 
163 |   Formatted:  * dan
164 | ~~~
165 | 
166 | 
167 | ## CLIENTINFO
168 | 
169 | ~~~
170 | Query:  CLIENTINFO
171 | Reply:  CLIENTINFO <tokens>
172 | ~~~
173 | 
174 | Clients which implement this message MUST reply with a list of the CTCP messages they support, delimited by an ASCII space. Some legacy implementations add an extra text message at the end prefixed by a colon, as demonstrated in the examples.
175 | 
176 | CLIENTINFO is widely implemented. Clients SHOULD implement this CTCP message.
177 | 
178 | Example:
179 | 
180 | ~~~
181 |   Query:  CLIENTINFO
182 |   Reply:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
183 | ~~~
184 | 
185 | ~~~
186 |   Query:  CLIENTINFO
187 |   Reply:  CLIENTINFO CLIENTINFO PING VERSION  :Use CLIENTINFO
188 |           <COMMAND> to get more specific information
189 | ~~~
190 | 
191 | 
192 | ## DCC
193 | 
194 | ~~~
195 | Query:  DCC <type> <argument> <host> <port>
196 | Reply:  Described elsewhere.
197 | ~~~
198 | 
199 | This message sets up connections that go directly between clients, bypassing the IRC server. This is typically used for features that require a large amount of traffic (e.g. file transfers), or simply direct chat that bypasses the server.
200 | 
201 | The Direct Client-to-Client (DCC) protocol requires its own specification, and is not described in-depth here.
202 | 
203 | DCC is widely implemented. Clients MAY implement this CTCP message.
204 | 
205 | 
206 | ## FINGER
207 | 
208 | ~~~
209 | Query:  FINGER
210 | Reply:  FINGER <info>
211 | ~~~
212 | 
213 | Clients which implement this message MUST reply with miscellaneous information about the user (typically the contents of their realname/gecos field). However, some implementations return the client name and version instead.
214 | 
215 | FINGER is largely obsolete. Clients MAY implement this CTCP message.
216 | 
217 | Example:
218 | 
219 | ~~~
220 |   Query:  FINGER
221 |   Reply:  FINGER WeeChat 1.8-dev
222 | ~~~
223 | 
224 | 
225 | ## PING
226 | 
227 | ~~~
228 | Query:  PING <info>
229 | Reply:  PING <info>
230 | ~~~
231 | 
232 | Clients which implement this message MUST send a reply containing exactly the same params as the original query. However, leading spaces MAY be stripped. This message confirms reachability and latency between two clients.
233 | 
234 | PING is universally implemented. Clients SHOULD implement this CTCP message.
235 | 
236 | Example:
237 | 
238 | ~~~
239 |   Query:  PING 1473523721 662865
240 |   Reply:  PING 1473523721 662865
241 |   
242 |   Query:  PING foo bar baz
243 |   Reply:  PING foo bar baz
244 | ~~~
245 | 
246 | 
247 | ## SOURCE
248 | 
249 | ~~~
250 | Query:  SOURCE
251 | Reply:  SOURCE <info>
252 | ~~~
253 | 
254 | Clients which implement this message MUST reply with a URL where the source code for the client can be found.
255 | 
256 | SOURCE is rarely implemented. Clients MAY implement this CTCP message.
257 | 
258 | Example:
259 | 
260 | ~~~
261 |   Query:  SOURCE
262 |   Reply:  SOURCE https://weechat.org/download
263 | ~~~
264 | 
265 | 
266 | ## TIME
267 | 
268 | ~~~
269 | Query:  TIME
270 | Reply:  TIME <timestring>
271 | ~~~
272 | 
273 | Clients which implement this message MUST reply with the client's local time in a human-readable format. In practice, both the format returned by ctime() and the format described in Section 3.3 of {{!RFC5322}} are common. Earlier specifications recommended prefixing the time string with a colon, but this is no longer recommended.
274 | 
275 | Clients MAY default to UTC time for privacy reasons and only respond with the local time if the user enables it.
276 | 
277 | TIME is almost universally implemented. Clients MAY implement this CTCP message.
278 | 
279 | Example:
280 | 
281 | ~~~
282 |   Query:  TIME
283 |   Reply:  TIME Mon, 08 May 2017 09:15:29 GMT
284 | ~~~
285 | 
286 | 
287 | ## VERSION
288 | 
289 | ~~~
290 | Query:  VERSION
291 | Reply:  VERSION <verstring>
292 | ~~~
293 | 
294 | Clients which implement this message MUST reply with the name and version of the client software in use. There is no specified format for the version string.
295 | 
296 | Clients MAY receive more than one reply after sending a VERSION query. Clients may allow users to customise the response value for this query.
297 | 
298 | VERSION is universally implemented. Clients SHOULD implement this CTCP message.
299 | 
300 | Example:
301 | 
302 | ~~~
303 |   Query:  VERSION
304 |   Reply:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
305 | ~~~
306 | 
307 | 
308 | ## USERINFO
309 | 
310 | ~~~
311 | Query:  USERINFO
312 | Reply:  USERINFO <info>
313 | ~~~
314 | 
315 | Clients which implement this message MUST reply with miscellaneous information about the user (typically the contents of their realname/gecos field).
316 | 
317 | USERINFO is largely obsolete. Clients MAY implement this CTCP message.
318 | 
319 | Example:
320 | 
321 | ~~~
322 |   Query:  USERINFO
323 |   Reply:  USERINFO fred (Fred Foobar)
324 | ~~~
325 | 
326 | # Change History \[RFC Editor: Please remove this section\]
327 | 
328 | Changes from draft 2 (... 2021)
329 | 
330 | - Removed the CTCP Types section (thanks James).
331 | - Added advice on leading spaces in messages (thanks Sadie).
332 | - Minor ABNF fix.
333 | 
334 | Changes from draft 1 (July 18, 2017)
335 | 
336 | - General editing, fixed mistypes.
337 | - Simplified some of the examples.
338 | 
339 | Changes from draft 0 (May 29, 2017)
340 | 
341 | - Added note about servers truncating CTCP messages (thanks Sadie).
342 | - Fixed misspellings and added note to TIME about previously-recommended prefix (thanks Patrick).
343 | - Mentioned how to parse/send empty ACTION messages (thanks dequis and the crew).
344 | 


--------------------------------------------------------------------------------
/versions/ctcp/draft-oakley-irc-ctcp-00.mkd:
--------------------------------------------------------------------------------
  1 | ---
  2 | coding: utf-8
  3 | 
  4 | title: "Internet Relay Chat: Client-to-Client Protocol (CTCP)"
  5 | abbrev: IRC Client-to-Client Protocol
  6 | docname: draft-oakley-irc-ctcp-00
  7 | 
  8 | submissionType: independent
  9 | category: info
 10 | 
 11 | stand_alone: yes
 12 | pi: [toc, sortrefs, symrefs, comments]
 13 | 
 14 | updates: 1459, 2812
 15 | 
 16 | author:
 17 |   -
 18 |     #ins: M. Mikulėnas
 19 |     #name: Mantas Mikulėnas
 20 |     ins: M. Mikulenas
 21 |     name: Mantas Mikulenas
 22 |     org: Independent
 23 |     email: grawity@gmail.com
 24 |   -
 25 |     ins: D. Oakley
 26 |     name: Daniel Oakley
 27 |     org: ircdocs
 28 |     email: daniel@danieloaks.net
 29 | 
 30 | --- abstract
 31 | 
 32 | This document describes the Client-to-Client Protocol (CTCP), which lets Internet Relay Chat (IRC) clients send each other messages that get displayed or responded to in special ways. CTCP has been widely implemented, with most clients supporting it natively. This document outlines how to implement CTCP and the most common messages used.
 33 | 
 34 | It updates RFC 1459 and RFC 2812.
 35 | 
 36 | --- middle
 37 | 
 38 | # Introduction
 39 | 
 40 | The core Internet Relay Chat (IRC) protocol as described in {{!RFC1459}} and {{!RFC2812}} only has a single command for regular user messages, and does not provide a way for clients to exchange information directly. Client-to-Client Protocol (CTCP) messages let clients exchange messages that get displayed or responded to in special ways. Some examples of how CTCP is used is to request special formatting on messages, query other clients for metadata, and help initiate file transfers with other clients.
 41 | 
 42 | This document goes over the subset of CTCP which is commonly implemented, and is compatible with clients implementing CTCP as described by older documents.
 43 | 
 44 | 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}}.
 45 | 
 46 | 
 47 | # Message Syntax
 48 | 
 49 | CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies are sent with NOTICE command. To indicate a CTCP query or reply, the body of the message (the second parameter) begins with the CTCP delimiter. The ABNF {{!RFC5234}} for this message body is as follows:
 50 | 
 51 | ~~~abnf
 52 |   delim    = %x01
 53 | 
 54 |   command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
 55 |                 ; any octet except NUL, delim, CR, LF, and " "
 56 | 
 57 |   params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
 58 |                 ; any octet except NUL, delim, CR, and LF
 59 | 
 60 |   body     = delim command [ SPACE params ] [ delim ]
 61 | ~~~
 62 | {: artwork-align="center" artwork-name="syntax"}
 63 | 
 64 | Commands are case-insensitive. When creating new CTCP commands, authors SHOULD use only alphanumeric characters for ease of implementation.
 65 | 
 66 | The final CTCP delimiter SHOULD be sent on outgoing messages for compatibility reasons, and software MUST accept incoming messages which lack it. This is due to how certain clients implement message splitting and truncation.
 67 | 
 68 | Queries MAY be sent to channels. When these queries are responded to, the responses are sent to the querying client rather than the channel which the query was originally sent to.
 69 | 
 70 | Many servers implement optional filtering so that only the ACTION CTCP message can be sent to channels. When this is done, it can typically be enabled or disabled by channel operators with a channel mode.
 71 | 
 72 | Here are two examples of CTCP queries and replies:
 73 | 
 74 | ~~~
 75 |   :alice PRIVMSG bob :\x01VERSION\x01
 76 |   :bob NOTICE alice :\x01VERSION Snak for Macintosh 4.13 English\x01
 77 | 
 78 |   :alice PRIVMSG #ircv3 :\x01PING 1473523796 918320\x01
 79 |   :bob NOTICE alice :\x01PING 1473523796 918320\x01
 80 | ~~~
 81 | 
 82 | 
 83 | # Message Types
 84 | 
 85 | CTCP messages generally take on one of these types. These message types are defined here to simplify understanding, and aren’t differentiated by the protocol itself.
 86 | 
 87 | 
 88 | ## Extended formatting
 89 | 
 90 | This type of CTCP is used to request special formatting of a user-visible message. That is, to send a user-visible message that should be displayed differently from regular messages - e.g. as an action, a whisper, an announcement.
 91 | 
 92 | Extended formatting messages are sent as a PRIVMSG, and are expected to be used in channels as well as between clients. There is no automatic response to this message type, as it is not a query nor reply.
 93 | 
 94 | These messages are sent as a PRIVMSG and can have parameters, but generate no reply.
 95 | 
 96 | Example:
 97 | 
 98 | ~~~
 99 |   :dan PRIVMSG #ircv3 :\x01ACTION writes some specs!\x01
100 | ~~~
101 | 
102 | 
103 | ## Metadata Query
104 | 
105 | This type of CTCP is used to provide relatively static information about the target client, user or connection.
106 | 
107 | This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively). Due to how bouncers interact with multiple clients, there may sometimes be multiple responses to queries.
108 | 
109 | Metadata queries MUST NOT require the recipient to implement any side effects (beyond sending the reply itself); if a CTCP message causes side effects by design, it should be categorized as an extended query instead.
110 | 
111 | Metadata queries do not have any parameters, but expect a reply with parameters as the response data.
112 | 
113 | Example:
114 | 
115 | ~~~
116 |   :alice PRIVMSG bob :\x01VERSION\x01
117 |   :bob NOTICE alice :\x01VERSION SaberChat 27.5\x01
118 | ~~~
119 | 
120 | 
121 | ## Extended Query
122 | 
123 | This type of CTCP is used to provide dynamic information or invoke actions from the client.
124 | 
125 | This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively).
126 | 
127 | Queries sent to a channel always generate private replies.
128 | 
129 | Extended queries and replies may have parameters.
130 | 
131 | Example:
132 | 
133 | ~~~
134 |   :alice PRIVMSG bob :\x01PING 1473523796 918320\x01
135 |   :bob NOTICE alice :\x01PING 1473523796 918320\x01
136 | ~~~
137 | 
138 | 
139 | # Messages
140 | 
141 | CTCP messages themselves are not standardised. Clients that receive either unexpected messages or known messages with unexpected values SHOULD ignore them and produce no response to the sending user. Clients MAY receive more than one response per user for a query they send, due to multiple clients being connected behind an IRC bouncer.
142 | 
143 | 
144 | # Acknowledgements
145 | 
146 | Thanks to the IRCv3 group for giving feedback on this specification, and to Khaled for advice on client flood protection.
147 | 
148 | Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who wrote and revised related specifications.
149 | 
150 | Special thanks to dequis, Peter Powell and James Wheare for help with this and related work.
151 | 
152 | 
153 | # Security Considerations
154 | 
155 | CTCP messages are completely untrusted data, and clients MUST NOT assume that they are well-formed or complete.
156 | 
157 | Older CTCP specifications describe quoting methods which are complex and not widely implemented. Implementations SHOULD NOT implement "low-level quoting" or "CTCP-level quoting" when parsing messages.
158 | 
159 | Older CTCP specifications describe including more than one CTCP message inside a single PRIVMSG or NOTICE command. Implementations SHOULD NOT implement this form of CTCP parsing as it is not widely-implemented and may result in an implementation that can be more easily flooded off the server they are connected to.
160 | 
161 | CTCP requests can be abused to flood clients off the server they are connected to. Clients may ignore or delay excessive incoming requests to protect against this.
162 | 
163 | 
164 | # IANA Considerations
165 | 
166 | This document has no actions for IANA.
167 | 
168 | 
169 | --- back
170 | 
171 | 
172 | # Message List
173 | 
174 | This section is not exhaustive, and only lists those CTCP messages which are widely implemented across the IRC ecosystem.
175 | 
176 | The reply and parameter lines below use a simplified syntax that represents variables by surrounding them with angle brackets,.
177 | 
178 | 
179 | ## ACTION
180 | 
181 | ~~~
182 | Type:    Extended Formatting
183 | Params:  ACTION <text>
184 | ~~~
185 | 
186 | This extended formatting message shows that \<text\> should be displayed as a third-person action or emote; in clients, it’s generally activated with the command `/me`.
187 | 
188 | ACTION is universally implemented and very commonly used. Clients MUST implement this CTCP message to effectively use IRC.
189 | 
190 | Example:
191 | 
192 | ~~~
193 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
194 | 
195 |   Formatted:  * dan does it!
196 | ~~~
197 | 
198 | 
199 | ## CLIENTINFO
200 | 
201 | ~~~
202 | Type:   Extended Query
203 | Reply:  CLIENTINFO <tokens>
204 | ~~~
205 | 
206 | This extended query returns a list of the CTCP messages that this client supports and implements, delimited by a single ASCII space.
207 | 
208 | CLIENTINFO is widely implemented. Clients SHOULD implement this CTCP message.
209 | 
210 | Example:
211 | 
212 | ~~~
213 |   Query:     CLIENTINFO
214 |   Response:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
215 | ~~~
216 | 
217 | 
218 | ## DCC
219 | 
220 | ~~~
221 | Type:    Extended Query
222 | Params:  DCC <type> <argument> <host> <port>
223 | ~~~
224 | 
225 | This extended query is used to setup and control connections that go directly between clients, bypassing the IRC server. This is typically used for features that require a large amount of traffic between clients or simply wish to bypass the server itself such as file transfer and direct chat.
226 | 
227 | The Direct Client-to-Client (DCC) Protocol requires its own specification, and is not described in-depth here.
228 | 
229 | DCC is widely implemented. Clients MAY implement this CTCP message.
230 | 
231 | 
232 | ## FINGER
233 | 
234 | ~~~
235 | Type:   Metadata Query
236 | Reply:  FINGER <info>
237 | ~~~
238 | 
239 | This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.
240 | 
241 | However, some implementations return the client name and version instead.
242 | 
243 | FINGER is largely obsolete. Clients MAY implement this CTCP message.
244 | 
245 | Example:
246 | 
247 | ~~~
248 |   Query:     FINGER
249 |   Response:  FINGER WeeChat 1.8-dev
250 | ~~~
251 | 
252 | 
253 | ## PING
254 | 
255 | ~~~
256 | Type:    Extended Query
257 | Params:  PING <info>
258 | ~~~
259 | 
260 | This extended query is used to confirm reachability with other clients and to check latency. When receiving a CTCP PING, the reply MUST contain exactly the same parameters as the original query.
261 | 
262 | PING is universally implemented. Clients SHOULD implement this CTCP message.
263 | 
264 | Example:
265 | 
266 | ~~~
267 |   Query:     PING 1473523721 662865
268 |   Response:  PING 1473523721 662865
269 |   
270 |   Query:     PING foo bar baz
271 |   Response:  PING foo bar baz
272 | ~~~
273 | 
274 | 
275 | ## SOURCE
276 | 
277 | ~~~
278 | Type:   Metadata Query
279 | Reply:  SOURCE <info>
280 | ~~~
281 | 
282 | This metadata query is used to return the location of the source code for the client.
283 | 
284 | SOURCE is rarely implemented. Clients MAY implement this CTCP message.
285 | 
286 | Example:
287 | 
288 | ~~~
289 |   Query:     SOURCE
290 |   Response:  SOURCE https://weechat.org/download
291 | ~~~
292 | 
293 | 
294 | ## TIME
295 | 
296 | ~~~
297 | Type:    Extended Query
298 | Params:  TIME <timestring>
299 | ~~~
300 | 
301 | This extended query is used to return the client’s local time in an unspecified human-readable format. In practice, both the format output by ctime() and the format described in Section 3.3 of {{!RFC5322}} are common.
302 | 
303 | New implementations MAY default to UTC time for privacy reasons.
304 | 
305 | TIME is almost universally implemented. Clients SHOULD implement this CTCP message.
306 | 
307 | Example:
308 | 
309 | ~~~
310 |   Query:     TIME
311 |   Response:  TIME Mon, 08 May 2017 09:15:29 GMT
312 | ~~~
313 | 
314 | 
315 | ## VERSION
316 | 
317 | ~~~
318 | Type:   Metadata Query
319 | Reply:  VERSION <verstring>
320 | ~~~
321 | 
322 | This metadata query is used to return the name and version of the client software in use. There is no specified format for the version string.
323 | 
324 | Clients may allow users to customise the response value for this query.
325 | 
326 | VERSION is universally implemented. Clients SHOULD implement this CTCP message.
327 | 
328 | Example:
329 | 
330 | ~~~
331 |   Query:     VERSION
332 |   Response:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
333 | ~~~
334 | 
335 | 
336 | ## USERINFO
337 | 
338 | ~~~
339 | Type:   Metadata Query
340 | Reply:  USERINFO <info>
341 | ~~~
342 | 
343 | This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.
344 | 
345 | However, some implementations return `<nickname> (<realname>)` instead.
346 | 
347 | USERINFO is largely obsolete. Clients MAY implement this CTCP message.
348 | 
349 | Example:
350 | 
351 | ~~~
352 |   Query:     USERINFO
353 |   Response:  USERINFO fred (Fred Foobar)
354 | ~~~
355 | 


--------------------------------------------------------------------------------
/versions/ctcp/draft-oakley-irc-ctcp-01.mkd:
--------------------------------------------------------------------------------
  1 | ---
  2 | coding: utf-8
  3 | 
  4 | title: "Internet Relay Chat: Client-to-Client Protocol (CTCP)"
  5 | abbrev: IRC Client-to-Client Protocol
  6 | docname: draft-oakley-irc-ctcp-01
  7 | 
  8 | submissionType: independent
  9 | category: info
 10 | 
 11 | stand_alone: yes
 12 | pi: [toc, sortrefs, symrefs, comments]
 13 | 
 14 | updates: 1459, 2812
 15 | 
 16 | author:
 17 |   -
 18 |     #ins: M. Mikulėnas
 19 |     #name: Mantas Mikulėnas
 20 |     ins: M. Mikulenas
 21 |     name: Mantas Mikulenas
 22 |     org: Independent
 23 |     email: grawity@gmail.com
 24 |   -
 25 |     ins: D. Oakley
 26 |     name: Daniel Oakley
 27 |     org: ircdocs
 28 |     email: daniel@danieloaks.net
 29 | 
 30 | --- abstract
 31 | 
 32 | This document describes the Client-to-Client Protocol (CTCP), which lets Internet Relay Chat (IRC) clients send each other messages that get displayed or responded to in special ways. CTCP has been widely implemented, with most clients supporting it natively. This document outlines how to implement CTCP and the most common messages used.
 33 | 
 34 | It updates RFC 1459 and RFC 2812.
 35 | 
 36 | --- middle
 37 | 
 38 | # Introduction
 39 | 
 40 | The core Internet Relay Chat (IRC) protocol as described in {{!RFC1459}} and {{!RFC2812}} only has a single command for regular user messages, and does not provide a way for clients to exchange information directly. Client-to-Client Protocol (CTCP) messages let clients exchange messages that get displayed or responded to in special ways. Some examples of how CTCP is used is to request special formatting on messages, query other clients for metadata, and help initiate file transfers with other clients.
 41 | 
 42 | This document goes over the subset of CTCP which is commonly implemented, and is compatible with clients implementing CTCP as described by older documents.
 43 | 
 44 | 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}}.
 45 | 
 46 | 
 47 | # Message Syntax
 48 | 
 49 | CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies are sent with NOTICE command. To indicate a CTCP query or reply, the body of the message (the second parameter) begins with the CTCP delimiter. The ABNF {{!RFC5234}} for this message body is as follows:
 50 | 
 51 | ~~~abnf
 52 |   delim    = %x01
 53 | 
 54 |   command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
 55 |                 ; any octet except NUL, delim, CR, LF, and " "
 56 | 
 57 |   params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
 58 |                 ; any octet except NUL, delim, CR, and LF
 59 | 
 60 |   body     = delim command [ SPACE params ] [ delim ]
 61 | ~~~
 62 | {: artwork-align="center" artwork-name="syntax"}
 63 | 
 64 | Commands are case-insensitive. When creating new CTCP commands, authors SHOULD use only alphanumeric characters for ease of implementation.
 65 | 
 66 | The final CTCP delimiter SHOULD be sent on outgoing messages for compatibility reasons, and software MUST accept incoming messages which lack it. This is due to how servers implement message truncation and certain clients implement message splitting.
 67 | 
 68 | Queries MAY be sent to channels. When these queries are responded to, the responses are sent to the querying client rather than the channel which the query was originally sent to.
 69 | 
 70 | Many servers implement optional filtering so that only the ACTION CTCP message can be sent to channels. When this is done, it can typically be enabled or disabled by channel operators with a channel mode.
 71 | 
 72 | Here are two examples of CTCP queries and replies:
 73 | 
 74 | ~~~
 75 |   :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
 76 |   :bob!b@localhost NOTICE alice :\x01VERSION Snak for Mac 4.13\x01
 77 | 
 78 |   :alice!a@localhost PRIVMSG #ircv3 :\x01PING 1473523796 918320\x01
 79 |   :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
 80 | ~~~
 81 | 
 82 | 
 83 | # Message Types
 84 | 
 85 | CTCP messages generally take on one of these types. These message types are defined here to simplify understanding, and aren’t differentiated by the protocol itself.
 86 | 
 87 | 
 88 | ## Extended formatting
 89 | 
 90 | This type of CTCP is used to request special formatting of a user-visible message. That is, to send a user-visible message that should be displayed differently from regular messages - e.g. as an action, a whisper, an announcement.
 91 | 
 92 | Extended formatting messages are sent as a PRIVMSG, and are expected to be used in channels as well as between clients. There is no automatic response to this message type, as it is not a query nor reply.
 93 | 
 94 | These messages are sent as a PRIVMSG and can have parameters, but generate no reply.
 95 | 
 96 | Example:
 97 | 
 98 | ~~~
 99 |   :dan!u@localhost PRIVMSG #ircv3 :\x01ACTION writes some specs!\x01
100 | ~~~
101 | 
102 | 
103 | ## Metadata Query
104 | 
105 | This type of CTCP is used to provide relatively static information about the target client, user or connection.
106 | 
107 | This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively). Due to how bouncers interact with multiple clients, there may sometimes be multiple responses to queries.
108 | 
109 | Metadata queries MUST NOT require the recipient to implement any side effects (beyond sending the reply itself); if a CTCP message causes side effects by design, it should be categorized as an extended query instead.
110 | 
111 | Metadata queries do not have any parameters, but expect a reply with parameters as the response data.
112 | 
113 | Example:
114 | 
115 | ~~~
116 |   :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
117 |   :bob!b@localhost NOTICE alice :\x01VERSION SaberChat 27.5\x01
118 | ~~~
119 | 
120 | 
121 | ## Extended Query
122 | 
123 | This type of CTCP is used to provide dynamic information or invoke actions from the client.
124 | 
125 | This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively).
126 | 
127 | Queries sent to a channel always generate private replies.
128 | 
129 | Extended queries and replies may have parameters.
130 | 
131 | Example:
132 | 
133 | ~~~
134 |   :alice!a@localhost PRIVMSG bob :\x01PING 1473523796 918320\x01
135 |   :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
136 | ~~~
137 | 
138 | 
139 | # Messages
140 | 
141 | CTCP messages themselves are not standardised. Clients that receive either unexpected messages or known messages with unexpected values SHOULD ignore them and produce no response to the sending user. Clients MAY receive more than one response per user for a query they send, due to multiple clients being connected behind an IRC bouncer.
142 | 
143 | 
144 | # Acknowledgements
145 | 
146 | Thanks to the IRCv3 group for giving feedback on this specification, and to Khaled for advice on client flood protection.
147 | 
148 | Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who wrote and revised related specifications.
149 | 
150 | Special thanks to dequis, Peter Powell and James Wheare for help with this and related work.
151 | 
152 | 
153 | # Security Considerations
154 | 
155 | CTCP messages are completely untrusted data, and clients MUST NOT assume that they are well-formed or complete.
156 | 
157 | Older CTCP specifications describe quoting methods which are complex and not widely implemented. Implementations SHOULD NOT implement "low-level quoting" or "CTCP-level quoting" when parsing messages.
158 | 
159 | Older CTCP specifications describe including more than one CTCP message inside a single PRIVMSG or NOTICE command. Implementations SHOULD NOT implement this form of CTCP parsing as it is not widely-implemented and may result in an implementation that can be more easily flooded off the server they are connected to.
160 | 
161 | CTCP requests can be abused to flood clients off the server they are connected to. Clients may ignore or delay excessive incoming requests to protect against this.
162 | 
163 | 
164 | # IANA Considerations
165 | 
166 | This document has no actions for IANA.
167 | 
168 | 
169 | --- back
170 | 
171 | 
172 | # Message List
173 | 
174 | This section is not exhaustive, and only lists those CTCP messages which are widely implemented across the IRC ecosystem.
175 | 
176 | The reply and parameter lines below use a simplified syntax that represents variables by surrounding them with angle brackets.
177 | 
178 | 
179 | ## ACTION
180 | 
181 | ~~~
182 | Type:    Extended Formatting
183 | Params:  ACTION <text>
184 | ~~~
185 | 
186 | This extended formatting message shows that \<text\> should be displayed as a third-person action or emote; in clients, it’s generally activated with the command `/me`.
187 | 
188 | If \<text\> is empty, clients SHOULD still include a single space after `ACTION` (i.e. an empty params section) to help compatibility. Clients SHOULD correctly parse incoming ACTION messages with or without the params section.
189 | 
190 | ACTION is universally implemented and very commonly used. Clients MUST implement this CTCP message to effectively use IRC.
191 | 
192 | Examples:
193 | 
194 | ~~~
195 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
196 | 
197 |   Formatted:  * dan does it!
198 | ~~~
199 | 
200 | ~~~
201 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION \x01
202 | 
203 |   Formatted:  * dan
204 | ~~~
205 | 
206 | ~~~
207 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION\x01
208 | 
209 |   Formatted:  * dan
210 | ~~~
211 | 
212 | 
213 | ## CLIENTINFO
214 | 
215 | ~~~
216 | Type:   Extended Query
217 | Reply:  CLIENTINFO <tokens>
218 | ~~~
219 | 
220 | This extended query returns a list of the CTCP messages that this client supports and implements, delimited by a single ASCII space.
221 | 
222 | CLIENTINFO is widely implemented. Clients SHOULD implement this CTCP message.
223 | 
224 | Example:
225 | 
226 | ~~~
227 |   Query:     CLIENTINFO
228 |   Response:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
229 | ~~~
230 | 
231 | 
232 | ## DCC
233 | 
234 | ~~~
235 | Type:    Extended Query
236 | Params:  DCC <type> <argument> <host> <port>
237 | ~~~
238 | 
239 | This extended query is used to setup and control connections that go directly between clients, bypassing the IRC server. This is typically used for features that require a large amount of traffic between clients or simply wish to bypass the server itself such as file transfer and direct chat.
240 | 
241 | The Direct Client-to-Client (DCC) Protocol requires its own specification, and is not described in-depth here.
242 | 
243 | DCC is widely implemented. Clients MAY implement this CTCP message.
244 | 
245 | 
246 | ## FINGER
247 | 
248 | ~~~
249 | Type:   Metadata Query
250 | Reply:  FINGER <info>
251 | ~~~
252 | 
253 | This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.
254 | 
255 | However, some implementations return the client name and version instead.
256 | 
257 | FINGER is largely obsolete. Clients MAY implement this CTCP message.
258 | 
259 | Example:
260 | 
261 | ~~~
262 |   Query:     FINGER
263 |   Response:  FINGER WeeChat 1.8-dev
264 | ~~~
265 | 
266 | 
267 | ## PING
268 | 
269 | ~~~
270 | Type:    Extended Query
271 | Params:  PING <info>
272 | ~~~
273 | 
274 | This extended query is used to confirm reachability with other clients and to check latency. When receiving a CTCP PING, the reply MUST contain exactly the same parameters as the original query.
275 | 
276 | PING is universally implemented. Clients SHOULD implement this CTCP message.
277 | 
278 | Example:
279 | 
280 | ~~~
281 |   Query:     PING 1473523721 662865
282 |   Response:  PING 1473523721 662865
283 |   
284 |   Query:     PING foo bar baz
285 |   Response:  PING foo bar baz
286 | ~~~
287 | 
288 | 
289 | ## SOURCE
290 | 
291 | ~~~
292 | Type:   Metadata Query
293 | Reply:  SOURCE <info>
294 | ~~~
295 | 
296 | This metadata query is used to return the location of the source code for the client.
297 | 
298 | SOURCE is rarely implemented. Clients MAY implement this CTCP message.
299 | 
300 | Example:
301 | 
302 | ~~~
303 |   Query:     SOURCE
304 |   Response:  SOURCE https://weechat.org/download
305 | ~~~
306 | 
307 | 
308 | ## TIME
309 | 
310 | ~~~
311 | Type:    Extended Query
312 | Params:  TIME <timestring>
313 | ~~~
314 | 
315 | This extended query is used to return the client’s local time in an unspecified human-readable format. In practice, both the format output by ctime() and the format described in Section 3.3 of {{!RFC5322}} are common. Earlier specifications recommended to prefix the time string with a colon, but this is no longer recommended.
316 | 
317 | New implementations MAY default to UTC time for privacy reasons.
318 | 
319 | TIME is almost universally implemented. Clients SHOULD implement this CTCP message.
320 | 
321 | Example:
322 | 
323 | ~~~
324 |   Query:     TIME
325 |   Response:  TIME Mon, 08 May 2017 09:15:29 GMT
326 | ~~~
327 | 
328 | 
329 | ## VERSION
330 | 
331 | ~~~
332 | Type:   Metadata Query
333 | Reply:  VERSION <verstring>
334 | ~~~
335 | 
336 | This metadata query is used to return the name and version of the client software in use. There is no specified format for the version string.
337 | 
338 | Clients may allow users to customise the response value for this query.
339 | 
340 | VERSION is universally implemented. Clients SHOULD implement this CTCP message.
341 | 
342 | Example:
343 | 
344 | ~~~
345 |   Query:     VERSION
346 |   Response:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
347 | ~~~
348 | 
349 | 
350 | ## USERINFO
351 | 
352 | ~~~
353 | Type:   Metadata Query
354 | Reply:  USERINFO <info>
355 | ~~~
356 | 
357 | This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.
358 | 
359 | However, some implementations return `<nickname> (<realname>)` instead.
360 | 
361 | USERINFO is largely obsolete. Clients MAY implement this CTCP message.
362 | 
363 | Example:
364 | 
365 | ~~~
366 |   Query:     USERINFO
367 |   Response:  USERINFO fred (Fred Foobar)
368 | ~~~
369 | 
370 | # Change History \[RFC Editor: Please remove this section\]
371 | 
372 | Changes from draft 0 (May 29, 2017)
373 | 
374 | - Added note about servers truncating CTCP messages (thanks Peter).
375 | - Fixed misspellings and added note to TIME about previously-recommended prefix (thanks Patrick).
376 | - Mentioned how to parse/send empty ACTION messages (thanks dequis and the crew).
377 | 


--------------------------------------------------------------------------------
/versions/ctcp/draft-oakley-irc-ctcp-02.mkd:
--------------------------------------------------------------------------------
  1 | ---
  2 | coding: utf-8
  3 | 
  4 | title: "Internet Relay Chat: Client-to-Client Protocol (CTCP)"
  5 | abbrev: IRC Client-to-Client Protocol
  6 | docname: draft-oakley-irc-ctcp-02
  7 | 
  8 | submissionType: independent
  9 | category: info
 10 | 
 11 | stand_alone: yes
 12 | pi: [toc, sortrefs, symrefs, comments]
 13 | 
 14 | updates: 1459, 2812
 15 | 
 16 | author:
 17 |   -
 18 |     #ins: M. Mikulėnas
 19 |     #name: Mantas Mikulėnas
 20 |     ins: M. Mikulenas
 21 |     name: Mantas Mikulenas
 22 |     org: Independent
 23 |     email: grawity@gmail.com
 24 |   -
 25 |     ins: D. Oakley
 26 |     name: Daniel Oakley
 27 |     org: ircdocs
 28 |     email: daniel@danieloaks.net
 29 | 
 30 | --- abstract
 31 | 
 32 | This document describes the Client-to-Client Protocol (CTCP), which lets Internet Relay Chat (IRC) clients send each other messages that get displayed or responded to in special ways. CTCP has been widely implemented, with most clients supporting it natively. This document outlines how to implement CTCP and the most common messages used.
 33 | 
 34 | It updates RFC 1459 and RFC 2812.
 35 | 
 36 | --- middle
 37 | 
 38 | # Introduction
 39 | 
 40 | The core Internet Relay Chat (IRC) protocol as described in {{!RFC1459}} and {{!RFC2812}} only has a single command for regular user messages, and does not provide a way for clients to exchange information directly. Client-to-Client Protocol (CTCP) messages let clients exchange messages that get displayed or responded to in special ways. Some examples of how CTCP is used is to request special formatting on messages, query other clients for metadata, and help initiate file transfers with other clients.
 41 | 
 42 | This document goes over the subset of CTCP which is commonly implemented, and is compatible with clients implementing CTCP as described by older documents.
 43 | 
 44 | 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}}.
 45 | 
 46 | 
 47 | # Message Syntax
 48 | 
 49 | CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies are sent with NOTICE command. To indicate a CTCP query or reply, the body of the message (the second parameter) begins with the CTCP delimiter. The ABNF {{!RFC5234}} for this message body is as follows:
 50 | 
 51 | ~~~abnf
 52 |   delim    = %x01
 53 | 
 54 |   command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
 55 |                 ; any octet except NUL, delim, CR, LF, and " "
 56 | 
 57 |   params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
 58 |                 ; any octet except NUL, delim, CR, and LF
 59 | 
 60 |   body     = delim command [ SPACE params ] [ delim ]
 61 | ~~~
 62 | {: artwork-align="center" artwork-name="syntax"}
 63 | 
 64 | Commands are case-insensitive. When creating new CTCP commands, authors SHOULD use only alphanumeric characters for ease of implementation.
 65 | 
 66 | The final CTCP delimiter SHOULD be sent on outgoing messages for compatibility reasons, and software MUST accept incoming messages which lack it. This is due to how servers implement message truncation and certain clients implement message splitting.
 67 | 
 68 | Queries MAY be sent to channels. When these queries are responded to, the responses are sent to the querying client rather than the channel which the query was originally sent to.
 69 | 
 70 | Many servers implement optional filtering so that only the ACTION CTCP message can be sent to channels. When this is done, it can typically be enabled or disabled by channel operators with a channel mode.
 71 | 
 72 | Here are two examples of CTCP queries and replies:
 73 | 
 74 | ~~~
 75 |   :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
 76 |   :bob!b@localhost NOTICE alice :\x01VERSION Snak for Mac 4.13\x01
 77 | 
 78 |   :alice!a@localhost PRIVMSG #ircv3 :\x01PING 1473523796 918320\x01
 79 |   :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
 80 | ~~~
 81 | 
 82 | 
 83 | # Message Types
 84 | 
 85 | CTCP messages generally take on one of these types. These message types are defined here to simplify understanding, and aren’t differentiated by the protocol itself.
 86 | 
 87 | 
 88 | ## Extended formatting
 89 | 
 90 | This type of CTCP requests special formatting of a user-visible message. That is, to send a user-visible message that should be displayed differently from regular messages - e.g. as an action, a whisper, an announcement.
 91 | 
 92 | Extended formatting messages are sent as a PRIVMSG, and are expected to be used in channels as well as between clients. There is no automatic response to this message type, as it is not a query nor reply.
 93 | 
 94 | These messages are sent as a PRIVMSG and can have parameters, but generate no reply.
 95 | 
 96 | Example:
 97 | 
 98 | ~~~
 99 |   :dan!u@localhost PRIVMSG #ircv3 :\x01ACTION writes some specs!\x01
100 | ~~~
101 | 
102 | 
103 | ## Metadata Query
104 | 
105 | This type of CTCP provides relatively static information about the target client, user or connection.
106 | 
107 | This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively). Due to how bouncers interact with multiple clients, there may sometimes be multiple responses to queries.
108 | 
109 | Metadata queries MUST NOT require the recipient to implement any side effects (beyond sending the reply itself); if a CTCP message causes side effects by design, it should be categorized as an extended query instead.
110 | 
111 | Metadata queries do not have any parameters, but expect a reply with parameters as the response data.
112 | 
113 | Example:
114 | 
115 | ~~~
116 |   :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
117 |   :bob!b@localhost NOTICE alice :\x01VERSION SaberChat 27.5\x01
118 | ~~~
119 | 
120 | 
121 | ## Extended Query
122 | 
123 | This type of CTCP provides dynamic information or invoke actions from the client.
124 | 
125 | This CTCP takes the form of a query and a response (as a PRIVMSG and NOTICE, respectively).
126 | 
127 | Queries sent to a channel always generate private replies.
128 | 
129 | Extended queries and replies may have parameters.
130 | 
131 | Example:
132 | 
133 | ~~~
134 |   :alice!a@localhost PRIVMSG bob :\x01PING 1473523796 918320\x01
135 |   :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
136 | ~~~
137 | 
138 | 
139 | # Messages
140 | 
141 | CTCP messages themselves are not standardised. Clients that receive either unexpected messages or known messages with unexpected values SHOULD ignore them and produce no response to the sending user. Clients MAY receive more than one response per user for a query they send, due to multiple clients being connected behind an IRC bouncer.
142 | 
143 | 
144 | # Acknowledgements
145 | 
146 | Thanks to the IRCv3 group for giving feedback on this specification, and to Khaled for advice on client flood protection.
147 | 
148 | Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who wrote and revised related specifications.
149 | 
150 | Special thanks to dequis, Sadie and James Wheare for help with this and related work.
151 | 
152 | 
153 | # Security Considerations
154 | 
155 | CTCP messages are completely untrusted data, and clients MUST NOT assume that they are well-formed or complete.
156 | 
157 | Older CTCP specifications describe quoting methods which are complex and not widely implemented. Implementations SHOULD NOT implement "low-level quoting" or "CTCP-level quoting" when parsing messages.
158 | 
159 | Older CTCP specifications describe including more than one CTCP message inside a single PRIVMSG or NOTICE command. Implementations SHOULD NOT implement this form of CTCP parsing as it is not widely-implemented and may result in an implementation that can be more easily flooded off the server they are connected to.
160 | 
161 | CTCP requests can be abused to flood clients off the server they are connected to. Clients may ignore or delay excessive incoming requests to protect against this.
162 | 
163 | 
164 | # IANA Considerations
165 | 
166 | This document has no actions for IANA.
167 | 
168 | 
169 | --- back
170 | 
171 | 
172 | # Message List
173 | 
174 | This section is not exhaustive, and only lists those CTCP messages which are widely implemented across the IRC ecosystem.
175 | 
176 | The reply and parameter lines below use a simplified syntax that represents variables by surrounding them with angle brackets.
177 | 
178 | 
179 | ## ACTION
180 | 
181 | ~~~
182 | Type:    Extended Formatting
183 | Params:  ACTION <text>
184 | ~~~
185 | 
186 | This extended formatting message shows that \<text\> should be displayed as a third-person action or emote; in clients, it’s generally activated with the command `/me`.
187 | 
188 | If \<text\> is empty, clients SHOULD still include a single space after `ACTION` (i.e. an empty params section) to help compatibility. Clients SHOULD correctly parse incoming ACTION messages with or without the params section.
189 | 
190 | ACTION is universally implemented and very commonly used. Clients MUST implement this CTCP message to effectively use IRC.
191 | 
192 | Examples:
193 | 
194 | ~~~
195 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
196 | 
197 |   Formatted:  * dan does it!
198 | ~~~
199 | 
200 | ~~~
201 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION \x01
202 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION\x01
203 |   Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION
204 | 
205 |   Formatted:  * dan
206 | ~~~
207 | 
208 | 
209 | ## CLIENTINFO
210 | 
211 | ~~~
212 | Type:   Extended Query
213 | Reply:  CLIENTINFO <tokens>
214 | ~~~
215 | 
216 | This extended query returns a list of the CTCP messages that this client supports and implements, delimited by a single ASCII space.
217 | 
218 | CLIENTINFO is widely implemented. Clients SHOULD implement this CTCP message.
219 | 
220 | Example:
221 | 
222 | ~~~
223 |   Query:     CLIENTINFO
224 |   Response:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
225 | ~~~
226 | 
227 | 
228 | ## DCC
229 | 
230 | ~~~
231 | Type:    Extended Query
232 | Params:  DCC <type> <argument> <host> <port>
233 | ~~~
234 | 
235 | This extended query sets up and controls connections that go directly between clients, bypassing the IRC server. This is typically used for features that require a large amount of traffic between clients or simply wish to bypass the server itself such as file transfer and direct chat.
236 | 
237 | The Direct Client-to-Client (DCC) Protocol requires its own specification, and is not described in-depth here.
238 | 
239 | DCC is widely implemented. Clients MAY implement this CTCP message.
240 | 
241 | 
242 | ## FINGER
243 | 
244 | ~~~
245 | Type:   Metadata Query
246 | Reply:  FINGER <info>
247 | ~~~
248 | 
249 | This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.
250 | 
251 | However, some implementations return the client name and version instead.
252 | 
253 | FINGER is largely obsolete. Clients MAY implement this CTCP message.
254 | 
255 | Example:
256 | 
257 | ~~~
258 |   Query:     FINGER
259 |   Response:  FINGER WeeChat 1.8-dev
260 | ~~~
261 | 
262 | 
263 | ## PING
264 | 
265 | ~~~
266 | Type:    Extended Query
267 | Params:  PING <info>
268 | ~~~
269 | 
270 | This extended query confirms reachability and latency to the target client. When receiving a CTCP PING, the reply MUST contain exactly the same parameters as the original query.
271 | 
272 | PING is universally implemented. Clients SHOULD implement this CTCP message.
273 | 
274 | Example:
275 | 
276 | ~~~
277 |   Query:     PING 1473523721 662865
278 |   Response:  PING 1473523721 662865
279 |   
280 |   Query:     PING foo bar baz
281 |   Response:  PING foo bar baz
282 | ~~~
283 | 
284 | 
285 | ## SOURCE
286 | 
287 | ~~~
288 | Type:   Metadata Query
289 | Reply:  SOURCE <info>
290 | ~~~
291 | 
292 | This metadata query returns the location of the source code for the client.
293 | 
294 | SOURCE is rarely implemented. Clients MAY implement this CTCP message.
295 | 
296 | Example:
297 | 
298 | ~~~
299 |   Query:     SOURCE
300 |   Response:  SOURCE https://weechat.org/download
301 | ~~~
302 | 
303 | 
304 | ## TIME
305 | 
306 | ~~~
307 | Type:    Extended Query
308 | Params:  TIME <timestring>
309 | ~~~
310 | 
311 | This extended query returns the client’s local time in an unspecified human-readable format. In practice, both the format output by ctime() and the format described in Section 3.3 of {{!RFC5322}} are common. Earlier specifications recommended prefixing the time string with a colon, but this is no longer recommended.
312 | 
313 | New implementations MAY default to UTC time for privacy reasons.
314 | 
315 | TIME is almost universally implemented. Clients MAY implement this CTCP message.
316 | 
317 | Example:
318 | 
319 | ~~~
320 |   Query:     TIME
321 |   Response:  TIME Mon, 08 May 2017 09:15:29 GMT
322 | ~~~
323 | 
324 | 
325 | ## VERSION
326 | 
327 | ~~~
328 | Type:   Metadata Query
329 | Reply:  VERSION <verstring>
330 | ~~~
331 | 
332 | This metadata query returns the name and version of the client software in use. There is no specified format for the version string.
333 | 
334 | Clients may allow users to customise the response value for this query.
335 | 
336 | VERSION is universally implemented. Clients SHOULD implement this CTCP message.
337 | 
338 | Example:
339 | 
340 | ~~~
341 |   Query:     VERSION
342 |   Response:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
343 | ~~~
344 | 
345 | 
346 | ## USERINFO
347 | 
348 | ~~~
349 | Type:   Metadata Query
350 | Reply:  USERINFO <info>
351 | ~~~
352 | 
353 | This metadata query returns miscellaneous info about the user, typically the same information that’s held in their realname field.
354 | 
355 | However, some implementations return `<nickname> (<realname>)` instead.
356 | 
357 | USERINFO is largely obsolete. Clients MAY implement this CTCP message.
358 | 
359 | Example:
360 | 
361 | ~~~
362 |   Query:     USERINFO
363 |   Response:  USERINFO fred (Fred Foobar)
364 | ~~~
365 | 
366 | # Change History \[RFC Editor: Please remove this section\]
367 | 
368 | Changes from draft 1 (July 18, 2017)
369 | 
370 | - General editing, fixed mistypes.
371 | - Simplified some of the examples.
372 | 
373 | Changes from draft 0 (May 29, 2017)
374 | 
375 | - Added note about servers truncating CTCP messages (thanks Peter).
376 | - Fixed misspellings and added note to TIME about previously-recommended prefix (thanks Patrick).
377 | - Mentioned how to parse/send empty ACTION messages (thanks dequis and the crew).
378 | 


--------------------------------------------------------------------------------
/lib/style.css:
--------------------------------------------------------------------------------
  1 | /* retrieved as-is from https://github.com/martinthomson/i-d-template/blob/main/v3.css */
  2 | 
  3 | /* @import url('https://martinthomson.github.io/i-d-template/fonts.css'); */
  4 | 
  5 | html {
  6 |   --background-color: #fff;
  7 |   --text-color: #222;
  8 |   --title-color: #191919;
  9 |   --link-color: #2a6496;
 10 |   --highlight-color: #f9f9f9;
 11 |   --line-color: #eee;
 12 |   --pilcrow-weak: #ddd;
 13 |   --pilcrow-strong: #bbb;
 14 |   --small-font-size: 14.5px;
 15 |   scrollbar-color: #bbb #eee;
 16 | }
 17 | @media (prefers-color-scheme: dark) {
 18 | html {
 19 |   --background-color: #121212;
 20 |   --text-color: #f0f0f0;
 21 |   --title-color: #fff;
 22 |   --link-color: #4da4f0;
 23 |   --highlight-color: #282828;
 24 |   --line-color: #444;
 25 |   --pilcrow-weak: #444;
 26 |   --pilcrow-strong: #666;
 27 |   scrollbar-color: #777 #333;
 28 | }
 29 | }
 30 | body {
 31 |   max-width: 600px;
 32 |   margin: 75px auto;
 33 |   padding: 0 5px;
 34 |   color: var(--text-color);
 35 |   background-color: var(--background-color);
 36 |   font: 16px/22px "Lora", serif;
 37 |   scroll-behavior: smooth;
 38 | }
 39 | 
 40 | .ears {
 41 |   display: none;
 42 | }
 43 | 
 44 | /* headings */
 45 | #title, h1, h2, h3, h4, h5, h6 {
 46 |   font-family: "Cabin Condensed", sans-serif;
 47 |   font-weight: 600;
 48 |   margin: 0.8em 0 0.3em;
 49 |   font-size-adjust: 0.5;
 50 |   color: var(--title-color);
 51 | }
 52 | #title {
 53 |   padding: 1em 0 0.2em;
 54 |   font-size: 32px;
 55 |   line-height: 40px;
 56 |   clear: both;
 57 | }
 58 | h1, h2, h3 {
 59 |   font-size: 22px;
 60 |   line-height: 27px;
 61 | }
 62 | h4, h5, h6 {
 63 |   font-size: 20px;
 64 |   line-height: 24px;
 65 | }
 66 | 
 67 | /* general structure */
 68 | .author {
 69 |   padding-bottom: 0.3em;
 70 | }
 71 | #abstract+p, #abstract+p code, #abstract+p samp, #abstract+p tt {
 72 |   font-size: 18px;
 73 |   line-height: 24px;
 74 | }
 75 | p {
 76 |   padding: 0;
 77 |   margin: 0.5em 0;
 78 |   text-align: left;
 79 | }
 80 | div {
 81 |   margin: 0;
 82 | }
 83 | .alignRight.art-text {
 84 |   background-color: var(--highlight-color);
 85 |   border: 1px solid var(--line-color);
 86 |   border-radius: 3px;
 87 |   padding: 0.5em 1em 0;
 88 |   margin-bottom: 0.5em;
 89 | }
 90 | .alignRight.art-text pre {
 91 |   padding: 0;
 92 |   width: auto;
 93 | }
 94 | .alignRight {
 95 |   margin: 1em 0;
 96 | }
 97 | .alignRight > *:first-child {
 98 |   border: none;
 99 |   margin: 0;
100 |   float: right;
101 |   clear: both;
102 | }
103 | .alignRight > *:nth-child(2) {
104 |   clear: both;
105 |   display: block;
106 |   border: none;
107 | }
108 | svg {
109 |   display: block;
110 | }
111 | .alignCenter.art-text {
112 |   background-color: var(--highlight-color);
113 |   border: 1px solid var(--line-color);
114 |   border-radius: 3px;
115 |   padding: 0.5em 1em 0;
116 |   margin-bottom: 0.5em;
117 | }
118 | .alignCenter.art-text pre {
119 |   padding: 0;
120 |   width: auto;
121 | }
122 | .alignCenter {
123 |   margin: 1em 0;
124 | }
125 | .alignCenter > *:first-child {
126 |   border: none;
127 |   /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
128 |      support flexbox yet.
129 |   */
130 |   display: table;
131 |   margin: 0 auto;
132 | }
133 | 
134 | /* lists */
135 | ol, ul {
136 |   padding: 0;
137 |   margin: 0 0 0.5em 2em;
138 | }
139 | ol ol, ul ul, ol ul, ul ol {
140 |   margin-left: 1em;
141 | }
142 | li {
143 |   margin: 0 0 0.25em 0;
144 | }
145 | .ulCompact li {
146 |   margin: 0;
147 | }
148 | ul.empty, .ulEmpty {
149 |   list-style-type: none;
150 | }
151 | ul.empty li, .ulEmpty li {
152 |   margin-top: 0.5em;
153 | }
154 | ul.compact, .ulCompact,
155 | ol.compact, .olCompact {
156 |   line-height: 100%;
157 |   margin: 0 0 0 2em;
158 | }
159 | 
160 | /* definition lists */
161 | dl {
162 | }
163 | dl > dt {
164 |   float: left;
165 |   margin-right: 1em;
166 | }
167 | dl > dd {
168 |   margin-bottom: .8em;
169 |   min-height: 1.3em;
170 | }
171 | dl.compact > dd, .dlCompact > dd {
172 |   margin-bottom: 0em;
173 | }
174 | dl > dd > dl {
175 |   margin-top: 0.5em;
176 |   margin-bottom: 0em;
177 | }
178 | dd.break {
179 |   display: none;
180 | }
181 | 
182 | /* links */
183 | a, a[href].selfRef:hover {
184 |   text-decoration: none;
185 | }
186 | a[href].selfRef {
187 |   color: var(--text-color);
188 | }
189 | a[href] {
190 |   color: var(--link-color);
191 | }
192 | a[href]:hover {
193 |   text-decoration: underline;
194 | }
195 | a[href].selfRef:hover {
196 |   background-color: var(--highlight-color);
197 | }
198 | a.xref {
199 |   white-space: nowrap;
200 | }
201 | 
202 | /* Figures */
203 | tt, code, pre {
204 |   background-color: var(--highlight-color);
205 |   font: 14px/22px 'Oxygen Mono', monospace;
206 | }
207 | pre {
208 |   border: 1px solid var(--line-color);
209 |   font-size: 13.5px;
210 |   line-height: 16px;
211 |   letter-spacing: -0.2px;
212 |   margin: 5px;
213 |   padding: 5px;
214 | }
215 | img {
216 |   max-width: 100%;
217 | }
218 | figure {
219 |   margin: 0.5em 0;
220 |   padding: 0;
221 | }
222 | figure blockquote {
223 |   margin: 0.8em 0.4em 0.4em;
224 | }
225 | figcaption, caption {
226 |   font-style: italic;
227 |   margin: 0.5em 1.5em;
228 |   text-align: left;
229 | }
230 | @media screen {
231 |   pre {
232 |     display: inline-block;
233 |     overflow-x: auto;
234 |     max-width: 100%;
235 |     width: calc(100% - 22px - 1em);
236 |   }
237 |   figure pre {
238 |     display: block;
239 |     width: calc(100% - 25px);
240 |   }
241 |   pre + .pilcrow {
242 |     display: inline-block;
243 |     vertical-align: text-bottom;
244 |     padding-bottom: 8px;
245 |   }
246 | }
247 | 
248 | /* aside, blockquote */
249 | aside, blockquote {
250 |   margin-left: 0;
251 |   padding: 0 2em;
252 |   font-style: italic;
253 | }
254 | blockquote {
255 |   background-color: var(--highlight-color);
256 |   border: 1px solid var(--line-color);
257 |   border-radius: 3px;
258 |   margin: 1em 0;
259 | }
260 | cite {
261 |   display: block;
262 |   text-align: right;
263 |   font-style: italic;
264 | }
265 | 
266 | /* tables */
267 | table {
268 |   max-width: 100%;
269 |   margin: 0 0 1em;
270 |   border-collapse: collapse;
271 | }
272 | table.right {
273 |   margin-left: auto;
274 | }
275 | table.center {
276 |   margin-left: auto;
277 |   margin-right: auto;
278 | }
279 | table.left {
280 |   margin-right: auto;
281 | }
282 | thead, tbody {
283 |   border: 1px solid var(--line-color);
284 | }
285 | th, td {
286 |   text-align: left;
287 |   vertical-align: top;
288 |   padding: 5px 10px;
289 | }
290 | th {
291 |   background-color: var(--line-color);
292 | }
293 | tr:nth-child(2n) > td {
294 |   background-color: var(--background-color);
295 | }
296 | tr:nth-child(2n+1) > td {
297 |   background-color: var(--highlight-color);
298 | }
299 | thead+tbody > tr:nth-child(2n) > td {
300 |   background-color: var(--highlight-color);
301 | }
302 | thead+tbody > tr:nth-child(2n+1) > td {
303 |   background-color: var(--background-color);
304 | }
305 | table caption {
306 |   margin: 0;
307 |   padding: 3px 0 3px 1em;
308 | }
309 | table p {
310 |   margin: 0;
311 | }
312 | 
313 | /* pilcrow */
314 | a.pilcrow {
315 |   margin-left: 3px;
316 |   opacity: 0; /* dan: opacity was 0.2 in stock. felt distracting? */
317 |   user-select: none;
318 | }
319 | a.pilcrow[href] { color: var(--pilcrow-weak); }
320 | a.pilcrow[href]:hover { text-decoration: none; }
321 | @media not print {
322 |   :hover > a.pilcrow {
323 |     opacity: 1;
324 |   }
325 |   a.pilcrow[href]:hover {
326 |     color: var(--pilcrow-strong);
327 |     background-color: transparent;
328 |   }
329 | }
330 | @media print {
331 |   a.pilcrow {
332 |     display: none;
333 |   }
334 | }
335 | 
336 | /* misc */
337 | hr {
338 |   border: 0;
339 |   border-top: 1px solid var(--line-color);
340 | }
341 | .bcp14 {
342 |   font-variant: small-caps;
343 | }
344 | 
345 | .role {
346 |   font-variant: all-small-caps;
347 | }
348 | 
349 | /* info block */
350 | #identifiers {
351 |   margin: 0;
352 |   font-size: var(--small-font-size);
353 |   line-height: 18px;
354 |   --identifier-width: 8em;
355 | }
356 | #identifiers dt {
357 |   width: var(--identifier-width);
358 |   margin: 0;
359 |   clear: left;
360 |   float: left;
361 |   text-align: right;
362 | }
363 | #identifiers dd {
364 |   margin: 0 0 0 calc(1em + var(--identifier-width));
365 |   min-width: 5em;
366 | }
367 | #identifiers .authors .author {
368 |   display: inline-block;
369 |   margin-right: 1.5em;
370 | }
371 | #identifiers .authors .org {
372 |   font-style: italic;
373 | }
374 | 
375 | /* The prepared/rendered info at the very bottom of the page */
376 | .docInfo {
377 |   color: #999;
378 |   font-size: 0.9em;
379 |   font-style: italic;
380 |   margin-top: 2em;
381 | }
382 | .docInfo .prepared {
383 |   float: left;
384 | }
385 | .docInfo .prepared {
386 |   float: right;
387 | }
388 | 
389 | /* table of contents */
390 | #toc {
391 |   padding: 0.75em 0 2em 0;
392 |   margin-bottom: 1em;
393 | }
394 | #toc nav ul {
395 |   margin: 0 0.5em 0 0;
396 |   padding: 0;
397 |   list-style: none;
398 | }
399 | #toc nav li {
400 |   line-height: 1.3em;
401 |   margin: 0.75em 0;
402 |   padding-left: 1.2em;
403 |   text-indent: -1.2em;
404 | }
405 | #toc a.xref {
406 |   white-space: normal;
407 | }
408 | /* references */
409 | .references dt {
410 |   text-align: right;
411 |   font-weight: bold;
412 |   min-width: 7em;
413 | }
414 | .references dd {
415 |   margin-left: 8em;
416 |   overflow: auto;
417 | }
418 | 
419 | .refInstance {
420 |   margin-bottom: 1.25em;
421 | }
422 | 
423 | .references .ascii {
424 |   margin-bottom: 0.25em;
425 | }
426 | 
427 | /* index */
428 | .index ul {
429 |   margin: 0 0 0 1em;
430 |   padding: 0;
431 |   list-style: none;
432 | }
433 | .index ul ul {
434 |   margin: 0;
435 | }
436 | .index li {
437 |   margin: 0;
438 |   text-indent: -2em;
439 |   padding-left: 2em;
440 |   padding-bottom: 5px;
441 | }
442 | .indexIndex {
443 |   margin: 0.5em 0 1em;
444 | }
445 | .index a {
446 |   font-weight: 700;
447 | }
448 | /* make the index two-column on all but the smallest screens */
449 | @media (min-width: 500px) {
450 |   .index ul {
451 |     column-count: 2;
452 |     column-gap: 20px;
453 |   }
454 |   .index ul ul {
455 |     column-count: 1;
456 |     column-gap: 0;
457 |   }
458 | }
459 | 
460 | /* authors */
461 | address.vcard {
462 |   font-style: normal;
463 |   margin: 1em 0;
464 | }
465 | address.vcard .nameRole {
466 |   font-weight: 700;
467 |   margin-left: 0;
468 | }
469 | address.vcard .label {
470 |   margin: 0.5em 0;
471 | }
472 | address.vcard .type {
473 |   display: none;
474 | }
475 | .alternative-contact {
476 |   margin: 1.5em 0 1em;
477 | }
478 | hr.addr {
479 |   border-top: 1px dashed;
480 |   margin: 0;
481 |   color: #ddd;
482 |   max-width: calc(100% - 16px);
483 | }
484 | @media (min-width: 500px) {
485 |   #authors-addresses > section {
486 |     column-count: 2;
487 |     column-gap: 20px;
488 |   }
489 |   #authors-addresses > section > h2 {
490 |     column-span: all;
491 |   }
492 |   /* hack for break-inside: avoid-column */
493 |   #authors-addresses address {
494 |     display: inline-block;
495 |     break-inside: avoid-column;
496 |   }
497 | }
498 | 
499 | .rfcEditorRemove p:first-of-type {
500 |   font-style: italic;
501 | }
502 | .cref {
503 |   background-color: rgba(249, 232, 105, 0.3);
504 |   padding: 2px 4px;
505 | }
506 | .crefSource {
507 |   font-style: italic;
508 | }
509 | /* alternative layout for smaller screens */
510 | @media screen and (max-width: 929px) {
511 |   #toc {
512 |     position: fixed;
513 |     z-index: 2;
514 |     top: 0;
515 |     right: 0;
516 |     padding: 0;
517 |     margin: 0;
518 |     border-bottom: 1px solid #ccc;
519 |     opacity: 0.6;
520 |   }
521 |   #toc.active {
522 |       opacity: 1;
523 |   }
524 |   #toc h2 {
525 |     margin: 0;
526 |     padding: 2px 0 2px 6px;
527 |     padding-right: 1em;
528 |     font-size: 18px;
529 |     line-height: 24px;
530 |     min-width: 190px;
531 |     text-align: right;
532 |     background-color: #444;
533 |     color: white;
534 |     cursor: pointer;
535 |   }
536 |   #toc h2::before { /* css hamburger */
537 |     float: right;
538 |     position: relative;
539 |     width: 1em;
540 |     height: 1px;
541 |     left: -164px;
542 |     margin: 8px 0 0 0;
543 |     background: white none repeat scroll 0 0;
544 |     box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
545 |     content: "";
546 |   }
547 |   #toc nav {
548 |     display: none;
549 |     background-color: var(--background-color);
550 |     padding: 0.5em 1em 1em;
551 |     overflow: auto;
552 |     overscroll-behavior: contain;
553 |     height: calc(100vh - 48px);
554 |     border-left: 1px solid #ddd;
555 |   }
556 |   #toc.active nav {
557 |     display: block;
558 |   }
559 |   /* Make the collapsed ToC header render white on gray also when it's a link */
560 |   #toc h2 a,
561 |   #toc h2 a:link,
562 |   #toc h2 a:focus,
563 |   #toc h2 a:hover,
564 |   #toc a.toplink,
565 |   #toc a.toplink:hover {
566 |     color: white;
567 |     background-color: #444;
568 |     text-decoration: none;
569 |   }
570 |   #toc a.toplink {
571 |     margin-top: 2px;
572 |   }
573 | }
574 | 
575 | /* alternative layout for wide screens */
576 | @media screen and (min-width: 930px) {
577 |   body {
578 |     padding-right: 360px;
579 |     padding-right: calc(min(180px + 20%, 500px));
580 |   }
581 |   #toc {
582 |     position: fixed;
583 |     bottom: 0;
584 |     right: 0;
585 |     right: calc(50vw - 480px);
586 |     width: 312px;
587 |     margin: 0;
588 |     padding: 0;
589 |     z-index: 1;
590 |   }
591 |   #toc h2 {
592 |     margin: 0;
593 |     padding: 0.25em 1em 1em 0;
594 |   }
595 |   #toc nav {
596 |     display: block;
597 |     height: calc(90vh - 84px);
598 |     bottom: 0;
599 |     padding: 0.5em 0 2em;
600 |     overflow: auto;
601 |     overscroll-behavior: contain;
602 |     scrollbar-width: thin;
603 |   }
604 |   #toc nav > ul  {
605 |     margin-bottom: 2em;
606 |   }
607 |   #toc ul {
608 |     margin: 0 0 0 4px;
609 |     font-size: var(--small-font-size);
610 |   }
611 |   #toc ul p, #toc ul li {
612 |     margin: 2px 0;
613 |     line-height: 22px;
614 |   }
615 |   img { /* future proofing */
616 |     max-width: 100%;
617 |     height: auto;
618 |   }
619 | }
620 | 
621 | /* pagination */
622 | @media print {
623 |   body {
624 |     width: 100%;
625 |   }
626 |   p {
627 |     orphans: 3;
628 |     widows: 3;
629 |   }
630 |   #n-copyright-notice {
631 |     border-bottom: none;
632 |   }
633 |   #toc, #n-introduction {
634 |     page-break-before: always;
635 |   }
636 |   #toc {
637 |     border-top: none;
638 |     padding-top: 0;
639 |   }
640 |   figure, pre {
641 |     page-break-inside: avoid;
642 |   }
643 |   figure {
644 |     overflow: scroll;
645 |   }
646 |   h1, h2, h3, h4, h5, h6 {
647 |     page-break-after: avoid;
648 |   }
649 |   h2+*, h3+*, h4+*, h5+*, h6+* {
650 |     page-break-before: avoid;
651 |   }
652 |   pre {
653 |     white-space: pre-wrap;
654 |     word-wrap: break-word;
655 |     font-size: 10pt;
656 |   }
657 |   table {
658 |     border: 1px solid #ddd;
659 |   }
660 |   td {
661 |     border-top: 1px solid #ddd;
662 |   }
663 | }
664 | 
665 | @page :first {
666 |   padding-top: 0;
667 |   @top-left {
668 |     content: normal;
669 |     border: none;
670 |   }
671 |   @top-center {
672 |     content: normal;
673 |     border: none;
674 |   }
675 |   @top-right {
676 |     content: normal;
677 |     border: none;
678 |   }
679 | }
680 | 
681 | @page {
682 |   size: A4;
683 |   margin-bottom: 45mm;
684 |   padding-top: 20px;
685 | }
686 | 
687 | /* Changes introduced to fix issues found during implementation */
688 | 
689 | /* Separate body from document info even without intervening H1 */
690 | section {
691 |   clear: both;
692 | }
693 | 
694 | /* Top align author divs, to avoid names without organization dropping level with org names */
695 | .author {
696 |   vertical-align: top;
697 | }
698 | 
699 | /* Style section numbers with more space between number and title */
700 | .section-number {
701 |   padding-right: 0.5em;
702 | }
703 | 
704 | /* Add styling for a link in the ToC that points to the top of the document */
705 | a.toplink {
706 |   float: right;
707 |   margin: 8px 0.5em 0;
708 | }
709 | 
710 | /* Fix the dl styling to match the RFC 7992 attributes */
711 | dl > dt,
712 | dl.dlParallel > dt {
713 |   float: left;
714 |   margin-right: 1em;
715 | }
716 | dl.dlNewline > dt {
717 |   float: none;
718 | }
719 | 
720 | /* Provide styling for table cell text alignment */
721 | table .text-left, table .text-left {
722 |   text-align: left;
723 | }
724 | table .text-center, table .text-center {
725 |   text-align: center;
726 | }
727 | table .text-right, table .text-right {
728 |   text-align: right;
729 | }
730 | 
731 | /* Make the alternative author contact information look less like just another
732 |    author, and group it closer with the primary author contact information */
733 | .alternative-contact {
734 |   margin: 0.5em 0 0.25em 0;
735 | }
736 | address .non-ascii {
737 |   margin: 0 0 0 2em;
738 | }
739 | 
740 | /* With it being possible to set tables with alignment
741 |   left, center, and right, { width: 100%; } does not make sense */
742 | table {
743 |   width: auto;
744 | }
745 | 
746 | /* Avoid reference text that sits in a block with very wide left margin,
747 |    because of a long floating dt label.*/
748 | .references dd {
749 |   overflow: visible;
750 | }
751 | 
752 | /* Control caption placement */
753 | caption {
754 |   caption-side: bottom;
755 | }
756 | 
757 | /* Limit the width of the author address vcard, so names in right-to-left
758 |    script don't end up on the other side of the page. */
759 | 
760 | address.vcard {
761 |   max-width: 20em;
762 |   margin-right: auto;
763 | }
764 | 
765 | /* For address alignment dependent on LTR or RTL scripts */
766 | address div.left {
767 |   text-align: left;
768 | }
769 | address div.right {
770 |   text-align: right;
771 | }
772 | 
773 | /* Give the table caption label the same styling as the figcaption */
774 | 
775 | @media print {
776 |   .toplink {
777 |     display: none;
778 |   }
779 | 
780 |   /* avoid overwriting the top border line with the ToC header */
781 |   #toc {
782 |     padding-top: 1px;
783 |   }
784 | 
785 |   /* Avoid page breaks inside dl and author address entries */
786 |   dd {
787 |     page-break-before: avoid;
788 |   }
789 |   .vcard {
790 |     page-break-inside: avoid;
791 |   }
792 | 
793 | }
794 | /* Tweak the bcp14 keyword presentation */
795 | .bcp14 {
796 |   font-variant: small-caps;
797 |   font-weight: bold;
798 |   font-size: 0.9em;
799 | }


--------------------------------------------------------------------------------
/dist/draft-oakley-irc-client-latest.html:
--------------------------------------------------------------------------------
  1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
  2 |   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  3 | 
  4 | <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  5 | <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
  6 |   <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
  7 | 
  8 |   <title>Internet Relay Chat Client Protocol</title>
  9 | 
 10 |   
 11 | <style type="text/css">/*<![CDATA[*/
 12 | @viewport {
 13 |   zoom: 1.0;
 14 |   width: extend-to-zoom;
 15 | }
 16 | @-ms-viewport {
 17 |   width: extend-to-zoom;
 18 |   zoom: 1.0;
 19 | }
 20 | 
 21 | @media screen and (min-width: 1024px) {
 22 |   ul.toc, #rfc\.toc {
 23 |     position: fixed;
 24 |     bottom: 0;
 25 |     right: 0;
 26 |     right: calc(50vw - 500px);
 27 |     width: 300px;
 28 |     padding: 0 1em;
 29 |     z-index: 1;
 30 |   }
 31 |   #rfc\.toc {
 32 |     top: 16px;
 33 |   }
 34 |   ul.toc {
 35 |     top: 80px;
 36 |     overflow: auto;
 37 |   }
 38 | 
 39 |   body {
 40 |     padding-left: 1.5em;
 41 |     padding-right: 29em;
 42 |   }
 43 | }
 44 | 
 45 | body {
 46 |   font: 15px "Helvetica Neue",Helvetica,Arial,sans-serif;
 47 |   color: #333;
 48 |   font-size-adjust: 0.5;
 49 |   line-height: 130%;
 50 |   margin: 2.5em auto;
 51 |   max-width: 724px;
 52 | }
 53 | 
 54 | .title, .filename, h1, h2, h3, h4 {
 55 |   font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
 56 |   font-size-adjust: 0.5;
 57 |   font-weight: 500;
 58 |   color: #333;
 59 |   line-height: 100%;
 60 |   margin: 0.8em 0 0.3em;
 61 | }
 62 | .title { font-size: 36px; }
 63 | h1 { font-size: 30px; }
 64 | h2 { font-size: 24px; }
 65 | h3, h4 { font-size: 18px; }
 66 | h1 a[href], h2 a[href], h3 a[href], h4 a[href] {
 67 |   color: #333;
 68 | }
 69 | 
 70 | ul.toc li {
 71 |   list-style: none;
 72 |   text-indent: -2.5em;
 73 |   padding-left: 2.5em;
 74 |   padding-bottom: 5px;
 75 |   margin: 0;
 76 | }
 77 | ul.toc ul {
 78 |   margin: 0;
 79 | }
 80 | /* xml2rfc nests ul directly inside ul which messes with the style badly */
 81 | ul.toc, ul.toc>ul, ul.toc ul>ul {
 82 |   margin: 0 0 0 1.5em;
 83 | }
 84 | 
 85 | table {
 86 |   margin-left: 0em;
 87 |   border-collapse: collapse;
 88 | }
 89 | th {
 90 |   text-align: left;
 91 |   border-bottom: 2px solid #ddd;
 92 | }
 93 | td {
 94 |   border-top: 1px solid #ddd;
 95 |   vertical-align: top;
 96 | }
 97 | tr:nth-child(2n+1) > td,
 98 | tr:nth-child(2n+1) > th {
 99 |   background-color: #f9f9f9;
100 | }
101 | td.reference {
102 |   max-width: 200px;
103 |   border-top: none;
104 |   padding-right: 1em;
105 | }
106 | .right {
107 |   text-align: right;
108 | }
109 | 
110 | 
111 | table.header {
112 |   width: 100%;
113 | }
114 | table.header td {
115 |   border: none;
116 |   background-color: transparent;
117 |   color: black;
118 | }
119 | .filename {
120 |   color: rgb(119, 119, 119);
121 |   font-size: 23px;
122 |   font-weight: normal;
123 |   height: auto;
124 |   line-height: 100%;
125 | }
126 | #rfc\.abstract+p {
127 |   font-size: 20px;
128 |   font-weight: 300;
129 |   line-height: 130%;
130 | }
131 | 
132 | samp, tt, code, pre {
133 |   font: 11pt consolas, monospace;
134 |   font-size-adjust: none;
135 | }
136 | pre {
137 |   background-color: #eee;
138 |   border: 1px solid #ddd;
139 |   overflow-x: auto;
140 |   padding: 5px;
141 |   margin: 5px;
142 | }
143 | .figure {
144 |   font-style: italic;
145 |   margin: 0 1.5em;
146 | }
147 | 
148 | address {
149 |   margin: 10px 0 0;
150 | }
151 | .vcard {
152 |   font-style: normal;
153 | }
154 | .vcardline {
155 |   display: block;
156 | }
157 | .vcardline .fn {
158 |   font-weight: bold;
159 | }
160 | .vcardline .hidden {
161 |   display: none;
162 | }
163 | 
164 | dl {
165 |   margin-left: 1em;
166 | }
167 | dl.dl-horizontal: {
168 |   margin-left: 0;
169 | }
170 | dl > dt {
171 |   float: left;
172 |   margin-right: 1em;
173 | }
174 | dl.nohang > dt {
175 |   float: none;
176 | }
177 | dl > dd {
178 |   margin-bottom: .5em;
179 | }
180 | dl.compact > dd {
181 |   margin-bottom: 0em;
182 | }
183 | dl > dd > dl {
184 |   margin-top: 0.5em;
185 |   margin-bottom: 0em;
186 | }
187 | ul.empty {
188 |   list-style-type: none;
189 | }
190 | ul.empty li {
191 |   margin-top: .5em;
192 | }
193 | 
194 | hr {
195 |   border: 0;
196 |   border-top: 1px solid #eee;
197 | }
198 | 
199 | a {
200 |   text-decoration: none;
201 | }
202 | a[href] {
203 |   color: #2a6496;
204 | }
205 | a[href]:hover {
206 |   background-color: #eee;
207 | }
208 | 
209 | ol, ul, li, p {
210 |   padding: 0;
211 |   margin: 0.5em 0 0.5em 2em;
212 | }
213 | li, p {
214 |   margin-left: 0;
215 | }
216 | address {
217 |   font-style: normal;
218 | }
219 | 
220 | .github-fork-ribbon-wrapper {
221 |   display: none;
222 | }
223 | @media screen and (min-width: 800px) {
224 |   /* "Fork me on GitHub" CSS ribbon based on
225 |    * https://github.com/simonwhitaker/github-fork-ribbon-css
226 |    */
227 |   .github-fork-ribbon {
228 |     position: absolute;
229 |     padding: 2px 0;
230 |     background-color: #a00;
231 |     background-image: linear-gradient(to bottom, rgba(0, 0, 0, 0), rgba(0, 0, 0, 0.15));
232 |     box-shadow: 0 2px 3px 0 rgba(0, 0, 0, 0.5);
233 |     font: 700 12px "Helvetica Neue", Helvetica, Arial, sans-serif;
234 | 
235 |     pointer-events: auto;
236 | 
237 |     top: 38px;
238 |     right: -45px;
239 | 
240 |     transform: rotate(45deg);
241 |   }
242 | 
243 |   .github-fork-ribbon a[href],
244 |   .github-fork-ribbon a[href]:hover {
245 |     color: #fff;
246 |     background-color: transparent;
247 |     text-decoration: none;
248 |     text-shadow: 0 -1px rgba(0, 0, 0, 0.5);
249 |     text-align: center;
250 | 
251 |     width: 190px;
252 |     line-height: 18px;
253 | 
254 |     display: inline-block;
255 |     padding: 2px 0;
256 | 
257 |     border: 1.5px dotted #fff;
258 |     border-color: rgba(255, 255, 255, 0.6);
259 |   }
260 | 
261 |   .github-fork-ribbon-wrapper {
262 |     display: block;
263 |     width: 130px;
264 |     height: 130px;
265 |     position: absolute;
266 |     overflow: hidden;
267 |     top: 0; right: 0;
268 |     z-index: 2;
269 |     pointer-events: none;
270 |   }
271 | }
272 | @media screen and (min-width: 1000px) {
273 |   .github-fork-ribbon-wrapper {
274 |     position: fixed;
275 |   }
276 | 
277 | /*]]>*/</style>
278 | 
279 | 
280 |   <link href="#rfc.toc" rel="Contents"/>
281 | <link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
282 | <link href="#rfc.section.2" rel="Chapter" title="2 IRC Concepts"/>
283 | <link href="#rfc.section.2.1" rel="Chapter" title="2.1 Architectural"/>
284 | <link href="#rfc.section.2.1.1" rel="Chapter" title="2.1.1 Servers"/>
285 | <link href="#rfc.references" rel="Chapter" title="3 Normative References"/>
286 | <link href="#rfc.authors" rel="Chapter"/>
287 | 
288 | 
289 |   <meta name="generator" content="xml2rfc version 2.5.2 - http://tools.ietf.org/tools/xml2rfc" />
290 |   <link rel="schema.dct" href="http://purl.org/dc/terms/" />
291 | 
292 |   <meta name="dct.creator" content="Oakley, D., Ed. and J. Allnutt" />
293 |   <meta name="dct.identifier" content="urn:ietf:id:draft-oakley-irc-client-latest" />
294 |   <meta name="dct.issued" scheme="ISO8601" content="2017-5-28" />
295 |   <meta name="dct.abstract" content="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." />
296 |   <meta name="description" content="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." />
297 | 
298 | </head>
299 | 
300 | <body>
301 | 
302 |   <table class="header">
303 |     <tbody>
304 |     
305 |     	<tr>
306 |   <td class="left">Network Working Group</td>
307 |   <td class="right">D. Oakley, Ed.</td>
308 | </tr>
309 | <tr>
310 |   <td class="left">Internet-Draft</td>
311 |   <td class="right">ircdocs</td>
312 | </tr>
313 | <tr>
314 |   <td class="left">Obsoletes: 1459, 2810, 2811, 2812 (if</td>
315 |   <td class="right">J. Allnutt</td>
316 | </tr>
317 | <tr>
318 |   <td class="left">           approved)</td>
319 |   <td class="right">Kiwi IRC</td>
320 | </tr>
321 | <tr>
322 |   <td class="left">Intended status: Informational</td>
323 |   <td class="right">May 28, 2017</td>
324 | </tr>
325 | <tr>
326 |   <td class="left">Expires: November 29, 2017</td>
327 |   <td class="right"></td>
328 | </tr>
329 | 
330 |     	
331 |     </tbody>
332 |   </table>
333 | 
334 |   <p class="title">Internet Relay Chat Client Protocol<br />
335 |   <span class="filename">draft-oakley-irc-client-latest</span></p>
336 |   
337 |   <h1 id="rfc.abstract">
338 |   <a href="#rfc.abstract">Abstract</a>
339 | </h1>
340 | <p>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.</p>
341 | <p>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.</p>
342 | <h1 id="rfc.status">
343 |   <a href="#rfc.status">Status of This Memo</a>
344 | </h1>
345 | <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
346 | <p>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/.</p>
347 | <p>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."</p>
348 | <p>This Internet-Draft will expire on November 29, 2017.</p>
349 | <h1 id="rfc.copyrightnotice">
350 |   <a href="#rfc.copyrightnotice">Copyright Notice</a>
351 | </h1>
352 | <p>Copyright (c) 2017 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
353 | <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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.</p>
354 | 
355 |   
356 |   <hr class="noprint" />
357 |   <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
358 |   <ul class="toc">
359 | 
360 |   	<li>1.   <a href="#rfc.section.1">Introduction</a></li>
361 | <li>2.   <a href="#rfc.section.2">IRC Concepts</a></li>
362 | <ul><li>2.1.   <a href="#rfc.section.2.1">Architectural</a></li>
363 | <ul><li>2.1.1.   <a href="#rfc.section.2.1.1">Servers</a></li>
364 | </ul></ul><li>3.   <a href="#rfc.references">Normative References</a></li>
365 | <li><a href="#rfc.authors">Authors' Addresses</a></li>
366 | 
367 | 
368 |   </ul>
369 | 
370 |   <h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a></h1>
371 | <p id="rfc.section.1.p.1">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.</p>
372 | <p id="rfc.section.1.p.2">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.</p>
373 | <p id="rfc.section.1.p.3">The key words &#8220;MUST&#8221;, &#8220;MUST NOT&#8221;, &#8220;REQUIRED&#8221;, &#8220;SHALL&#8221;, &#8220;SHALL NOT&#8221;, &#8220;SHOULD&#8221;, &#8220;SHOULD NOT&#8221;, &#8220;RECOMMENDED&#8221;,  &#8220;MAY&#8221;, and &#8220;OPTIONAL&#8221; in this document are to be interpreted as described in <a href="#RFC2119">[RFC2119]</a>.</p>
374 | <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#irc-concepts" id="irc-concepts">IRC Concepts</a></h1>
375 | <p id="rfc.section.2.p.1">This section describes concepts behind the implementation and organisation of the IRC protocol, which are useful in understanding how it works.</p>
376 | <h1 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a> <a href="#architectural" id="architectural">Architectural</a></h1>
377 | <p id="rfc.section.2.1.p.1">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.</p>
378 | <h1 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1.</a> <a href="#servers" id="servers">Servers</a></h1>
379 | <p id="rfc.section.2.1.1.p.1">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.</p>
380 | <p id="rfc.section.2.1.1.p.2">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.</p>
381 | <div id="rfc.figure.1"/>
382 | <div id="figops"/>
383 | <pre>
384 |                           [ Server 15 ]  [ Server 13 ] [ Server 14 ]
385 |                                 /                \         /
386 |                                /                  \       /
387 |        [ Server 11 ] ------ [ Server 1 ]       [ Server 12 ]
388 |                              /        \          /
389 |                             /          \        /
390 |                  [ Server 2 ]          [ Server 3 ]
391 |                    /       \                      \
392 |                   /         \                      \
393 |           [ Server 4 ]    [ Server 5 ]         [ Server 6 ]
394 |            /    |    \                           /
395 |           /     |     \                         /
396 |          /      |      \____                   /
397 |         /       |           \                 /
398 | [ Server 7 ] [ Server 8 ] [ Server 9 ]   [ Server 10 ]
399 | 
400 |                                  :
401 |                               [ etc. ]
402 |                                  :
403 | </pre>
404 | <p class="figure">Figure 1: Format of a typical IRC network</p>
405 | <p id="rfc.section.2.1.1.p.3">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:</p>
406 | <p/>
407 | 
408 | <ul>
409 |   <li><strong>Hub</strong>: 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.</li>
410 |   <li><strong>Core Hub</strong>: 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.</li>
411 |   <li><strong>Leaf</strong>: 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.</li>
412 |   <li><strong>Services</strong>: A services server is a special type of server that extends the capabilities of the server software on the network (ie, they provide <em>services</em> 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 &#8216;own&#8217; channels), and further modifications and extensions to the IRC protocol. &#8216;Services&#8217; themselves are <strong>not</strong> specified in any way by the protocol. What they provide depends entirely on the software packages being run.</li>
413 | </ul>
414 | <p id="rfc.section.2.1.1.p.5">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 <samp>MAP</samp> 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 &#8216;hidden hubs&#8217;). Generally, IRC operators can always see the true structure of a network.</p>
415 | <p id="rfc.section.2.1.1.p.6">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.</p>
416 | <h1 id="rfc.references"><a href="#rfc.references">3.</a> Normative References</h1>
417 | <table>
418 |   <tbody>
419 |     <tr>
420 |       <td class="reference">
421 |         <b id="RFC2119">[RFC2119]</b>
422 |       </td>
423 |       <td class="top"><a>Bradner, S.</a>, "<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
424 |     </tr>
425 |   </tbody>
426 | </table>
427 | <h1 id="rfc.authors">
428 |   <a href="#rfc.authors">Authors' Addresses</a>
429 | </h1>
430 | <div class="avoidbreak">
431 |   <address class="vcard">
432 | 	<span class="vcardline">
433 | 	  <span class="fn">Daniel Oakley</span> (editor)
434 | 	  <span class="n hidden">
435 | 		<span class="family-name">Oakley</span>
436 | 	  </span>
437 | 	</span>
438 | 	<span class="org vcardline">ircdocs</span>
439 | 	<span class="adr">
440 | 	  
441 | 	  <span class="vcardline">
442 | 		<span class="locality"></span> 
443 | 		<span class="region"></span>
444 | 		<span class="code"></span>
445 | 	  </span>
446 | 	  <span class="country-name vcardline"></span>
447 | 	</span>
448 | 	<span class="vcardline">EMail: <a href="mailto:daniel@danieloaks.net">daniel@danieloaks.net</a></span>
449 | 
450 |   </address>
451 | </div><div class="avoidbreak">
452 |   <address class="vcard">
453 | 	<span class="vcardline">
454 | 	  <span class="fn">Jack Allnutt</span> 
455 | 	  <span class="n hidden">
456 | 		<span class="family-name">Allnutt</span>
457 | 	  </span>
458 | 	</span>
459 | 	<span class="org vcardline">Kiwi IRC</span>
460 | 	<span class="adr">
461 | 	  
462 | 	  <span class="vcardline">
463 | 		<span class="locality"></span> 
464 | 		<span class="region"></span>
465 | 		<span class="code"></span>
466 | 	  </span>
467 | 	  <span class="country-name vcardline"></span>
468 | 	</span>
469 | 	<span class="vcardline">EMail: <a href="mailto:jack@allnutt.eu">jack@allnutt.eu</a></span>
470 | 
471 |   </address>
472 | </div>
473 | 
474 | </body>
475 | </html>
476 | 


--------------------------------------------------------------------------------
/dist/draft-oakley-irc-ctcp-latest.txt:
--------------------------------------------------------------------------------
  1 | 
  2 | 
  3 | 
  4 | 
  5 | Network Working Group                                       M. Mikulėnas
  6 | Internet-Draft                                               Independent
  7 | Updates: 1459, 2812 (if approved)                         D. Oakley, Ed.
  8 | Intended status: Informational                                   ircdocs
  9 | Expires: 24 November 2021                                    23 May 2021
 10 | 
 11 | 
 12 |          Internet Relay Chat: Client-to-Client Protocol (CTCP)
 13 |                       draft-oakley-irc-ctcp-latest
 14 | 
 15 | Abstract
 16 | 
 17 |    This document describes the Client-to-Client Protocol (CTCP), which
 18 |    lets Internet Relay Chat (IRC) clients send each other messages that
 19 |    get displayed or responded to in special ways.  CTCP has been widely
 20 |    implemented, with most clients supporting it natively.  This document
 21 |    outlines how to implement CTCP and the most common messages.
 22 | 
 23 |    This document updates RFCs 1459 and 2812.
 24 | 
 25 | Status of This Memo
 26 | 
 27 |    This Internet-Draft is submitted in full conformance with the
 28 |    provisions of BCP 78 and BCP 79.
 29 | 
 30 |    Internet-Drafts are working documents of the Internet Engineering
 31 |    Task Force (IETF).  Note that other groups may also distribute
 32 |    working documents as Internet-Drafts.  The list of current Internet-
 33 |    Drafts is at https://datatracker.ietf.org/drafts/current/.
 34 | 
 35 |    Internet-Drafts are draft documents valid for a maximum of six months
 36 |    and may be updated, replaced, or obsoleted by other documents at any
 37 |    time.  It is inappropriate to use Internet-Drafts as reference
 38 |    material or to cite them other than as "work in progress."
 39 | 
 40 |    This Internet-Draft will expire on 24 November 2021.
 41 | 
 42 | Copyright Notice
 43 | 
 44 |    Copyright (c) 2021 IETF Trust and the persons identified as the
 45 |    document authors.  All rights reserved.
 46 | 
 47 |    This document is subject to BCP 78 and the IETF Trust's Legal
 48 |    Provisions Relating to IETF Documents (https://trustee.ietf.org/
 49 |    license-info) in effect on the date of publication of this document.
 50 |    Please review these documents carefully, as they describe your rights
 51 |    and restrictions with respect to this document.
 52 | 
 53 | 
 54 | 
 55 | 
 56 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 1]
 57 | 
 58 | Internet-Draft                  IRC CTCP                        May 2021
 59 | 
 60 | 
 61 | Table of Contents
 62 | 
 63 |    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 64 |    2.  Protocol Structure  . . . . . . . . . . . . . . . . . . . . .   3
 65 |    3.  Message Syntax  . . . . . . . . . . . . . . . . . . . . . . .   3
 66 |    4.  Messages  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
 67 |    5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
 68 |    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
 69 |    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
 70 |    8.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
 71 |    Appendix A.  Message List . . . . . . . . . . . . . . . . . . . .   5
 72 |      A.1.  ACTION  . . . . . . . . . . . . . . . . . . . . . . . . .   5
 73 |      A.2.  CLIENTINFO  . . . . . . . . . . . . . . . . . . . . . . .   6
 74 |      A.3.  DCC . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
 75 |      A.4.  FINGER  . . . . . . . . . . . . . . . . . . . . . . . . .   7
 76 |      A.5.  PING  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 77 |      A.6.  SOURCE  . . . . . . . . . . . . . . . . . . . . . . . . .   7
 78 |      A.7.  TIME  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 79 |      A.8.  VERSION . . . . . . . . . . . . . . . . . . . . . . . . .   8
 80 |      A.9.  USERINFO  . . . . . . . . . . . . . . . . . . . . . . . .   9
 81 |    Appendix B.  Change History [RFC Editor: Please remove this
 82 |            section]  . . . . . . . . . . . . . . . . . . . . . . . .   9
 83 |    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
 84 | 
 85 | 1.  Introduction
 86 | 
 87 |    The core Internet Relay Chat (IRC) protocol as described in [RFC1459]
 88 |    and [RFC2812] does not provide a way to exchange computer-readable
 89 |    information directly between clients.  The Client-to-Client Protocol
 90 |    (CTCP) lets them exchange messages that get processed, displayed or
 91 |    responded to in special ways.
 92 | 
 93 |    CTCP can be used to request special formatting on messages, query
 94 |    other clients for metadata, and help initiate file transfers with
 95 |    other clients among other uses.  This document covers the subset of
 96 |    CTCP which is commonly implemented, and clients implementing this
 97 |    specification are compatible with those implementing the protocol as
 98 |    described by older documents.
 99 | 
100 |    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
101 |    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
102 |    document are to be interpreted as described in [RFC2119].
103 | 
104 | 
105 | 
106 | 
107 | 
108 | 
109 | 
110 | 
111 | 
112 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 2]
113 | 
114 | Internet-Draft                  IRC CTCP                        May 2021
115 | 
116 | 
117 | 2.  Protocol Structure
118 | 
119 |    CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies
120 |    are sent with NOTICE command.  To indicate a CTCP query or reply, the
121 |    body of the message (the second parameter) begins with the CTCP
122 |    delimiter.
123 | 
124 |    Queries MAY be sent to channels.  Replies MUST always be sent to the
125 |    querying client only, not the channel.
126 | 
127 |    Many servers implement filters so that only specific CTCP commands
128 |    can be sent to channels.  When this is done, channel operators can
129 |    typically enable and disable this filtering with a channel mode.
130 | 
131 | 3.  Message Syntax
132 | 
133 |    The ABNF [RFC5234] for CTCP message bodies is as follows:
134 | 
135 |          delim    = %x01
136 | 
137 |          command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
138 |                        ; any octet except NUL, delim, CR, LF, and SP
139 | 
140 |          params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
141 |                        ; any octet except NUL, delim, CR, and LF
142 | 
143 |          body     = delim command [ SP params ] [ delim ]
144 | 
145 |    Commands are case-insensitive.  When creating new CTCP commands,
146 |    authors SHOULD use only alphanumeric characters for ease of
147 |    implementation.
148 | 
149 |    The final CTCP delimiter SHOULD be sent on outgoing messages for
150 |    compatibility reasons, but software MUST accept incoming messages
151 |    which lack it.
152 | 
153 |    In message examples throughout this document, the CTCP delimiter is
154 |    shown as "\x01".
155 | 
156 |    Here are two examples of valid CTCP queries and replies:
157 | 
158 |      :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
159 |      :bob!b@localhost NOTICE alice :\x01VERSION Snak for Mac 4.13\x01
160 | 
161 |      :alice!a@localhost PRIVMSG #ircv3 :\x01PING 1473523796 918320
162 |      :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
163 | 
164 | 
165 | 
166 | 
167 | 
168 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 3]
169 | 
170 | Internet-Draft                  IRC CTCP                        May 2021
171 | 
172 | 
173 | 4.  Messages
174 | 
175 |    There is not a formal registry of CTCP message names, and CTCP
176 |    responses are uniquely flexible.  Clients that receive either
177 |    unexpected messages or known messages with unexpected values SHOULD
178 |    ignore them and send no response to the querying user.
179 | 
180 | 5.  Acknowledgements
181 | 
182 |    Thanks to the IRCv3 group for giving feedback on this specification,
183 |    and to Khaled Mardam-Bey for advice on client flood protection.
184 | 
185 |    Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating
186 |    the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who
187 |    wrote and revised related specifications.
188 | 
189 |    Special thanks to dequis, Sadie Powell and James Wheare for help with
190 |    this and related work.
191 | 
192 | 6.  Security Considerations
193 | 
194 |    CTCP messages are completely untrusted data and clients MUST NOT
195 |    assume that they are well-formed or complete.
196 | 
197 |    Older CTCP specifications describe quoting methods which are complex
198 |    and not widely implemented.  Implementations SHOULD NOT implement
199 |    "low-level quoting" or "CTCP-level quoting" when parsing messages.
200 | 
201 |    CTCP requests can be abused to flood clients off the server they are
202 |    connected to.  Clients SHOULD ignore or delay excessive incoming
203 |    requests to protect against this.
204 | 
205 |    Older CTCP specifications describe including more than one CTCP
206 |    message inside a single PRIVMSG or NOTICE command.  Implementations
207 |    SHOULD NOT implement this form of CTCP parsing as it is not widely-
208 |    implemented and may result in an implementation that can be more
209 |    easily flooded off the server they are connected to.
210 | 
211 | 7.  IANA Considerations
212 | 
213 |    This document has no actions for IANA.
214 | 
215 | 8.  Normative References
216 | 
217 |    [RFC1459]  Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
218 |               RFC 1459, DOI 10.17487/RFC1459, May 1993,
219 |               <https://www.rfc-editor.org/info/rfc1459>.
220 | 
221 | 
222 | 
223 | 
224 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 4]
225 | 
226 | Internet-Draft                  IRC CTCP                        May 2021
227 | 
228 | 
229 |    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
230 |               Requirement Levels", BCP 14, RFC 2119,
231 |               DOI 10.17487/RFC2119, March 1997,
232 |               <https://www.rfc-editor.org/info/rfc2119>.
233 | 
234 |    [RFC2812]  Kalt, C., "Internet Relay Chat: Client Protocol",
235 |               RFC 2812, DOI 10.17487/RFC2812, April 2000,
236 |               <https://www.rfc-editor.org/info/rfc2812>.
237 | 
238 |    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
239 |               Specifications: ABNF", STD 68, RFC 5234,
240 |               DOI 10.17487/RFC5234, January 2008,
241 |               <https://www.rfc-editor.org/info/rfc5234>.
242 | 
243 |    [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
244 |               DOI 10.17487/RFC5322, October 2008,
245 |               <https://www.rfc-editor.org/info/rfc5322>.
246 | 
247 | Appendix A.  Message List
248 | 
249 |    This section is not exhaustive, and only lists those CTCP messages
250 |    which are widely implemented across the IRC ecosystem.  Clients MUST
251 |    ONLY send params on a query if a params section is listed here.
252 | 
253 |    The Query and Reply lines below represent variables by surrounding
254 |    them with angle brackets.
255 | 
256 | A.1.  ACTION
257 | 
258 |    Query:  ACTION <text>
259 |    Reply:  None
260 | 
261 |    Clients which implement this message MUST display <text> as a third-
262 |    person action or emote.  Users typically use the "/me" command in
263 |    their IRC clients to send this message.
264 | 
265 |    If <text> is empty, clients SHOULD still include a single space after
266 |    "ACTION" (i.e. an empty params section) to help ensure compatibility.
267 |    Clients SHOULD correctly parse incoming ACTION messages with or
268 |    without the params section.  Leading spaces in <text> SHOULD NOT be
269 |    stripped before being displayed to users.
270 | 
271 |    ACTION is universally implemented and very commonly used.  Clients
272 |    MUST implement this CTCP message to effectively use IRC.
273 | 
274 |    Examples:
275 | 
276 | 
277 | 
278 | 
279 | 
280 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 5]
281 | 
282 | Internet-Draft                  IRC CTCP                        May 2021
283 | 
284 | 
285 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
286 | 
287 |      Formatted:  * dan does it!
288 | 
289 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION \x01
290 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION\x01
291 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION
292 | 
293 |      Formatted:  * dan
294 | 
295 | A.2.  CLIENTINFO
296 | 
297 |    Query:  CLIENTINFO
298 |    Reply:  CLIENTINFO <tokens>
299 | 
300 |    Clients which implement this message MUST reply with a list of the
301 |    CTCP messages they support, delimited by an ASCII space.  Some legacy
302 |    implementations add an extra text message at the end prefixed by a
303 |    colon, as demonstrated in the examples.
304 | 
305 |    CLIENTINFO is widely implemented.  Clients SHOULD implement this CTCP
306 |    message.
307 | 
308 |    Example:
309 | 
310 |      Query:  CLIENTINFO
311 |      Reply:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
312 | 
313 |      Query:  CLIENTINFO
314 |      Reply:  CLIENTINFO CLIENTINFO PING VERSION  :Use CLIENTINFO
315 |              <COMMAND> to get more specific information
316 | 
317 | A.3.  DCC
318 | 
319 |    Query:  DCC <type> <argument> <host> <port>
320 |    Reply:  Described elsewhere.
321 | 
322 |    This message sets up connections that go directly between clients,
323 |    bypassing the IRC server.  This is typically used for features that
324 |    require a large amount of traffic (e.g. file transfers), or simply
325 |    direct chat that bypasses the server.
326 | 
327 |    The Direct Client-to-Client (DCC) protocol requires its own
328 |    specification, and is not described in-depth here.
329 | 
330 |    DCC is widely implemented.  Clients MAY implement this CTCP message.
331 | 
332 | 
333 | 
334 | 
335 | 
336 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 6]
337 | 
338 | Internet-Draft                  IRC CTCP                        May 2021
339 | 
340 | 
341 | A.4.  FINGER
342 | 
343 |    Query:  FINGER
344 |    Reply:  FINGER <info>
345 | 
346 |    Clients which implement this message MUST reply with miscellaneous
347 |    information about the user (typically the contents of their realname/
348 |    gecos field).  However, some implementations return the client name
349 |    and version instead.
350 | 
351 |    FINGER is largely obsolete.  Clients MAY implement this CTCP message.
352 | 
353 |    Example:
354 | 
355 |      Query:  FINGER
356 |      Reply:  FINGER WeeChat 1.8-dev
357 | 
358 | A.5.  PING
359 | 
360 |    Query:  PING <info>
361 |    Reply:  PING <info>
362 | 
363 |    Clients which implement this message MUST send a reply containing
364 |    exactly the same params as the original query.  However, leading
365 |    spaces MAY be stripped.  This message confirms reachability and
366 |    latency between two clients.
367 | 
368 |    PING is universally implemented.  Clients SHOULD implement this CTCP
369 |    message.
370 | 
371 |    Example:
372 | 
373 |      Query:  PING 1473523721 662865
374 |      Reply:  PING 1473523721 662865
375 | 
376 |      Query:  PING foo bar baz
377 |      Reply:  PING foo bar baz
378 | 
379 | A.6.  SOURCE
380 | 
381 |    Query:  SOURCE
382 |    Reply:  SOURCE <info>
383 | 
384 |    Clients which implement this message MUST reply with a URL where the
385 |    source code for the client can be found.
386 | 
387 |    SOURCE is rarely implemented.  Clients MAY implement this CTCP
388 |    message.
389 | 
390 | 
391 | 
392 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 7]
393 | 
394 | Internet-Draft                  IRC CTCP                        May 2021
395 | 
396 | 
397 |    Example:
398 | 
399 |      Query:  SOURCE
400 |      Reply:  SOURCE https://weechat.org/download
401 | 
402 | A.7.  TIME
403 | 
404 |    Query:  TIME
405 |    Reply:  TIME <timestring>
406 | 
407 |    Clients which implement this message MUST reply with the client's
408 |    local time in a human-readable format.  In practice, both the format
409 |    returned by ctime() and the format described in Section 3.3 of
410 |    [RFC5322] are common.  Earlier specifications recommended prefixing
411 |    the time string with a colon, but this is no longer recommended.
412 | 
413 |    Clients MAY default to UTC time for privacy reasons and only respond
414 |    with the local time if the user enables it.
415 | 
416 |    TIME is almost universally implemented.  Clients MAY implement this
417 |    CTCP message.
418 | 
419 |    Example:
420 | 
421 |      Query:  TIME
422 |      Reply:  TIME Mon, 08 May 2017 09:15:29 GMT
423 | 
424 | A.8.  VERSION
425 | 
426 |    Query:  VERSION
427 |    Reply:  VERSION <verstring>
428 | 
429 |    Clients which implement this message MUST reply with the name and
430 |    version of the client software in use.  There is no specified format
431 |    for the version string.
432 | 
433 |    Clients MAY receive more than one reply after sending a VERSION
434 |    query.  Clients may allow users to customise the response value for
435 |    this query.
436 | 
437 |    VERSION is universally implemented.  Clients SHOULD implement this
438 |    CTCP message.
439 | 
440 |    Example:
441 | 
442 |      Query:  VERSION
443 |      Reply:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
444 | 
445 | 
446 | 
447 | 
448 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 8]
449 | 
450 | Internet-Draft                  IRC CTCP                        May 2021
451 | 
452 | 
453 | A.9.  USERINFO
454 | 
455 |    Query:  USERINFO
456 |    Reply:  USERINFO <info>
457 | 
458 |    Clients which implement this message MUST reply with miscellaneous
459 |    information about the user (typically the contents of their realname/
460 |    gecos field).
461 | 
462 |    USERINFO is largely obsolete.  Clients MAY implement this CTCP
463 |    message.
464 | 
465 |    Example:
466 | 
467 |      Query:  USERINFO
468 |      Reply:  USERINFO fred (Fred Foobar)
469 | 
470 | Appendix B.  Change History [RFC Editor: Please remove this section]
471 | 
472 |    Changes from draft 2 (... 2021)
473 | 
474 |    *  Removed the CTCP Types section (thanks James).
475 | 
476 |    *  Added advice on leading spaces in messages (thanks Sadie).
477 | 
478 |    *  Minor ABNF fix.
479 | 
480 |    Changes from draft 1 (July 18, 2017)
481 | 
482 |    *  General editing, fixed mistypes.
483 | 
484 |    *  Simplified some of the examples.
485 | 
486 |    Changes from draft 0 (May 29, 2017)
487 | 
488 |    *  Added note about servers truncating CTCP messages (thanks Sadie).
489 | 
490 |    *  Fixed misspellings and added note to TIME about previously-
491 |       recommended prefix (thanks Patrick).
492 | 
493 |    *  Mentioned how to parse/send empty ACTION messages (thanks dequis
494 |       and the crew).
495 | 
496 | Authors' Addresses
497 | 
498 |    Mantas Mikulėnas
499 |    Independent
500 | 
501 | 
502 | 
503 | 
504 | Mikulėnas & Oakley      Expires 24 November 2021                [Page 9]
505 | 
506 | Internet-Draft                  IRC CTCP                        May 2021
507 | 
508 | 
509 |    Email: grawity@gmail.com
510 | 
511 | 
512 |    Daniel Oakley (editor)
513 |    ircdocs
514 | 
515 |    Email: daniel@danieloaks.net
516 | 
517 | 
518 | 
519 | 
520 | 
521 | 
522 | 
523 | 
524 | 
525 | 
526 | 
527 | 
528 | 
529 | 
530 | 
531 | 
532 | 
533 | 
534 | 
535 | 
536 | 
537 | 
538 | 
539 | 
540 | 
541 | 
542 | 
543 | 
544 | 
545 | 
546 | 
547 | 
548 | 
549 | 
550 | 
551 | 
552 | 
553 | 
554 | 
555 | 
556 | 
557 | 
558 | 
559 | 
560 | Mikulėnas & Oakley      Expires 24 November 2021               [Page 10]
561 | 


--------------------------------------------------------------------------------
/versions/ctcp/draft-oakley-irc-ctcp-00.txt:
--------------------------------------------------------------------------------
  1 | 
  2 | 
  3 | 
  4 | 
  5 | Network Working Group                                       M. Mikulenas
  6 | Internet-Draft                                               Independent
  7 | Updates: 1459, 2812 (if approved)                              D. Oakley
  8 | Intended status: Informational                                   ircdocs
  9 | Expires: November 30, 2017                                  May 29, 2017
 10 | 
 11 | 
 12 |          Internet Relay Chat: Client-to-Client Protocol (CTCP)
 13 |                         draft-oakley-irc-ctcp-00
 14 | 
 15 | Abstract
 16 | 
 17 |    This document describes the Client-to-Client Protocol (CTCP), which
 18 |    lets Internet Relay Chat (IRC) clients send each other messages that
 19 |    get displayed or responded to in special ways.  CTCP has been widely
 20 |    implemented, with most clients supporting it natively.  This document
 21 |    outlines how to implement CTCP and the most common messages used.
 22 | 
 23 |    It updates RFC 1459 and RFC 2812.
 24 | 
 25 | Status of This Memo
 26 | 
 27 |    This Internet-Draft is submitted in full conformance with the
 28 |    provisions of BCP 78 and BCP 79.
 29 | 
 30 |    Internet-Drafts are working documents of the Internet Engineering
 31 |    Task Force (IETF).  Note that other groups may also distribute
 32 |    working documents as Internet-Drafts.  The list of current Internet-
 33 |    Drafts is at http://datatracker.ietf.org/drafts/current/.
 34 | 
 35 |    Internet-Drafts are draft documents valid for a maximum of six months
 36 |    and may be updated, replaced, or obsoleted by other documents at any
 37 |    time.  It is inappropriate to use Internet-Drafts as reference
 38 |    material or to cite them other than as "work in progress."
 39 | 
 40 |    This Internet-Draft will expire on November 30, 2017.
 41 | 
 42 | Copyright Notice
 43 | 
 44 |    Copyright (c) 2017 IETF Trust and the persons identified as the
 45 |    document authors.  All rights reserved.
 46 | 
 47 |    This document is subject to BCP 78 and the IETF Trust's Legal
 48 |    Provisions Relating to IETF Documents
 49 |    (http://trustee.ietf.org/license-info) in effect on the date of
 50 |    publication of this document.  Please review these documents
 51 |    carefully, as they describe your rights and restrictions with respect
 52 |    to this document.
 53 | 
 54 | 
 55 | 
 56 | Mikulenas & Oakley      Expires November 30, 2017               [Page 1]
 57 | 
 58 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
 59 | 
 60 | 
 61 | Table of Contents
 62 | 
 63 |    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 64 |    2.  Message Syntax  . . . . . . . . . . . . . . . . . . . . . . .   3
 65 |    3.  Message Types . . . . . . . . . . . . . . . . . . . . . . . .   3
 66 |      3.1.  Extended formatting . . . . . . . . . . . . . . . . . . .   4
 67 |      3.2.  Metadata Query  . . . . . . . . . . . . . . . . . . . . .   4
 68 |      3.3.  Extended Query  . . . . . . . . . . . . . . . . . . . . .   4
 69 |    4.  Messages  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
 70 |    5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
 71 |    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
 72 |    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
 73 |    8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
 74 |    Appendix A.  Message List . . . . . . . . . . . . . . . . . . . .   6
 75 |      A.1.  ACTION  . . . . . . . . . . . . . . . . . . . . . . . . .   6
 76 |      A.2.  CLIENTINFO  . . . . . . . . . . . . . . . . . . . . . . .   7
 77 |      A.3.  DCC . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 78 |      A.4.  FINGER  . . . . . . . . . . . . . . . . . . . . . . . . .   7
 79 |      A.5.  PING  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 80 |      A.6.  SOURCE  . . . . . . . . . . . . . . . . . . . . . . . . .   8
 81 |      A.7.  TIME  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 82 |      A.8.  VERSION . . . . . . . . . . . . . . . . . . . . . . . . .   9
 83 |      A.9.  USERINFO  . . . . . . . . . . . . . . . . . . . . . . . .   9
 84 |    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
 85 | 
 86 | 1.  Introduction
 87 | 
 88 |    The core Internet Relay Chat (IRC) protocol as described in [RFC1459]
 89 |    and [RFC2812] only has a single command for regular user messages,
 90 |    and does not provide a way for clients to exchange information
 91 |    directly.  Client-to-Client Protocol (CTCP) messages let clients
 92 |    exchange messages that get displayed or responded to in special ways.
 93 |    Some examples of how CTCP is used is to request special formatting on
 94 |    messages, query other clients for metadata, and help initiate file
 95 |    transfers with other clients.
 96 | 
 97 |    This document goes over the subset of CTCP which is commonly
 98 |    implemented, and is compatible with clients implementing CTCP as
 99 |    described by older documents.
100 | 
101 |    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 |    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103 |    document are to be interpreted as described in [RFC2119].
104 | 
105 | 
106 | 
107 | 
108 | 
109 | 
110 | 
111 | 
112 | Mikulenas & Oakley      Expires November 30, 2017               [Page 2]
113 | 
114 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
115 | 
116 | 
117 | 2.  Message Syntax
118 | 
119 |    CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies
120 |    are sent with NOTICE command.  To indicate a CTCP query or reply, the
121 |    body of the message (the second parameter) begins with the CTCP
122 |    delimiter.  The ABNF [RFC5234] for this message body is as follows:
123 | 
124 |         delim    = %x01
125 | 
126 |         command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
127 |                       ; any octet except NUL, delim, CR, LF, and " "
128 | 
129 |         params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
130 |                       ; any octet except NUL, delim, CR, and LF
131 | 
132 |         body     = delim command [ SPACE params ] [ delim ]
133 | 
134 |    Commands are case-insensitive.  When creating new CTCP commands,
135 |    authors SHOULD use only alphanumeric characters for ease of
136 |    implementation.
137 | 
138 |    The final CTCP delimiter SHOULD be sent on outgoing messages for
139 |    compatibility reasons, and software MUST accept incoming messages
140 |    which lack it.  This is due to how certain clients implement message
141 |    splitting and truncation.
142 | 
143 |    Queries MAY be sent to channels.  When these queries are responded
144 |    to, the responses are sent to the querying client rather than the
145 |    channel which the query was originally sent to.
146 | 
147 |    Many servers implement optional filtering so that only the ACTION
148 |    CTCP message can be sent to channels.  When this is done, it can
149 |    typically be enabled or disabled by channel operators with a channel
150 |    mode.
151 | 
152 |    Here are two examples of CTCP queries and replies:
153 | 
154 |      :alice PRIVMSG bob :\x01VERSION\x01
155 |      :bob NOTICE alice :\x01VERSION Snak for Macintosh 4.13 English\x01
156 | 
157 |      :alice PRIVMSG #ircv3 :\x01PING 1473523796 918320\x01
158 |      :bob NOTICE alice :\x01PING 1473523796 918320\x01
159 | 
160 | 3.  Message Types
161 | 
162 |    CTCP messages generally take on one of these types.  These message
163 |    types are defined here to simplify understanding, and aren't
164 |    differentiated by the protocol itself.
165 | 
166 | 
167 | 
168 | Mikulenas & Oakley      Expires November 30, 2017               [Page 3]
169 | 
170 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
171 | 
172 | 
173 | 3.1.  Extended formatting
174 | 
175 |    This type of CTCP is used to request special formatting of a user-
176 |    visible message.  That is, to send a user-visible message that should
177 |    be displayed differently from regular messages - e.g. as an action, a
178 |    whisper, an announcement.
179 | 
180 |    Extended formatting messages are sent as a PRIVMSG, and are expected
181 |    to be used in channels as well as between clients.  There is no
182 |    automatic response to this message type, as it is not a query nor
183 |    reply.
184 | 
185 |    These messages are sent as a PRIVMSG and can have parameters, but
186 |    generate no reply.
187 | 
188 |    Example:
189 | 
190 |      :dan PRIVMSG #ircv3 :\x01ACTION writes some specs!\x01
191 | 
192 | 3.2.  Metadata Query
193 | 
194 |    This type of CTCP is used to provide relatively static information
195 |    about the target client, user or connection.
196 | 
197 |    This CTCP takes the form of a query and a response (as a PRIVMSG and
198 |    NOTICE, respectively).  Due to how bouncers interact with multiple
199 |    clients, there may sometimes be multiple responses to queries.
200 | 
201 |    Metadata queries MUST NOT require the recipient to implement any side
202 |    effects (beyond sending the reply itself); if a CTCP message causes
203 |    side effects by design, it should be categorized as an extended query
204 |    instead.
205 | 
206 |    Metadata queries do not have any parameters, but expect a reply with
207 |    parameters as the response data.
208 | 
209 |    Example:
210 | 
211 |      :alice PRIVMSG bob :\x01VERSION\x01
212 |      :bob NOTICE alice :\x01VERSION SaberChat 27.5\x01
213 | 
214 | 3.3.  Extended Query
215 | 
216 |    This type of CTCP is used to provide dynamic information or invoke
217 |    actions from the client.
218 | 
219 |    This CTCP takes the form of a query and a response (as a PRIVMSG and
220 |    NOTICE, respectively).
221 | 
222 | 
223 | 
224 | Mikulenas & Oakley      Expires November 30, 2017               [Page 4]
225 | 
226 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
227 | 
228 | 
229 |    Queries sent to a channel always generate private replies.
230 | 
231 |    Extended queries and replies may have parameters.
232 | 
233 |    Example:
234 | 
235 |      :alice PRIVMSG bob :\x01PING 1473523796 918320\x01
236 |      :bob NOTICE alice :\x01PING 1473523796 918320\x01
237 | 
238 | 4.  Messages
239 | 
240 |    CTCP messages themselves are not standardised.  Clients that receive
241 |    either unexpected messages or known messages with unexpected values
242 |    SHOULD ignore them and produce no response to the sending user.
243 |    Clients MAY receive more than one response per user for a query they
244 |    send, due to multiple clients being connected behind an IRC bouncer.
245 | 
246 | 5.  Acknowledgements
247 | 
248 |    Thanks to the IRCv3 group for giving feedback on this specification,
249 |    and to Khaled for advice on client flood protection.
250 | 
251 |    Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating
252 |    the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who
253 |    wrote and revised related specifications.
254 | 
255 |    Special thanks to dequis, Peter Powell and James Wheare for help with
256 |    this and related work.
257 | 
258 | 6.  Security Considerations
259 | 
260 |    CTCP messages are completely untrusted data, and clients MUST NOT
261 |    assume that they are well-formed or complete.
262 | 
263 |    Older CTCP specifications describe quoting methods which are complex
264 |    and not widely implemented.  Implementations SHOULD NOT implement
265 |    "low-level quoting" or "CTCP-level quoting" when parsing messages.
266 | 
267 |    Older CTCP specifications describe including more than one CTCP
268 |    message inside a single PRIVMSG or NOTICE command.  Implementations
269 |    SHOULD NOT implement this form of CTCP parsing as it is not widely-
270 |    implemented and may result in an implementation that can be more
271 |    easily flooded off the server they are connected to.
272 | 
273 |    CTCP requests can be abused to flood clients off the server they are
274 |    connected to.  Clients may ignore or delay excessive incoming
275 |    requests to protect against this.
276 | 
277 | 
278 | 
279 | 
280 | Mikulenas & Oakley      Expires November 30, 2017               [Page 5]
281 | 
282 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
283 | 
284 | 
285 | 7.  IANA Considerations
286 | 
287 |    This document has no actions for IANA.
288 | 
289 | 8.  Normative References
290 | 
291 |    [RFC1459]  Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
292 |               RFC 1459, DOI 10.17487/RFC1459, May 1993,
293 |               <http://www.rfc-editor.org/info/rfc1459>.
294 | 
295 |    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
296 |               Requirement Levels", BCP 14, RFC 2119,
297 |               DOI 10.17487/RFC2119, March 1997,
298 |               <http://www.rfc-editor.org/info/rfc2119>.
299 | 
300 |    [RFC2812]  Kalt, C., "Internet Relay Chat: Client Protocol",
301 |               RFC 2812, DOI 10.17487/RFC2812, April 2000,
302 |               <http://www.rfc-editor.org/info/rfc2812>.
303 | 
304 |    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
305 |               Specifications: ABNF", STD 68, RFC 5234,
306 |               DOI 10.17487/RFC5234, January 2008,
307 |               <http://www.rfc-editor.org/info/rfc5234>.
308 | 
309 |    [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
310 |               DOI 10.17487/RFC5322, October 2008,
311 |               <http://www.rfc-editor.org/info/rfc5322>.
312 | 
313 | Appendix A.  Message List
314 | 
315 |    This section is not exhaustive, and only lists those CTCP messages
316 |    which are widely implemented across the IRC ecosystem.
317 | 
318 |    The reply and parameter lines below use a simplified syntax that
319 |    represents variables by surrounding them with angle brackets,.
320 | 
321 | A.1.  ACTION
322 | 
323 |    Type:    Extended Formatting
324 |    Params:  ACTION <text>
325 | 
326 |    This extended formatting message shows that <text> should be
327 |    displayed as a third-person action or emote; in clients, it's
328 |    generally activated with the command "/me".
329 | 
330 |    ACTION is universally implemented and very commonly used.  Clients
331 |    MUST implement this CTCP message to effectively use IRC.
332 | 
333 | 
334 | 
335 | 
336 | Mikulenas & Oakley      Expires November 30, 2017               [Page 6]
337 | 
338 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
339 | 
340 | 
341 |    Example:
342 | 
343 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
344 | 
345 |      Formatted:  * dan does it!
346 | 
347 | A.2.  CLIENTINFO
348 | 
349 |    Type:   Extended Query
350 |    Reply:  CLIENTINFO <tokens>
351 | 
352 |    This extended query returns a list of the CTCP messages that this
353 |    client supports and implements, delimited by a single ASCII space.
354 | 
355 |    CLIENTINFO is widely implemented.  Clients SHOULD implement this CTCP
356 |    message.
357 | 
358 |    Example:
359 | 
360 |      Query:     CLIENTINFO
361 |      Response:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
362 | 
363 | A.3.  DCC
364 | 
365 |    Type:    Extended Query
366 |    Params:  DCC <type> <argument> <host> <port>
367 | 
368 |    This extended query is used to setup and control connections that go
369 |    directly between clients, bypassing the IRC server.  This is
370 |    typically used for features that require a large amount of traffic
371 |    between clients or simply wish to bypass the server itself such as
372 |    file transfer and direct chat.
373 | 
374 |    The Direct Client-to-Client (DCC) Protocol requires its own
375 |    specification, and is not described in-depth here.
376 | 
377 |    DCC is widely implemented.  Clients MAY implement this CTCP message.
378 | 
379 | A.4.  FINGER
380 | 
381 |    Type:   Metadata Query
382 |    Reply:  FINGER <info>
383 | 
384 |    This metadata query returns miscellaneous info about the user,
385 |    typically the same information that's held in their realname field.
386 | 
387 |    However, some implementations return the client name and version
388 |    instead.
389 | 
390 | 
391 | 
392 | Mikulenas & Oakley      Expires November 30, 2017               [Page 7]
393 | 
394 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
395 | 
396 | 
397 |    FINGER is largely obsolete.  Clients MAY implement this CTCP message.
398 | 
399 |    Example:
400 | 
401 |      Query:     FINGER
402 |      Response:  FINGER WeeChat 1.8-dev
403 | 
404 | A.5.  PING
405 | 
406 |    Type:    Extended Query
407 |    Params:  PING <info>
408 | 
409 |    This extended query is used to confirm reachability with other
410 |    clients and to check latency.  When receiving a CTCP PING, the reply
411 |    MUST contain exactly the same parameters as the original query.
412 | 
413 |    PING is universally implemented.  Clients SHOULD implement this CTCP
414 |    message.
415 | 
416 |    Example:
417 | 
418 |      Query:     PING 1473523721 662865
419 |      Response:  PING 1473523721 662865
420 | 
421 |      Query:     PING foo bar baz
422 |      Response:  PING foo bar baz
423 | 
424 | A.6.  SOURCE
425 | 
426 |    Type:   Metadata Query
427 |    Reply:  SOURCE <info>
428 | 
429 |    This metadata query is used to return the location of the source code
430 |    for the client.
431 | 
432 |    SOURCE is rarely implemented.  Clients MAY implement this CTCP
433 |    message.
434 | 
435 |    Example:
436 | 
437 |      Query:     SOURCE
438 |      Response:  SOURCE https://weechat.org/download
439 | 
440 | A.7.  TIME
441 | 
442 |    Type:    Extended Query
443 |    Params:  TIME <timestring>
444 | 
445 | 
446 | 
447 | 
448 | Mikulenas & Oakley      Expires November 30, 2017               [Page 8]
449 | 
450 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
451 | 
452 | 
453 |    This extended query is used to return the client's local time in an
454 |    unspecified human-readable format.  In practice, both the format
455 |    output by ctime() and the format described in Section 3.3 of
456 |    [RFC5322] are common.
457 | 
458 |    New implementations MAY default to UTC time for privacy reasons.
459 | 
460 |    TIME is almost universally implemented.  Clients SHOULD implement
461 |    this CTCP message.
462 | 
463 |    Example:
464 | 
465 |      Query:     TIME
466 |      Response:  TIME Mon, 08 May 2017 09:15:29 GMT
467 | 
468 | A.8.  VERSION
469 | 
470 |    Type:   Metadata Query
471 |    Reply:  VERSION <verstring>
472 | 
473 |    This metadata query is used to return the name and version of the
474 |    client software in use.  There is no specified format for the version
475 |    string.
476 | 
477 |    Clients may allow users to customise the response value for this
478 |    query.
479 | 
480 |    VERSION is universally implemented.  Clients SHOULD implement this
481 |    CTCP message.
482 | 
483 |    Example:
484 | 
485 |      Query:     VERSION
486 |      Response:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
487 | 
488 | A.9.  USERINFO
489 | 
490 |    Type:   Metadata Query
491 |    Reply:  USERINFO <info>
492 | 
493 |    This metadata query returns miscellaneous info about the user,
494 |    typically the same information that's held in their realname field.
495 | 
496 |    However, some implementations return "<nickname> (<realname>)"
497 |    instead.
498 | 
499 |    USERINFO is largely obsolete.  Clients MAY implement this CTCP
500 |    message.
501 | 
502 | 
503 | 
504 | Mikulenas & Oakley      Expires November 30, 2017               [Page 9]
505 | 
506 | Internet-Draft        IRC Client-to-Client Protocol             May 2017
507 | 
508 | 
509 |    Example:
510 | 
511 |      Query:     USERINFO
512 |      Response:  USERINFO fred (Fred Foobar)
513 | 
514 | Authors' Addresses
515 | 
516 |    Mantas Mikulenas
517 |    Independent
518 | 
519 |    Email: grawity@gmail.com
520 | 
521 | 
522 |    Daniel Oakley
523 |    ircdocs
524 | 
525 |    Email: daniel@danieloaks.net
526 | 
527 | 
528 | 
529 | 
530 | 
531 | 
532 | 
533 | 
534 | 
535 | 
536 | 
537 | 
538 | 
539 | 
540 | 
541 | 
542 | 
543 | 
544 | 
545 | 
546 | 
547 | 
548 | 
549 | 
550 | 
551 | 
552 | 
553 | 
554 | 
555 | 
556 | 
557 | 
558 | 
559 | 
560 | Mikulenas & Oakley      Expires November 30, 2017              [Page 10]
561 | 


--------------------------------------------------------------------------------
/info/grawity-sasl-20150304.md:
--------------------------------------------------------------------------------
  1 | # SASL authentication in IRC
  2 | 
  3 | © 2014 Mantas Mikulėnas &lt;<grawity@gmail.com>&gt;
  4 | 
  5 | This documentation is released under Creative Commons 3.0 Attribution license.
  6 | 
  7 | ---
  8 | 
  9 | Despite at least four ircds having added SASL support by now, there has been no documentation on how this should be done from the server side.
 10 | 
 11 | While SASL is a generic authentication layer, used by over a dozen Internet protocols, its implementation in IRC is somewhat different than anywhere else, since the authentication is almost never performed by the IRC server (ircd) itself, but rather forwarded to a services pseudoserver. This means that adding SASL support isn't a matter of linking to the right library like libgsasl, but rather a matter of exchanging data with another server on the network.
 12 | 
 13 | SASL is documented in [RFC 4422][sasl]; in short, it is based around authentication "mechanisms", each of which defines a series of messages that the client and server should exchange, the most common mechanism being PLAIN ([RFC 4616][sasl-plain]) where the only exchange consists of the username and password being sent directly.
 14 | 
 15 | For an IRC server that relies on separate services (which this document is aimed at), the exact SASL mechanisms being used are not important, as it only has to relay the mechanism name and data between client and services.
 16 | 
 17 | (An ircd _could_ act as the SASL server by itself, either by using libgsasl, Dovecot, Cyrus libsasl, or by implementing some mechanisms internally – to the client it would not matter. So far, however, this has never been done (aside from Microsoft's IRCX servers), mostly because the existing services packages provide sufficient features, and they already handle old-style "/msg"-based authentication anyway, so this would only make sense when writing a new ircd that has all services features built in.)
 18 | 
 19 | ## Requirements for ircds
 20 | 
 21 | To add SASL support to an ircd, it needs to have three features:
 22 | 
 23 |   * _unique IDs_ to distinguish between connections,
 24 |   * a link _protocol command_ to carry the SASL exchange between you and the services pseudoserver,
 25 |   * and ability to store the _account name_ that each user has logged in to.
 26 | 
 27 | ### Link protocol updates
 28 | 
 29 | Almost all existing implementations rely on a services pseudoserver (such as Atheme, X3, or Anope) to actually process the SASL exchange and authenticate the user, in a similar way to how services handle old-style authentication "/msg NickServ …" and so on. Therefore they add a server-to-server command encapsulating the SASL exchange between ircd and services.
 30 | 
 31 | The `SASL` command varies slightly between protocols, but the basic parameters are the same: target server for routing the message; client UID; SASL message type; and 1-2 data parameters. (In protocols that support it ENCAP or a similar feature should be used, to let the messages safely pass through out-of-date hubs which otherwise drop unknown commands.)
 32 | 
 33 | ### Unique connection IDs
 34 | 
 35 | On IRC, the SASL authentication happens during user "registration", that is, _before_ annoucing the user to the rest of the network. This allows removing such race conditions as the user being visible before their vhost/cloak is applied, or trying to join "registered-only" channels before their account name gets set. (However, SASL by itself is not enough for this; the server-to-server protocol also needs to consider these race conditions, for example, the EUID extension to TS6. This is problematic with protocols that first introduce the user and only then use ENCAP or METADATA to broadcast their account name…)
 36 | 
 37 | The unique ID requirement exists because, as mentioned above, at the time of SASL authentication the user hasn't been announced to the network yet and quite possibly might not even have chosen a nickname at all. (It is **not** required that NICK/USER commands be sent before trying SASL authentication – they could arrive during or after it.) Besides, clients can change the nickname at any time. This means that services need a way to track authentication state per connection.
 38 | 
 39 | For TS6 and IRCnet protocols, which already use UIDs everywhere, this is not a problem; in other protocols (like TS5, P10, RFC2813) the ircd will need to generate a temporary "pseudo-UID" (aka PUID) for each connection. It is recommended to do this by concatenating the server name, a separator like "!", and a random cookie – this also makes it easier for services to send the reply back to the correct server. (Of course, it would be even better to upgrade your protocol to TS6, but this takes more time…)
 40 | 
 41 | ### Account names
 42 | 
 43 | While not specific to SASL (e.g. also seen in QuakeNet), all ircds that implement it are capable of storing the user's account/login name (for account-based services packages like Atheme, X3, or even modern Anope versions).
 44 | 
 45 | During SASL authentication, the services will send another command to set the account name. Some ircds (e.g. Nefarious) use `SASL` message type "L", while others add a dedicated command like `SVSLOGIN` or `ENCAP * SVSLOGIN`; the exact choice is not very important.
 46 | 
 47 | Yet others use generic commands like `PROP` or `METADATA`. This mostly works, but can be problematic – it must work with not-yet-announced users, so if the protocol has `METADATA` but lacks UIDs, then the command will need to be updated to accept pseudo-UIDs in addition to nicknames. For another, services may want to know the difference between an account name that was received during a netburst (e.g. if a distant server splits and rejoins) and should be accepted, versus one that a server attempted to set for an existing user (bypassing services) which services may want to reject.
 48 | 
 49 | ## Server-to-server SASL protocol
 50 | 
 51 | The client's server and the services pseudoserver exchange SASL messages containing the client's unique ID, message type, and attached data (usually one or two parameters). These messages are encapsulated in protocol-specific commands (e.g. "SASL" or "ENCAP SASL").
 52 | 
 53 | ### Start of authentication
 54 | 
 55 | When the client initiates authentication, the server sends a "S" message on behalf of the client, with the chosen SASL mechanism name as data.
 56 | 
 57 | If the chosen mechanism is "EXTERNAL", and if the server has any external authentication data (e.g. TLS client certificate fingerprint or Unix user ID), it must be sent as an additional parameter to the "S" message. (The form is unspecified, though it is highly recommended to follow existing implementations.)
 58 | 
 59 | The ircd SHOULD also send a "H" message containing the client's host address; such a "H" message MUST precede any "S" messages.
 60 | 
 61 | ### Bad mechanism indication
 62 | 
 63 | If the client chooses an unknown mechanism, services first send a "M" message containing a comma-separated mechanism list (corresponding to a 908 numeric), followed by a "D" message containing "F" to signal failure (corresponding to a 904 numeric).
 64 | 
 65 | ### Back-and-forth
 66 | 
 67 | If a _known_ mechanism is chosen, the server (on behalf of the client) and services exchange "C" commands containing Base64-encoded mechanism data, or `+` if the mechanism data is empty.
 68 | 
 69 | As soon as the mechanism is chosen, services MUST send the initial reply. If there is no data to send (e.g. if a "client-first" mechanism was chosen), services MUST still send an empty reply \[as above\].
 70 | 
 71 | (However, for certain compatibility reasons, it is advised that services treat incoming "S" and "C" messages identically – that is, after the mechanism was chosen, accept authentication data in either "S" or "C" messages.)
 72 | 
 73 | If the initial "S" message was broadcast (e.g. "ENCAP \* …") and no reply from services was received, the server SHOULD abort authentication after a timeout, by sending a "D" message containing "A" to services (corresponding to numeric 906 to the client).
 74 | 
 75 | ### Success indication
 76 | 
 77 | After successful authentication, services first send a "L" message (or protocol-specific equivalent) containing the user's account name \[i.e. the authzid\], followed by a "D" message containing "S" to signal success.
 78 | 
 79 | It is up to the server protocol implementors whether a SASL "L" message or a protocol-specific command is used. (For example, TS6 uses the "SVSLOGIN" command, while m\_spanningtree uses "METADATA".)
 80 | 
 81 | The ircd MUST store the account name for the connection.
 82 | 
 83 | ### Failed authentication indication
 84 | 
 85 | If the client chooses a _known_ mechanism but sends bad authentication data, services send a "D" message containing "F" to signal failure (corresponding to a 904 numeric).
 86 | 
 87 | ### Client abort (implicit)
 88 | 
 89 | If the client either disconnects or completes registration (by sending "NICK" + "USER" + CAP END") in the middle of SASL authentication exchange, the server must abort the authentication by sending a "D" message containing "A" to services, and a 906 numeric to the client (if still connected).
 90 | 
 91 | ## Interaction between server-server and RFC 1459 client-server protocols
 92 | 
 93 | The server MUST support the IRCv3 "capability-negotiation" and "sasl" extensions. All examples in this document use the `CAP` and `AUTHENTICATE` commands and numeric replies defined by IRCv3.
 94 | 
 95 | The server MAY, upon receiving the `PASS` command, use the password to automatically perform SASL PLAIN authentication with services on behalf of the client.
 96 | 
 97 | The server SHOULD NOT support the IRCX `AUTH` command.
 98 | 
 99 | ### From IRCv3 SASL protocol to services
100 | 
101 | On receiving `AUTHENTICATE <data>` from the client:
102 | 
103 |   - If this is a new SASL session, the server sends "H" and "S" messages to services (as documented in previous section). This first message has the SASL mechanism name as data.
104 | 
105 |   - Otherwise, the server sends a "C" message to services, containing the same data.
106 | 
107 | The "AUTHENTICATE" parameter MUST be at least 1 byte and at most 400 bytes long. The ircd MUST reject longer parameters with ERR\_SASLTOOLONG. If the client needs to send a larger reply, it must fragment it as specified in the IRCv3 "sasl" extension.
108 | 
109 | If the client disconnects during an active SASL session, the server must abort the session by sending a "D" message containing "A" (abort) to services.
110 | 
111 | If the client completes registration (sends `NICK`, `USER`, `CAP END`), the server must abort the session, send a "D" message containing "A" to services, and send numeric 906 to the client.
112 | 
113 | ### From services to IRCv3 SASL protocol
114 | 
115 | On receiving a "C" (client) message from services, the server sends an `AUTHENTICATE <data>` reply to the client.
116 | 
117 | On receiving a "D" (done) message from services, the server sends an apropriate numeric and forgets the SASL session data.
118 | 
119 |   - If the "D" message data equals "S", the client is successfully authenticated, and numeric 903 is sent. (If the server doesn't know the account name yet, it's dealing with buggy services and should squit/jupe/napalm them as needed.)
120 | 
121 |   - If the "D" message data equals "F", the authentication failed and numeric 904 is sent. The server MAY disconnect the client for exceeding a failure limit; otherwise, the client MAY immediately start a new session by sending `AUTHENTICATE` again.
122 | 
123 | On receiving a "L" (login) message from services, the server stores the first parameter as the user's account name and sends numeric 900 to the client.
124 | 
125 | On receiving a "M" (mechlist) message from services, the server sends numeric 908 to the client, containing the received data as `<list>`. The server must not assume failed authentication from a "M" message alone.
126 | 
127 | Services never send "H" or "S" messages.
128 | 
129 | ### Summary of "SASL" message types
130 | 
131 |   - type "C" – client data
132 |       - sent in both directions
133 |       - data is the SASL buffer (directly converted to/from "AUTHENTICATE …data…")
134 |   - type "D" – authentication done
135 |       - sent in both directions
136 |       - data "A" (from ircd) – auth aborted by client
137 |       - data "S" (from services) – auth successful
138 |       - data "F" (from services) – auth failed
139 |   - type "H" – client host address
140 |       - sent by ircd
141 |       - data is the client's visible hostname
142 |       - extdata is the IP address (may be "`0`" if server refuses to reveal it)
143 |   - type "L" – user login
144 |       - sent by services
145 |       - data is the account name
146 |   - type "M" – supported mechanisms
147 |       - sent by services
148 |       - data is a comma-separated mechanism list, re-sent to user as RPL\_SASLMECHS
149 |   - type "S" – start authentication
150 |       - sent by ircd
151 |       - data is the mechanism given by user
152 |       - extdata is the SASL EXTERNAL authentication data supplied by ircd
153 | 
154 | ### Summary of numeric formats
155 | 
156 |     RPL_LOGGEDIN      "900 <nick> %s!%s@%s %s :You are now logged in as %s."
157 |     RPL_LOGGEDOUT     "901 <nick> %s!%s@%s :You are now logged out."
158 |     ERR_NICKLOCKED    "902 <nick> :You must use a nick assigned to you." // What's it for?
159 |     RPL_SASLSUCCESS   "903 <nick> :SASL authentication successful"
160 |     ERR_SASLFAILED    "904 <nick> :SASL authentication failed"
161 |     ERR_SASLTOOLONG   "905 <nick> :SASL message too long"
162 |     ERR_SASLABORTED   "906 <nick> :SASL authentication aborted"
163 |     ERR_SASLALREADY   "907 <nick> :You have already completed SASL authentication"
164 |     RPL_SASLMECHS     "908 <nick> <list> :are available SASL mechanisms"
165 | 
166 | ## Existing S2S protocol extensions
167 | 
168 | ### TS6 protocol
169 | 
170 | Refer to [ts6-protocol.txt][charybdis-ts6] in Charybdis source tree for the authoritative version of this documentation.
171 | 
172 | Command name: `SASL` (always ENCAP)
173 | 
174 | Command parameters:
175 | 
176 |   - source UID (either client or services)
177 |   - target UID (either services or client) or `*`
178 |   - message type ("S", "D", etc.)
179 |   - data (may be more than one parameter)
180 | 
181 | The `SASL` command requires ENCAP. The first message may be broadcast or sent to a configured services server name. All later messages are sent directly to the apropriate server.
182 | 
183 | The first message (sent on behalf of the client) has `*` as the target UID, as the SASL agent is not known yet. All later messages are exchanged between the client's and the agent's (service's) UIDs. Note that some services use their SID, instead of an UID, as the SASL agent.
184 | 
185 | The account name is set using a separate `SVSLOGIN` command, which is documented in [ts6-protocol.txt][charybdis-ts6].
186 | 
187 | ### InspIRCd (m\_spanningtree) version of TS6
188 | 
189 | The `SASL` command is the same as in TS6 (except InspIRCd prefers SIDs in ENCAP instead of server names, but that is out of scope for this file).
190 | 
191 | The account name is set using the [`METADATA` command][inspircd-metadata], in the "accountname" field.
192 | 
193 | ### UnrealIRCd 3.2 protocol
194 | 
195 | Command name: `SASL` (token `SY`)
196 | 
197 | Command parameters:
198 | 
199 |   - target server name
200 |   - client PUID
201 |   - message type ("S", "D", etc.)
202 |   - data (may be more than one parameter)
203 | 
204 | Since the protocol in version 3.2 does not have unique user IDs, the ircd generates a pseudo-UID consisting of the server name, a "!" character,  and a random cookie. (This is similar to UIDs, which also start with the server's ID.)
205 | 
206 | The account name is set using a `SVSLOGIN` command (token `SZ`):
207 | 
208 | Command parameters:
209 | 
210 |   - target server name
211 |   - client PUID
212 |   - account name
213 | 
214 | Note that the target server parameter is always specified by its full name, never by "@numeric".
215 | 
216 | ### Nefarious2 version of P10 protocol
217 | 
218 | Command token: `SASL`
219 | 
220 | Command parameters:
221 | 
222 |   - target server numeric or "\*"
223 |   - client PUID
224 |   - message type ("S", "D", etc.)
225 |   - data (may be more than one parameter)
226 | 
227 | Since the ircd assigns UIDs very late (immediately before introducing the user), during SASL authentication it generates a pseudo-UID consisting of the server ID, a "!" character, and a random cookie. (This is similar to UIDs, which also start with the server's ID.)
228 | 
229 | The accountname is set using the "L" SASL message.
230 | 
231 | ## Examples
232 | 
233 | TS6 example of successful EXTERNAL authentication:
234 | 
235 |     --> :0HA ENCAP *            SASL 0HAAAAF37 *         H poseidon.int 2001:db8::1a36
236 |     --> :0HA ENCAP *            SASL 0HAAAAF37 *         S EXTERNAL 57366a8747e...
237 |     <-- :5RV ENCAP hades.arpa   SASL 5RVAAAAA0 0HAAAAF37 C +
238 |     --> :0HA ENCAP services.int SASL 0HAAAAF37 5RVAAAAA0 C Z3Jhd2l0eQ==
239 |     <-- :5RV ENCAP hades.arpa   SVSLOGIN 0HAAAAF37 * * * grawity
240 |     <-- :5RV ENCAP hades.arpa   SASL 5RVAAAAA0 0HAAAAF37 D S
241 | 
242 | TS6 example of a bad mechanism error:
243 | 
244 |     --> :0HA ENCAP *          SASL 0HAAAAF37 *         H poseidon.int 192.0.42.7
245 |     --> :0HA ENCAP *          SASL 0HAAAAF37 *         S DIGEST-MD5
246 |     <-- :5RV ENCAP hades.arpa SASL 5RVAAAAA0 0HAAAAF37 M PLAIN,EXTERNAL,GSSAPI
247 |     <-- :5RV ENCAP hades.arpa SASL 5RVAAAAA0 0HAAAAF37 D F
248 | 
249 | InspIRCd 2.x m\_spanningtree example of successful SCRAM-SHA-1 authentication:
250 | 
251 |     --> :1SP ENCAP *   SASL 1SP000251 *         S SCRAM-SHA-1
252 |     <-- :00A ENCAP 1SP SASL 00AAAAAAG 1SP000251 C +
253 |     --> :1SP ENCAP *   SASL 1SP000251 00AAAAAAG C biwsbj1ncmF3aXR5LHI9L1NRQz...
254 |     <-- :00A ENCAP 1SP SASL 00AAAAAAG 1SP000251 C cj0vU1FDN3RqM0xMWOEhUZk...
255 |     --> :1SP ENCAP *   SASL 1SP000251 00AAAAAAG C Yz1iaXdzLHI9L1NRQzd0ajNMTF...
256 |     <-- :00A ENCAP 1SP SASL 00AAAAAAG 1SP000251 C dj03bGdLeElRRHBRT3Ss1Zn...
257 |     --> :1SP ENCAP *   SASL 1SP000251 00AAAAAAG C +
258 |     <-- :00A ENCAP 1SP SASL 00AAAAAAG 1SP000251 C +
259 |     <-- :00A METADATA 1SP000251 accountname :grawity
260 |     <-- :00A ENCAP 1SP SASL 00AAAAAAG 1SP000251 D S
261 | 
262 | UnrealIRCd 3.2 example of successful PLAIN authentication (without tokens or server-numerics):
263 | 
264 |     --> :hades.arpa SASL     services.int hades.arpa!23.760 S PLAIN
265 |     <-- :SaslServ   SASL     hades.arpa   hades.arpa!23.760 C +
266 |     --> :hades.arpa SASL     services.int hades.arpa!23.760 C Z3Jhd2l0eQB...
267 |     <-- :SaslServ   SVSLOGIN hades.arpa   hades.arpa!23.760 grawity
268 |     <-- :SaslServ   SASL     hades.arpa   hades.arpa!23.760 D S
269 | 
270 | UnrealIRCd 3.2 example of the client aborting authentication (note that D A is sent by the ircd, and services do not reply to it):
271 | 
272 |     --> :hades.arpa SASL services.int hades.arpa!24.5541 S PLAIN
273 |     <-- :SaslServ   SASL hades.arpa   hades.arpa!24.5541 C +
274 |     --> :hades.arpa SASL services.int hades.arpa!24.5541 D A
275 | 
276 | Nefarious2 P10 example of succesful PLAIN authentication (ircd has numeric `Aq`, services `AB`):
277 | 
278 |     --> Aq SASL *  Aq!17.1504627973 S :PLAIN
279 |     <-- AB SASL Aq Aq!17.1504627973 C +
280 |     --> Aq SASL AB Aq!17.1504627973 C :Z3Jhd2l0eQB...
281 |     <-- AB SASL Aq Aq!17.1504627973 L grawity
282 |     <-- AB SASL Aq Aq!17.1504627973 D S
283 | 
284 | ## Client examples
285 | 
286 | The client-to-server dialogue is already documented by the IRCv3 capability specification and by the IRCv3 "sasl" extension, but here's an example for comparison with the above server-to-server exchanges.
287 | 
288 |     --> AUTHENTICATE DIGEST-MD5
289 |     <-- :hades.arpa 908 grw PLAIN,EXTERNAL :are the available SASL mechanisms
290 |     <-- :hades.arpa 904 grw :SASL authentication failed
291 | 
292 |     --> AUTHENTICATE PLAIN
293 |     <-- AUTHENTICATE +
294 |     --> AUTHENTICATE Z3Jhd2l0eQB...
295 |     <-- :hades.arpa 900 grw grw!~root@rain.local grawity :You are now logged in as grawity.
296 |     <-- :hades.arpa 903 grw :SASL authentication successful
297 | 
298 | ("CAP REQ" is required but it is not technically part of the SASL exchange; it does not cause any message to services, therefore it was left out of this example. Likewise, PASS, NICK, and USER were omitted because they are not relevant to the SASL exchange and can be sent at any time.)
299 | 
300 | [charybdis-ts6]: https://github.com/atheme/charybdis/blob/master/doc/technical/ts6-protocol.txt
301 | [inspircd-metadata]: https://github.com/attilamolnar/wiki/blob/gh-pages/Modules/spanningtree/commands/METADATA.md
302 | [sasl]: https://tools.ietf.org/html/rfc4422
303 | [sasl-plain]: http://tools.ietf.org/search/rfc4616
304 | 
305 | <!--
306 | vim: ts=4:sw=4:et
307 | -->
308 | 


--------------------------------------------------------------------------------
/versions/ctcp/draft-oakley-irc-ctcp-01.txt:
--------------------------------------------------------------------------------
  1 | 
  2 | 
  3 | 
  4 | 
  5 | Network Working Group                                       M. Mikulenas
  6 | Internet-Draft                                               Independent
  7 | Updates: 1459, 2812 (if approved)                              D. Oakley
  8 | Intended status: Informational                                   ircdocs
  9 | Expires: January 19, 2018                                  July 18, 2017
 10 | 
 11 | 
 12 |          Internet Relay Chat: Client-to-Client Protocol (CTCP)
 13 |                         draft-oakley-irc-ctcp-01
 14 | 
 15 | Abstract
 16 | 
 17 |    This document describes the Client-to-Client Protocol (CTCP), which
 18 |    lets Internet Relay Chat (IRC) clients send each other messages that
 19 |    get displayed or responded to in special ways.  CTCP has been widely
 20 |    implemented, with most clients supporting it natively.  This document
 21 |    outlines how to implement CTCP and the most common messages used.
 22 | 
 23 |    It updates RFC 1459 and RFC 2812.
 24 | 
 25 | Status of This Memo
 26 | 
 27 |    This Internet-Draft is submitted in full conformance with the
 28 |    provisions of BCP 78 and BCP 79.
 29 | 
 30 |    Internet-Drafts are working documents of the Internet Engineering
 31 |    Task Force (IETF).  Note that other groups may also distribute
 32 |    working documents as Internet-Drafts.  The list of current Internet-
 33 |    Drafts is at http://datatracker.ietf.org/drafts/current/.
 34 | 
 35 |    Internet-Drafts are draft documents valid for a maximum of six months
 36 |    and may be updated, replaced, or obsoleted by other documents at any
 37 |    time.  It is inappropriate to use Internet-Drafts as reference
 38 |    material or to cite them other than as "work in progress."
 39 | 
 40 |    This Internet-Draft will expire on January 19, 2018.
 41 | 
 42 | Copyright Notice
 43 | 
 44 |    Copyright (c) 2017 IETF Trust and the persons identified as the
 45 |    document authors.  All rights reserved.
 46 | 
 47 |    This document is subject to BCP 78 and the IETF Trust's Legal
 48 |    Provisions Relating to IETF Documents
 49 |    (http://trustee.ietf.org/license-info) in effect on the date of
 50 |    publication of this document.  Please review these documents
 51 |    carefully, as they describe your rights and restrictions with respect
 52 |    to this document.
 53 | 
 54 | 
 55 | 
 56 | Mikulenas & Oakley      Expires January 19, 2018                [Page 1]
 57 | 
 58 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
 59 | 
 60 | 
 61 | Table of Contents
 62 | 
 63 |    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 64 |    2.  Message Syntax  . . . . . . . . . . . . . . . . . . . . . . .   3
 65 |    3.  Message Types . . . . . . . . . . . . . . . . . . . . . . . .   3
 66 |      3.1.  Extended formatting . . . . . . . . . . . . . . . . . . .   4
 67 |      3.2.  Metadata Query  . . . . . . . . . . . . . . . . . . . . .   4
 68 |      3.3.  Extended Query  . . . . . . . . . . . . . . . . . . . . .   4
 69 |    4.  Messages  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
 70 |    5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
 71 |    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
 72 |    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
 73 |    8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
 74 |    Appendix A.  Message List . . . . . . . . . . . . . . . . . . . .   6
 75 |      A.1.  ACTION  . . . . . . . . . . . . . . . . . . . . . . . . .   6
 76 |      A.2.  CLIENTINFO  . . . . . . . . . . . . . . . . . . . . . . .   7
 77 |      A.3.  DCC . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
 78 |      A.4.  FINGER  . . . . . . . . . . . . . . . . . . . . . . . . .   8
 79 |      A.5.  PING  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 80 |      A.6.  SOURCE  . . . . . . . . . . . . . . . . . . . . . . . . .   8
 81 |      A.7.  TIME  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
 82 |      A.8.  VERSION . . . . . . . . . . . . . . . . . . . . . . . . .   9
 83 |      A.9.  USERINFO  . . . . . . . . . . . . . . . . . . . . . . . .  10
 84 |    Appendix B.  Change History [RFC Editor: Please remove this
 85 |                 section] . . . . . . . . . . . . . . . . . . . . . .  10
 86 |    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
 87 | 
 88 | 1.  Introduction
 89 | 
 90 |    The core Internet Relay Chat (IRC) protocol as described in [RFC1459]
 91 |    and [RFC2812] only has a single command for regular user messages,
 92 |    and does not provide a way for clients to exchange information
 93 |    directly.  Client-to-Client Protocol (CTCP) messages let clients
 94 |    exchange messages that get displayed or responded to in special ways.
 95 |    Some examples of how CTCP is used is to request special formatting on
 96 |    messages, query other clients for metadata, and help initiate file
 97 |    transfers with other clients.
 98 | 
 99 |    This document goes over the subset of CTCP which is commonly
100 |    implemented, and is compatible with clients implementing CTCP as
101 |    described by older documents.
102 | 
103 |    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 |    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
105 |    document are to be interpreted as described in [RFC2119].
106 | 
107 | 
108 | 
109 | 
110 | 
111 | 
112 | Mikulenas & Oakley      Expires January 19, 2018                [Page 2]
113 | 
114 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
115 | 
116 | 
117 | 2.  Message Syntax
118 | 
119 |    CTCP queries are sent with the PRIVMSG IRC command, and CTCP replies
120 |    are sent with NOTICE command.  To indicate a CTCP query or reply, the
121 |    body of the message (the second parameter) begins with the CTCP
122 |    delimiter.  The ABNF [RFC5234] for this message body is as follows:
123 | 
124 |         delim    = %x01
125 | 
126 |         command  = 1*( %x02-09 / %x0B-0C / %x0E-1F / %x21-FF )
127 |                       ; any octet except NUL, delim, CR, LF, and " "
128 | 
129 |         params   = 1*( %x02-09 / %x0B-0C / %x0E-FF )
130 |                       ; any octet except NUL, delim, CR, and LF
131 | 
132 |         body     = delim command [ SPACE params ] [ delim ]
133 | 
134 |    Commands are case-insensitive.  When creating new CTCP commands,
135 |    authors SHOULD use only alphanumeric characters for ease of
136 |    implementation.
137 | 
138 |    The final CTCP delimiter SHOULD be sent on outgoing messages for
139 |    compatibility reasons, and software MUST accept incoming messages
140 |    which lack it.  This is due to how servers implement message
141 |    truncation and certain clients implement message splitting.
142 | 
143 |    Queries MAY be sent to channels.  When these queries are responded
144 |    to, the responses are sent to the querying client rather than the
145 |    channel which the query was originally sent to.
146 | 
147 |    Many servers implement optional filtering so that only the ACTION
148 |    CTCP message can be sent to channels.  When this is done, it can
149 |    typically be enabled or disabled by channel operators with a channel
150 |    mode.
151 | 
152 |    Here are two examples of CTCP queries and replies:
153 | 
154 |      :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
155 |      :bob!b@localhost NOTICE alice :\x01VERSION Snak for Mac 4.13\x01
156 | 
157 |      :alice!a@localhost PRIVMSG #ircv3 :\x01PING 1473523796 918320\x01
158 |      :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
159 | 
160 | 3.  Message Types
161 | 
162 |    CTCP messages generally take on one of these types.  These message
163 |    types are defined here to simplify understanding, and aren't
164 |    differentiated by the protocol itself.
165 | 
166 | 
167 | 
168 | Mikulenas & Oakley      Expires January 19, 2018                [Page 3]
169 | 
170 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
171 | 
172 | 
173 | 3.1.  Extended formatting
174 | 
175 |    This type of CTCP is used to request special formatting of a user-
176 |    visible message.  That is, to send a user-visible message that should
177 |    be displayed differently from regular messages - e.g. as an action, a
178 |    whisper, an announcement.
179 | 
180 |    Extended formatting messages are sent as a PRIVMSG, and are expected
181 |    to be used in channels as well as between clients.  There is no
182 |    automatic response to this message type, as it is not a query nor
183 |    reply.
184 | 
185 |    These messages are sent as a PRIVMSG and can have parameters, but
186 |    generate no reply.
187 | 
188 |    Example:
189 | 
190 |      :dan!u@localhost PRIVMSG #ircv3 :\x01ACTION writes some specs!\x01
191 | 
192 | 3.2.  Metadata Query
193 | 
194 |    This type of CTCP is used to provide relatively static information
195 |    about the target client, user or connection.
196 | 
197 |    This CTCP takes the form of a query and a response (as a PRIVMSG and
198 |    NOTICE, respectively).  Due to how bouncers interact with multiple
199 |    clients, there may sometimes be multiple responses to queries.
200 | 
201 |    Metadata queries MUST NOT require the recipient to implement any side
202 |    effects (beyond sending the reply itself); if a CTCP message causes
203 |    side effects by design, it should be categorized as an extended query
204 |    instead.
205 | 
206 |    Metadata queries do not have any parameters, but expect a reply with
207 |    parameters as the response data.
208 | 
209 |    Example:
210 | 
211 |      :alice!a@localhost PRIVMSG bob :\x01VERSION\x01
212 |      :bob!b@localhost NOTICE alice :\x01VERSION SaberChat 27.5\x01
213 | 
214 | 3.3.  Extended Query
215 | 
216 |    This type of CTCP is used to provide dynamic information or invoke
217 |    actions from the client.
218 | 
219 |    This CTCP takes the form of a query and a response (as a PRIVMSG and
220 |    NOTICE, respectively).
221 | 
222 | 
223 | 
224 | Mikulenas & Oakley      Expires January 19, 2018                [Page 4]
225 | 
226 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
227 | 
228 | 
229 |    Queries sent to a channel always generate private replies.
230 | 
231 |    Extended queries and replies may have parameters.
232 | 
233 |    Example:
234 | 
235 |      :alice!a@localhost PRIVMSG bob :\x01PING 1473523796 918320\x01
236 |      :bob!b@localhost NOTICE alice :\x01PING 1473523796 918320\x01
237 | 
238 | 4.  Messages
239 | 
240 |    CTCP messages themselves are not standardised.  Clients that receive
241 |    either unexpected messages or known messages with unexpected values
242 |    SHOULD ignore them and produce no response to the sending user.
243 |    Clients MAY receive more than one response per user for a query they
244 |    send, due to multiple clients being connected behind an IRC bouncer.
245 | 
246 | 5.  Acknowledgements
247 | 
248 |    Thanks to the IRCv3 group for giving feedback on this specification,
249 |    and to Khaled for advice on client flood protection.
250 | 
251 |    Thanks to Michael Sandrof for creating CTCP, Troy Rollo for creating
252 |    the related DCC protocol, as well as Klaus Zeuge and Ben Mesander who
253 |    wrote and revised related specifications.
254 | 
255 |    Special thanks to dequis, Peter Powell and James Wheare for help with
256 |    this and related work.
257 | 
258 | 6.  Security Considerations
259 | 
260 |    CTCP messages are completely untrusted data, and clients MUST NOT
261 |    assume that they are well-formed or complete.
262 | 
263 |    Older CTCP specifications describe quoting methods which are complex
264 |    and not widely implemented.  Implementations SHOULD NOT implement
265 |    "low-level quoting" or "CTCP-level quoting" when parsing messages.
266 | 
267 |    Older CTCP specifications describe including more than one CTCP
268 |    message inside a single PRIVMSG or NOTICE command.  Implementations
269 |    SHOULD NOT implement this form of CTCP parsing as it is not widely-
270 |    implemented and may result in an implementation that can be more
271 |    easily flooded off the server they are connected to.
272 | 
273 |    CTCP requests can be abused to flood clients off the server they are
274 |    connected to.  Clients may ignore or delay excessive incoming
275 |    requests to protect against this.
276 | 
277 | 
278 | 
279 | 
280 | Mikulenas & Oakley      Expires January 19, 2018                [Page 5]
281 | 
282 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
283 | 
284 | 
285 | 7.  IANA Considerations
286 | 
287 |    This document has no actions for IANA.
288 | 
289 | 8.  Normative References
290 | 
291 |    [RFC1459]  Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
292 |               RFC 1459, DOI 10.17487/RFC1459, May 1993,
293 |               <http://www.rfc-editor.org/info/rfc1459>.
294 | 
295 |    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
296 |               Requirement Levels", BCP 14, RFC 2119,
297 |               DOI 10.17487/RFC2119, March 1997,
298 |               <http://www.rfc-editor.org/info/rfc2119>.
299 | 
300 |    [RFC2812]  Kalt, C., "Internet Relay Chat: Client Protocol",
301 |               RFC 2812, DOI 10.17487/RFC2812, April 2000,
302 |               <http://www.rfc-editor.org/info/rfc2812>.
303 | 
304 |    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
305 |               Specifications: ABNF", STD 68, RFC 5234,
306 |               DOI 10.17487/RFC5234, January 2008,
307 |               <http://www.rfc-editor.org/info/rfc5234>.
308 | 
309 |    [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
310 |               DOI 10.17487/RFC5322, October 2008,
311 |               <http://www.rfc-editor.org/info/rfc5322>.
312 | 
313 | Appendix A.  Message List
314 | 
315 |    This section is not exhaustive, and only lists those CTCP messages
316 |    which are widely implemented across the IRC ecosystem.
317 | 
318 |    The reply and parameter lines below use a simplified syntax that
319 |    represents variables by surrounding them with angle brackets.
320 | 
321 | A.1.  ACTION
322 | 
323 |    Type:    Extended Formatting
324 |    Params:  ACTION <text>
325 | 
326 |    This extended formatting message shows that <text> should be
327 |    displayed as a third-person action or emote; in clients, it's
328 |    generally activated with the command "/me".
329 | 
330 |    If <text> is empty, clients SHOULD still include a single space after
331 |    "ACTION" (i.e. an empty params section) to help compatibility.
332 | 
333 | 
334 | 
335 | 
336 | Mikulenas & Oakley      Expires January 19, 2018                [Page 6]
337 | 
338 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
339 | 
340 | 
341 |    Clients SHOULD correctly parse incoming ACTION messages with or
342 |    without the params section.
343 | 
344 |    ACTION is universally implemented and very commonly used.  Clients
345 |    MUST implement this CTCP message to effectively use IRC.
346 | 
347 |    Examples:
348 | 
349 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION does it!\x01
350 | 
351 |      Formatted:  * dan does it!
352 | 
353 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION \x01
354 | 
355 |      Formatted:  * dan
356 | 
357 |      Raw:        :dan!user@host PRIVMSG #ircv3 :\x01ACTION\x01
358 | 
359 |      Formatted:  * dan
360 | 
361 | A.2.  CLIENTINFO
362 | 
363 |    Type:   Extended Query
364 |    Reply:  CLIENTINFO <tokens>
365 | 
366 |    This extended query returns a list of the CTCP messages that this
367 |    client supports and implements, delimited by a single ASCII space.
368 | 
369 |    CLIENTINFO is widely implemented.  Clients SHOULD implement this CTCP
370 |    message.
371 | 
372 |    Example:
373 | 
374 |      Query:     CLIENTINFO
375 |      Response:  CLIENTINFO ACTION DCC CLIENTINFO PING TIME VERSION
376 | 
377 | A.3.  DCC
378 | 
379 |    Type:    Extended Query
380 |    Params:  DCC <type> <argument> <host> <port>
381 | 
382 |    This extended query is used to setup and control connections that go
383 |    directly between clients, bypassing the IRC server.  This is
384 |    typically used for features that require a large amount of traffic
385 |    between clients or simply wish to bypass the server itself such as
386 |    file transfer and direct chat.
387 | 
388 | 
389 | 
390 | 
391 | 
392 | Mikulenas & Oakley      Expires January 19, 2018                [Page 7]
393 | 
394 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
395 | 
396 | 
397 |    The Direct Client-to-Client (DCC) Protocol requires its own
398 |    specification, and is not described in-depth here.
399 | 
400 |    DCC is widely implemented.  Clients MAY implement this CTCP message.
401 | 
402 | A.4.  FINGER
403 | 
404 |    Type:   Metadata Query
405 |    Reply:  FINGER <info>
406 | 
407 |    This metadata query returns miscellaneous info about the user,
408 |    typically the same information that's held in their realname field.
409 | 
410 |    However, some implementations return the client name and version
411 |    instead.
412 | 
413 |    FINGER is largely obsolete.  Clients MAY implement this CTCP message.
414 | 
415 |    Example:
416 | 
417 |      Query:     FINGER
418 |      Response:  FINGER WeeChat 1.8-dev
419 | 
420 | A.5.  PING
421 | 
422 |    Type:    Extended Query
423 |    Params:  PING <info>
424 | 
425 |    This extended query is used to confirm reachability with other
426 |    clients and to check latency.  When receiving a CTCP PING, the reply
427 |    MUST contain exactly the same parameters as the original query.
428 | 
429 |    PING is universally implemented.  Clients SHOULD implement this CTCP
430 |    message.
431 | 
432 |    Example:
433 | 
434 |      Query:     PING 1473523721 662865
435 |      Response:  PING 1473523721 662865
436 | 
437 |      Query:     PING foo bar baz
438 |      Response:  PING foo bar baz
439 | 
440 | A.6.  SOURCE
441 | 
442 |    Type:   Metadata Query
443 |    Reply:  SOURCE <info>
444 | 
445 | 
446 | 
447 | 
448 | Mikulenas & Oakley      Expires January 19, 2018                [Page 8]
449 | 
450 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
451 | 
452 | 
453 |    This metadata query is used to return the location of the source code
454 |    for the client.
455 | 
456 |    SOURCE is rarely implemented.  Clients MAY implement this CTCP
457 |    message.
458 | 
459 |    Example:
460 | 
461 |      Query:     SOURCE
462 |      Response:  SOURCE https://weechat.org/download
463 | 
464 | A.7.  TIME
465 | 
466 |    Type:    Extended Query
467 |    Params:  TIME <timestring>
468 | 
469 |    This extended query is used to return the client's local time in an
470 |    unspecified human-readable format.  In practice, both the format
471 |    output by ctime() and the format described in Section 3.3 of
472 |    [RFC5322] are common.  Earlier specifications recommended to prefix
473 |    the time string with a colon, but this is no longer recommended.
474 | 
475 |    New implementations MAY default to UTC time for privacy reasons.
476 | 
477 |    TIME is almost universally implemented.  Clients SHOULD implement
478 |    this CTCP message.
479 | 
480 |    Example:
481 | 
482 |      Query:     TIME
483 |      Response:  TIME Mon, 08 May 2017 09:15:29 GMT
484 | 
485 | A.8.  VERSION
486 | 
487 |    Type:   Metadata Query
488 |    Reply:  VERSION <verstring>
489 | 
490 |    This metadata query is used to return the name and version of the
491 |    client software in use.  There is no specified format for the version
492 |    string.
493 | 
494 |    Clients may allow users to customise the response value for this
495 |    query.
496 | 
497 |    VERSION is universally implemented.  Clients SHOULD implement this
498 |    CTCP message.
499 | 
500 |    Example:
501 | 
502 | 
503 | 
504 | Mikulenas & Oakley      Expires January 19, 2018                [Page 9]
505 | 
506 | Internet-Draft        IRC Client-to-Client Protocol            July 2017
507 | 
508 | 
509 |      Query:     VERSION
510 |      Response:  VERSION WeeChat 1.8-dev (git: v1.7-329-g22f2fd03a)
511 | 
512 | A.9.  USERINFO
513 | 
514 |    Type:   Metadata Query
515 |    Reply:  USERINFO <info>
516 | 
517 |    This metadata query returns miscellaneous info about the user,
518 |    typically the same information that's held in their realname field.
519 | 
520 |    However, some implementations return "<nickname> (<realname>)"
521 |    instead.
522 | 
523 |    USERINFO is largely obsolete.  Clients MAY implement this CTCP
524 |    message.
525 | 
526 |    Example:
527 | 
528 |      Query:     USERINFO
529 |      Response:  USERINFO fred (Fred Foobar)
530 | 
531 | Appendix B.  Change History [RFC Editor: Please remove this section]
532 | 
533 |    Changes from draft 0 (May 29, 2017)
534 | 
535 |    o  Added note about servers truncating CTCP messages (thanks Peter).
536 | 
537 |    o  Fixed misspellings and added note to TIME about previously-
538 |       recommended prefix (thanks Patrick).
539 | 
540 |    o  Mentioned how to parse/send empty ACTION messages (thanks dequis
541 |       and the crew).
542 | 
543 | Authors' Addresses
544 | 
545 |    Mantas Mikulenas
546 |    Independent
547 | 
548 |    Email: grawity@gmail.com
549 | 
550 | 
551 |    Daniel Oakley
552 |    ircdocs
553 | 
554 |    Email: daniel@danieloaks.net
555 | 
556 | 
557 | 
558 | 
559 | 
560 | Mikulenas & Oakley      Expires January 19, 2018               [Page 10]
561 | 


--------------------------------------------------------------------------------
/info/rfc2810.txt:
--------------------------------------------------------------------------------
  1 | 
  2 | 
  3 | 
  4 | 
  5 | 
  6 | 
  7 | Network Working Group                                           C. Kalt
  8 | Request for Comments: 2810                                   April 2000
  9 | Updates: 1459
 10 | Category: Informational
 11 | 
 12 | 
 13 |                    Internet Relay Chat: Architecture
 14 | 
 15 | Status of this Memo
 16 | 
 17 |    This memo provides information for the Internet community.  It does
 18 |    not specify an Internet standard of any kind.  Distribution of this
 19 |    memo is unlimited.
 20 | 
 21 | Copyright Notice
 22 | 
 23 |    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 24 | 
 25 | Abstract
 26 | 
 27 |    The IRC (Internet Relay Chat) protocol is for use with text based
 28 |    conferencing. It has been developed since 1989 when it was originally
 29 |    implemented as a mean for users on a BBS to chat amongst themselves.
 30 | 
 31 |    First formally documented in May 1993 by RFC 1459 [IRC], the protocol
 32 |    has kept evolving. This document is an update describing the
 33 |    architecture of the current IRC protocol and the role of its
 34 |    different components.  Other documents describe in detail the
 35 |    protocol used between the various components defined here.
 36 | 
 37 | Table of Contents
 38 | 
 39 |    1.  Introduction ...............................................   2
 40 |    2.  Components .................................................   2
 41 |       2.1  Servers ................................................   2
 42 |       2.2  Clients ................................................   3
 43 |          2.2.1  User Clients ......................................   3
 44 |          2.2.2  Service Clients ...................................   3
 45 |    3.  Architecture ...............................................   3
 46 |    4.  IRC Protocol Services ......................................   4
 47 |       4.1  Client Locator .........................................   4
 48 |       4.2  Message Relaying .......................................   4
 49 |       4.3  Channel Hosting And Management .........................   4
 50 |    5.  IRC Concepts ...............................................   4
 51 |       5.1  One-To-One Communication ...............................   5
 52 |       5.2  One-To-Many ............................................   5
 53 |          5.2.1  To A Channel ......................................   5
 54 |          5.2.2  To A Host/Server Mask .............................   6
 55 | 
 56 | 
 57 | 
 58 | Kalt                         Informational                      [Page 1]
 59 | 
 60 | RFC 2810           Internet Relay Chat: Architecture          April 2000
 61 | 
 62 | 
 63 |          5.2.3  To A List .........................................   6
 64 |       5.3  One-To-All .............................................   6
 65 |          5.3.1  Client-to-Client ..................................   6
 66 |          5.3.2  Client-to-Server ..................................   7
 67 |          5.3.3  Server-to-Server ..................................   7
 68 |    6.  Current Problems ...........................................   7
 69 |       6.1  Scalability ............................................   7
 70 |       6.2  Reliability ............................................   7
 71 |       6.3  Network Congestion .....................................   7
 72 |       6.4  Privacy ................................................   8
 73 |    7.  Security Considerations ....................................   8
 74 |    8.  Current Support And Availability ...........................   8
 75 |    9.  Acknowledgements ...........................................   8
 76 |    10.  References ................................................   8
 77 |    11.  Author's Address ..........................................   9
 78 |    12.  Full Copyright Statement ..................................  10
 79 | 
 80 | 1. Introduction
 81 | 
 82 |    The IRC (Internet Relay Chat) protocol has been designed over a
 83 |    number of years for use with text based conferencing.  This document
 84 |    describes its current architecture.
 85 | 
 86 |    The IRC Protocol is based on the client-server model, and is well
 87 |    suited to running on many machines in a distributed fashion.  A
 88 |    typical setup involves a single process (the server) forming a
 89 |    central point for clients (or other servers) to connect to,
 90 |    performing the required message delivery/multiplexing and other
 91 |    functions.
 92 | 
 93 |    This distributed model, which requires each server to have a copy
 94 |    of the global state information, is still the most flagrant problem
 95 |    of the protocol as it is a serious handicap, which limits the maximum
 96 |    size a network can reach.  If the existing networks have been able to
 97 |    keep growing at an incredible pace, we must thank hardware
 98 |    manufacturers for giving us ever more powerful systems.
 99 | 
100 | 2. Components
101 | 
102 |    The following paragraphs define the basic components of the IRC
103 |    protocol.
104 | 
105 | 2.1 Servers
106 | 
107 |    The server forms the backbone of IRC as it is the only component
108 |    of the protocol which is able to link all the other components
109 |    together: it provides a point to which clients may connect to talk to
110 | 
111 | 
112 | 
113 | 
114 | Kalt                         Informational                      [Page 2]
115 | 
116 | RFC 2810           Internet Relay Chat: Architecture          April 2000
117 | 
118 | 
119 |    each other [IRC-CLIENT], and a point for other servers to connect to
120 |    [IRC-SERVER].  The server is also responsible for providing the basic
121 |    services defined by the IRC protocol.
122 | 
123 | 2.2 Clients
124 | 
125 |    A client is anything connecting to a server that is not another
126 |    server.  There are two types of clients which both serve a different
127 |    purpose.
128 | 
129 | 2.2.1 User Clients
130 | 
131 |    User clients are generally programs providing a text based
132 |    interface that is used to communicate interactively via IRC.  This
133 |    particular type of clients is often referred as "users".
134 | 
135 | 2.2.2 Service Clients
136 | 
137 |    Unlike users, service clients are not intended to be used manually
138 |    nor for talking.  They have a more limited access to the chat
139 |    functions of the protocol, while optionally having access to more
140 |    private data from the servers.
141 | 
142 |    Services are typically automatons used to provide some kind of
143 |    service (not necessarily related to IRC itself) to users.  An example
144 |    is a service collecting statistics about the origin of users
145 |    connected on the IRC network.
146 | 
147 | 3. Architecture
148 | 
149 |    An IRC network is defined by a group of servers connected to each
150 |    other.  A single server forms the simplest IRC network.
151 | 
152 |    The only network configuration allowed for IRC servers is that of
153 |    a spanning tree where each server acts as a central node for the rest
154 |    of the network it sees.
155 | 
156 |                        1--\
157 |                            A        D---4
158 |                        2--/ \      /
159 |                              B----C
160 |                             /      \
161 |                            3        E
162 | 
163 |    Servers: A, B, C, D, E         Clients: 1, 2, 3, 4
164 | 
165 |                     [ Fig. 1. Sample small IRC network ]
166 | 
167 | 
168 | 
169 | 
170 | Kalt                         Informational                      [Page 3]
171 | 
172 | RFC 2810           Internet Relay Chat: Architecture          April 2000
173 | 
174 | 
175 |    The IRC protocol provides no mean for two clients to directly
176 |    communicate.  All communication between clients is relayed by the
177 |    server(s).
178 | 
179 | 4. IRC Protocol Services
180 | 
181 |    This section describes the services offered by the IRC protocol.  The
182 |    combination of these services allow real-time conferencing.
183 | 
184 | 4.1 Client Locator
185 | 
186 |    To be able to exchange messages, two clients must be able to locate
187 |    each other.
188 | 
189 |    Upon connecting to a server, a client registers using a label which
190 |    is then used by other servers and clients to know where the client is
191 |    located.  Servers are responsible for keeping track of all the labels
192 |    being used.
193 | 
194 | 4.2 Message Relaying
195 | 
196 |    The IRC protocol provides no mean for two clients to directly
197 |    communicate.  All communication between clients is relayed by the
198 |    server(s).
199 | 
200 | 4.3 Channel Hosting And Management
201 | 
202 |    A channel is a named group of one or more users which will all
203 |    receive messages addressed to that channel.  A channel is
204 |    characterized by its name and current members, it also has a set of
205 |    properties which can be manipulated by (some of) its members.
206 | 
207 |    Channels provide a mean for a message to be sent to several clients.
208 |    Servers host channels, providing the necessary message multiplexing.
209 |    Servers are also responsible for managing channels by keeping track
210 |    of the channel members.  The exact role of servers is defined in
211 |    "Internet Relay Chat: Channel Management" [IRC-CHAN].
212 | 
213 | 5. IRC Concepts
214 | 
215 |    This section is devoted to describing the actual concepts behind the
216 |    organization of the IRC protocol and how different classes of
217 |    messages are delivered.
218 | 
219 | 
220 | 
221 | 
222 | 
223 | 
224 | 
225 | 
226 | Kalt                         Informational                      [Page 4]
227 | 
228 | RFC 2810           Internet Relay Chat: Architecture          April 2000
229 | 
230 | 
231 | 5.1 One-To-One Communication
232 | 
233 |    Communication on a one-to-one basis is usually performed by clients,
234 |    since most server-server traffic is not a result of servers talking
235 |    only to each other.  To provide a means for clients to talk to each
236 |    other, it is REQUIRED that all servers be able to send a message in
237 |    exactly one direction along the spanning tree in order to reach any
238 |    client.  Thus the path of a message being delivered is the shortest
239 |    path between any two points on the spanning tree.
240 | 
241 |    The following examples all refer to Figure 1 above.
242 | 
243 |    Example 1: A message between clients 1 and 2 is only seen by server
244 |        A, which sends it straight to client 2.
245 | 
246 |    Example 2: A message between clients 1 and 3 is seen by servers A &
247 |        B, and client 3.  No other clients or servers are allowed see the
248 |        message.
249 | 
250 |    Example 3: A message between clients 2 and 4 is seen by servers A, B,
251 |        C & D and client 4 only.
252 | 
253 | 5.2 One-To-Many
254 | 
255 |    The main goal of IRC is to provide a forum which allows easy and
256 |    efficient conferencing (one to many conversations).  IRC offers
257 |    several means to achieve this, each serving its own purpose.
258 | 
259 | 5.2.1 To A Channel
260 | 
261 |    In IRC the channel has a role equivalent to that of the multicast
262 |    group; their existence is dynamic and the actual conversation carried
263 |    out on a channel MUST only be sent to servers which are supporting
264 |    users on a given channel.  Moreover, the message SHALL only be sent
265 |    once to every local link as each server is responsible to fan the
266 |    original message to ensure that it will reach all the recipients.
267 | 
268 |    The following examples all refer to Figure 2.
269 | 
270 |    Example 4: Any channel with 1 client in it. Messages to the channel
271 |        go to the server and then nowhere else.
272 | 
273 |    Example 5: 2 clients in a channel. All messages traverse a path as if
274 |        they were private messages between the two clients outside a
275 |        channel.
276 | 
277 | 
278 | 
279 | 
280 | 
281 | 
282 | Kalt                         Informational                      [Page 5]
283 | 
284 | RFC 2810           Internet Relay Chat: Architecture          April 2000
285 | 
286 | 
287 |    Example 6: Clients 1, 2 and 3 in a channel.  All messages to the
288 |        channel are sent to all clients and only those servers which must
289 |        be traversed by the message if it were a private message to a
290 |        single client.  If client 1 sends a message, it goes back to
291 |        client 2 and then via server B to client 3.
292 | 
293 | 5.2.2 To A Host/Server Mask
294 | 
295 |    To provide with some mechanism to send messages to a large body of
296 |    related users, host and server mask messages are available.  These
297 |    messages are sent to users whose host or server information match
298 |    that of the mask.  The messages are only sent to locations where
299 |    users are, in a fashion similar to that of channels.
300 | 
301 | 5.2.3 To A List
302 | 
303 |    The least efficient style of one-to-many conversation is through
304 |    clients talking to a 'list' of targets (client, channel, mask).  How
305 |    this is done is almost self explanatory: the client gives a list of
306 |    destinations to which the message is to be delivered and the server
307 |    breaks it up and dispatches a separate copy of the message to each
308 |    given destination.
309 | 
310 |    This is not as efficient as using a channel since the destination
311 |    list MAY be broken up and the dispatch sent without checking to make
312 |    sure duplicates aren't sent down each path.
313 | 
314 | 5.3 One-To-All
315 | 
316 |    The one-to-all type of message is better described as a broadcast
317 |    message, sent to all clients or servers or both.  On a large network
318 |    of users and servers, a single message can result in a lot of traffic
319 |    being sent over the network in an effort to reach all of the desired
320 |    destinations.
321 | 
322 |    For some class of messages, there is no option but to broadcast it to
323 |    all servers so that the state information held by each server is
324 |    consistent between servers.
325 | 
326 | 5.3.1 Client-to-Client
327 | 
328 |    There is no class of message which, from a single message, results in
329 |    a message being sent to every other client.
330 | 
331 | 
332 | 
333 | 
334 | 
335 | 
336 | 
337 | 
338 | Kalt                         Informational                      [Page 6]
339 | 
340 | RFC 2810           Internet Relay Chat: Architecture          April 2000
341 | 
342 | 
343 | 5.3.2 Client-to-Server
344 | 
345 |    Most of the commands which result in a change of state information
346 |    (such as channel membership, channel mode, user status, etc.) MUST be
347 |    sent to all servers by default, and this distribution SHALL NOT be
348 |    changed by the client.
349 | 
350 | 5.3.3 Server-to-Server
351 | 
352 |    While most messages between servers are distributed to all 'other'
353 |    servers, this is only required for any message that affects a user,
354 |    channel or server.  Since these are the basic items found in IRC,
355 |    nearly all messages originating from a server are broadcast to all
356 |    other connected servers.
357 | 
358 | 6. Current Problems
359 | 
360 |    There are a number of recognized problems with this protocol, this
361 |    section only addresses the problems related to the architecture of
362 |    the protocol.
363 | 
364 | 6.1 Scalability
365 | 
366 |    It is widely recognized that this protocol does not scale
367 |    sufficiently well when used in a large arena.  The main problem comes
368 |    from the requirement that all servers know about all other servers,
369 |    clients and channels and that information regarding them be updated
370 |    as soon as it changes.
371 | 
372 | 6.2 Reliability
373 | 
374 |    As the only network configuration allowed for IRC servers is that of
375 |    a spanning tree, each link between two servers is an obvious and
376 |    quite serious point of failure.  This particular issue is addressed
377 |    more in detail in "Internet Relay Chat: Server Protocol" [IRC-
378 |    SERVER].
379 | 
380 | 6.3 Network Congestion
381 | 
382 |    Another problem related to the scalability and reliability issues, as
383 |    well as the spanning tree architecture, is that the protocol and
384 |    architecture for IRC are extremely vulnerable to network congestions.
385 |    This problem is endemic, and should be solved for the next
386 |    generation: if congestion and high traffic volume cause a link
387 |    between two servers to fail, not only this failure generates more
388 |    network traffic, but the reconnection (eventually elsewhere) of two
389 |    servers also generates more traffic.
390 | 
391 | 
392 | 
393 | 
394 | Kalt                         Informational                      [Page 7]
395 | 
396 | RFC 2810           Internet Relay Chat: Architecture          April 2000
397 | 
398 | 
399 |    In an attempt to minimize the impact of these problems, it is
400 |    strongly RECOMMENDED that servers do not automatically try to
401 |    reconnect too fast, in order to avoid aggravating the situation.
402 | 
403 | 6.4 Privacy
404 | 
405 |    Besides not scaling well, the fact that servers need to know all
406 |    information about other entities, the issue of privacy is also a
407 |    concern. This is in particular true for channels, as the related
408 |    information is quite a lot more revealing than whether a user is
409 |    online or not.
410 | 
411 | 7. Security Considerations
412 | 
413 |    Asides from the privacy concerns mentioned in section 6.4 (Privacy),
414 |    security is believed to be irrelevant to this document.
415 | 
416 | 8. Current Support And Availability
417 | 
418 |         Mailing lists for IRC related discussion:
419 |           General discussion: ircd-users@irc.org
420 |           Protocol development: ircd-dev@irc.org
421 | 
422 |         Software implementations:
423 |           ftp://ftp.irc.org/irc/server
424 |           ftp://ftp.funet.fi/pub/unix/irc
425 |           ftp://coombs.anu.edu.au/pub/irc
426 | 
427 |         Newsgroup: alt.irc
428 | 
429 | 9. Acknowledgements
430 | 
431 |    Parts of this document were copied from the RFC 1459 [IRC] which
432 |    first formally documented the IRC Protocol.  It has also benefited
433 |    from many rounds of review and comments.  In particular, the
434 |    following people have made significant contributions to this
435 |    document:
436 | 
437 |    Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
438 |    Ruokonen, Magnus Tjernstrom, Stefan Zehl.
439 | 
440 | 
441 | 
442 | 
443 | 
444 | 
445 | 
446 | 
447 | 
448 | 
449 | 
450 | Kalt                         Informational                      [Page 8]
451 | 
452 | RFC 2810           Internet Relay Chat: Architecture          April 2000
453 | 
454 | 
455 | 10. References
456 | 
457 |    [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
458 |                 Requirement Levels", BCP 14, RFC 2119, March 1997.
459 | 
460 |    [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
461 |                 Protocol", RFC 1459, May 1993.
462 | 
463 |    [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
464 |                 2812, April 2000.
465 | 
466 |    [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
467 |                 2813, April 2000.
468 | 
469 |    [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
470 |                 2811, April 2000.
471 | 
472 | 11. Author's Address
473 | 
474 |    Christophe Kalt
475 |    99 Teaneck Rd, Apt #117
476 |    Ridgefield Park, NJ 07660
477 |    USA
478 | 
479 |    EMail: kalt@stealth.net
480 | 
481 | 
482 | 
483 | 
484 | 
485 | 
486 | 
487 | 
488 | 
489 | 
490 | 
491 | 
492 | 
493 | 
494 | 
495 | 
496 | 
497 | 
498 | 
499 | 
500 | 
501 | 
502 | 
503 | 
504 | 
505 | 
506 | Kalt                         Informational                      [Page 9]
507 | 
508 | RFC 2810           Internet Relay Chat: Architecture          April 2000
509 | 
510 | 
511 | 12.  Full Copyright Statement
512 | 
513 |    Copyright (C) The Internet Society (2000).  All Rights Reserved.
514 | 
515 |    This document and translations of it may be copied and furnished to
516 |    others, and derivative works that comment on or otherwise explain it
517 |    or assist in its implementation may be prepared, copied, published
518 |    and distributed, in whole or in part, without restriction of any
519 |    kind, provided that the above copyright notice and this paragraph are
520 |    included on all such copies and derivative works.  However, this
521 |    document itself may not be modified in any way, such as by removing
522 |    the copyright notice or references to the Internet Society or other
523 |    Internet organizations, except as needed for the purpose of
524 |    developing Internet standards in which case the procedures for
525 |    copyrights defined in the Internet Standards process must be
526 |    followed, or as required to translate it into languages other than
527 |    English.
528 | 
529 |    The limited permissions granted above are perpetual and will not be
530 |    revoked by the Internet Society or its successors or assigns.
531 | 
532 |    This document and the information contained herein is provided on an
533 |    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534 |    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535 |    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536 |    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537 |    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
538 | 
539 | Acknowledgement
540 | 
541 |    Funding for the RFC Editor function is currently provided by the
542 |    Internet Society.
543 | 
544 | 
545 | 
546 | 
547 | 
548 | 
549 | 
550 | 
551 | 
552 | 
553 | 
554 | 
555 | 
556 | 
557 | 
558 | 
559 | 
560 | 
561 | 
562 | Kalt                         Informational                     [Page 10]
563 | 
564 | 


--------------------------------------------------------------------------------