/[svn]/ircd-hybrid/doc/technical/draft-mitchell-irc-capabilities-01.txt
ViewVC logotype

Contents of /ircd-hybrid/doc/technical/draft-mitchell-irc-capabilities-01.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 502 - (show annotations)
Fri Mar 3 19:49:25 2006 UTC (15 years, 2 months ago) by michael
File MIME type: text/plain
File size: 43886 byte(s)
- Implemented CAP command handler based uppon ircu's m_cap()
- Added somewhat outdated draft-mitchell-irc-capabilities-01.txt until
  I get the latest version from kev.
- Added "multi-prefix" cap so clients supporting "multi-prefix"
  may recieve multi prefixed NAMES replies, e.g. @%+nick1 @+nick2 ..
- Fixed "make clean" for src/conf/

1
2 Network Working Group K. Mitchell
3 Internet-Draft P. Lorier
4 Expires: September 5, 2005 Undernet IRC Network
5 L. Hardy
6 ircd-ratbox
7 P. Kucharski
8 IRCnet
9 March 7, 2005
10
11 IRC Client Capabilities Extension
12 draft-mitchell-irc-capabilities-01
13
14 Status of this Memo
15
16 This document is an Internet-Draft and is subject to all provisions
17 of section 3 of RFC 3667. By submitting this Internet-Draft, each
18 author represents that any applicable patent or other IPR claims of
19 which he or she is aware have been or will be disclosed, and any of
20 which he or she become aware will be disclosed, in accordance with
21 RFC 3668.
22
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as
26 Internet-Drafts.
27
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
32
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
35
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
38
39 This Internet-Draft will expire on September 5, 2005.
40
41 Copyright Notice
42
43 Copyright (C) The Internet Society (2005).
44
45 Abstract
46
47 IRC (Internet Relay Chat) is a long-standing protocol for real-time
48 chatting. The basic client-server protocol is a very simple
49 text-based protocol with no explicit mechanism for introducing or
50
51
52 Mitchell, et al. Expires September 5, 2005 [Page 1]
53 Internet-Draft IRC CAP March 2005
54
55 negotiating backwards-incompatible extensions. This memo presents a
56 mechanism for negotiation of such extensions.
57
58 Requirements Language
59
60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
62 "OPTIONAL" in this document are to be interpreted as described in RFC
63 2119 [1].
64
65 Table of Contents
66
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
68
69 2. Problems to be Solved . . . . . . . . . . . . . . . . . . . . 4
70
71 3. The CAP Command . . . . . . . . . . . . . . . . . . . . . . . 5
72 3.1 CAP LS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
73 3.2 CAP LIST . . . . . . . . . . . . . . . . . . . . . . . . . 6
74 3.3 CAP REQ . . . . . . . . . . . . . . . . . . . . . . . . . 7
75 3.4 CAP ACK . . . . . . . . . . . . . . . . . . . . . . . . . 7
76 3.5 CAP NAK . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 3.6 CAP CLEAR . . . . . . . . . . . . . . . . . . . . . . . . 8
78 3.7 CAP END . . . . . . . . . . . . . . . . . . . . . . . . . 8
79
80 4. Capability Negotiation . . . . . . . . . . . . . . . . . . . . 10
81
82 5. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 11
83 5.1 Capability Modifiers . . . . . . . . . . . . . . . . . . . 11
84
85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
86
87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
88
89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
90
91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
92
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
94
95 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
96
97 B. ABNF Description of Capabilities . . . . . . . . . . . . . . . 19
98
99 C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 21
100
101 Intellectual Property and Copyright Statements . . . . . . . . 28
102
103
104 Mitchell, et al. Expires September 5, 2005 [Page 2]
105 Internet-Draft IRC CAP March 2005
106
107 1. Introduction
108
109 The IRC protocol, as originally documented by RFC 1459 [2] and
110 updated by RFC 2812 [3], is a simple, text-based conferencing
111 protocol, involving a number of users spread across a number of
112 interconnected servers. These users may chat with other individual
113 users, or may chat with groups of users on "channels"--what other
114 chat systems refer to as "rooms" or "chat rooms".
115
116 Over the years, various extensions to the basic IRC protocol have
117 been made by IRC server programmers. Often, these extensions are
118 intended to conserve bandwidth, close loopholes left by the original
119 protocol specification, or add features for users or for the server
120 administrators. Most of these changes are backwards-compatible with
121 the original protocol specification: A command may be added, a reply
122 may be extended to contain more parameters, etc. Recently, however,
123 there has been a desire to introduce changes that would not be
124 backwards-compatible with existing IRC clients. Ideally, these
125 protocol changes would only be used with clients and servers that can
126 understand the revised protocol. Unfortunately, the IRC protocol
127 does not provide any form of extension or protocol negotiation,
128 making it impossible to determine support for such extensions.
129
130 This memo introduces a standardized mechanism for negotiation of
131 protocol extensions, known as *capabilities*, that will be
132 backwards-compatible with all existing IRC clients and servers. Any
133 server not implementing this extension will still interoperate with
134 clients that do implement it; similarly, clients that do not
135 implement the capabilities extension may successfully communicate
136 with a server that does implement the extension.
137
138
139
140
141
142
143
144
145
146
147
148 Mitchell, et al. Expires September 5, 2005 [Page 3]
149 Internet-Draft IRC CAP March 2005
150
151 2. Problems to be Solved
152
153 The IRC protocol is not a lockstep protocol. This means that a
154 client may issue additional commands before the server has finished
155 responding to the first one. Additionally, unlike other protocols,
156 the server does not necessarily issue a banner response upon initial
157 connection. This, combined with the fact that some servers do not
158 complain about unknown commands prior to completion of the client
159 registration phase, means that a client cannot know for certain
160 whether a server implements the extension. If a client had to wait
161 for a banner message, it would fail to interoperate with a server not
162 implementing the capabilities extension. If the client must issue a
163 command and then wait for a response, a similar problem results. As
164 some potential protocol extensions must be set up prior to completion
165 of the client registration phase, there is no reliable way a server
166 may indicate implementation of the capabilities extension to a
167 client.
168
169 The solution to these problems turns out to be to extend the client
170 registration procedure. The client sends a request to begin
171 capability negotiation, as well as the other information necessary
172 for client registration (user name, nick name, optional password,
173 etc.). If the server understands the capabilities extension, it will
174 suspend completion of the registration phase until the negotiation is
175 complete; negotiation may then proceed in a lockstep fashion. If the
176 server does not understand capabilities, then the registration will
177 complete immediately, and the client will receive the 001 numeric.
178 This will signal to the client that the server does not implement the
179 capabilities extension.
180
181
182
183
184
185
186
187
188
189
190
191 Mitchell, et al. Expires September 5, 2005 [Page 4]
192 Internet-Draft IRC CAP March 2005
193
194 3. The CAP Command
195
196 The capabilities extension is implemented by addition of one command
197 with several subcommands. The command added is *CAP*. CAP takes a
198 single, required subcommand, optionally followed by a single
199 parameter consisting of a space-separated list of capabilities. Each
200 capability within the list MAY be preceded by a capability modifier.
201 (Section 5.1)
202
203 The subcommands defined for CAP are:
204
205 1. LS (Section 3.1)
206 2. LIST (Section 3.2)
207 3. REQ (Section 3.3)
208 4. ACK (Section 3.4)
209 5. NAK (Section 3.5)
210 6. CLEAR (Section 3.6)
211 7. END (Section 3.7)
212
213 The LS (Section 3.1), LIST (Section 3.2), REQ (Section 3.3), ACK
214 (Section 3.4), and NAK (Section 3.5) subcommands may be followed by a
215 single parameter consisting of a space-separated list of capability
216 names. If more than one capability is named, this argument MUST be
217 preceded by the IRC protocol colon (':') sentinel to signal that the
218 remainder of the line is a single argument.
219
220 If a client sends a subcommand not listed above or issues an invalid
221 command, the server SHOULD reply with the ERR_INVALIDCAPCMD numeric
222 response, 410. The first parameter after the client nickname SHALL
223 be the subcommand the client sent; the second parameter SHOULD be a
224 textual description of the error.
225
226 In ABNF [4] notation:
227
228 capcmd = [ ":" servername SP ] "CAP" SP subcmd
229
230 subcmd = lscmd / listcmd / reqcmd / ackcmd /
231 nakcmd / clearcmd / endcmd
232
233 capcmderr = ":" servername SP "410" SP nick SP badcmd
234 SP ":Invalid CAP subcommand"
235 ; badcmd is the unrecognized subcommand
236
237 caplist = [ ":" ] *( capmod ) capab
238 caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab )
239
240 where SP is as designated in Appendix A of RFC 2234 [4], and
241 servername and nick are as designated in section 2.3.1 of RFC 1459
242
243
244 Mitchell, et al. Expires September 5, 2005 [Page 5]
245 Internet-Draft IRC CAP March 2005
246
247 [2].
248
249 The discussion in the following sections applies only to clients and
250 servers implementing the capabilities extension. Servers (and
251 clients) not implementing the capabilities extension are exempted
252 from the requirements of this section.
253
254 3.1 CAP LS
255
256 The LS subcommand is used to list the capabilities supported by the
257 server. The client SHALL send an LS subcommand with no arguments to
258 solicit a list of supported capabilities from the server. Servers
259 MUST respond to such LS subcommands with one or more LS subcommands
260 containing the list of recognized capabilities. All but the last
261 subcommand MUST have a parameter containing only an asterisk ('*')
262 preceding the capability list.
263
264 If a client issues an LS subcommand during the client registration
265 phase, client registration MUST be suspended until an END (Section
266 3.7) subcommand is received.
267
268 ABNF [4] description of the LS subcommand:
269
270 lscmd = "LS"
271 lscmd =/ "LS" SP [ "*" SP ] caplist
272
273 3.2 CAP LIST
274
275 The LIST subcommand is provided to permit the client to request a
276 list of the capabilities currently active for the connection. It is
277 similar to the LS (Section 3.1) subcommand--if a client issues a LIST
278 subcommand with no arguments, the server MUST respond with a sequence
279 of LIST subcommands, all but the last of which MUST have a single
280 parameter consisting solely of an asterisk ('*') preceding the list
281 of capabilities. If no capabilities have been enabled, the server
282 MUST send a LIST command with an empty capability list; the parameter
283 MUST NOT be omitted. The active capabilities MAY be listed in any
284 order.
285
286 ABNF [4] description of the LIST subcommand:
287
288 listcmd = "LIST"
289 listcmd =/ "LIST" SP ":"
290 listcmd =/ "LIST" SP [ "*" SP ] caplist
291
292
293
294 Mitchell, et al. Expires September 5, 2005 [Page 6]
295 Internet-Draft IRC CAP March 2005
296
297 3.3 CAP REQ
298
299 The REQ subcommand is sent by the client to request that a capability
300 or set of capabilities be enabled or disabled. Its sole parameter
301 MUST be a space-separated list of capabilities. Each capability name
302 MAY be preceded by a dash ('-') to indicate that the capability
303 should be disabled. Additionally, receipt of this subcommand during
304 the client registration MUST suspend client registration until an END
305 (Section 3.7) subcommand is received.
306
307 Servers MUST respond to a REQ command with either the ACK (Section
308 3.4) or NAK (Section 3.5) subcommands to indicate acceptance or
309 rejection of the capability set requested by the client. A server
310 MUST accept the entire capability set or reject it whole; servers
311 MUST NOT accept some capabilities in the set while rejecting others.
312 If a client requests that a "sticky" capability be disabled, the
313 server MUST reject the capability set.
314
315 ABNF [4] description of the REQ subcommand:
316
317 reqcmd = "REQ" SP caplist
318
319 3.4 CAP ACK
320
321 The ACK subcommand has three uses. It is used by the server to
322 acknowledge a REQ (Section 3.3) subcommand; by the server to
323 acknowledge a CLEAR (Section 3.6) subcommand and list the removed
324 capabilities; and by the client to acknowledge certain capabilities
325 designated as requiring acknowledgment. If more than one ACK is
326 required due to the IRC line length limitation of 512 characters, all
327 but the last SHALL contain a parameter consisting of a single
328 asterisk ('*') immediately preceding the list of capabilities, as for
329 LS (Section 3.1) and LIST (Section 3.2).
330
331 If an ACK reply originating from the server is spread across multiple
332 lines, a client MUST NOT change capabilities until the last ACK of
333 the set is received. Equally, a server MUST NOT change the
334 capabilities of the client until the last ACK of the set has been
335 sent.
336
337 In the first usage, acknowledging a REQ (Section 3.3) subcommand, the
338 ACK subcommand has a single parameter consisting of a space separated
339 list of capability names, which may optionally be preceded with one
340 or more modifiers (Section 5.1).
341
342 The second usage, acknowledging a CLEAR (Section 3.6) subcommand, is
343 similar to the first usage. When a CLEAR (Section 3.6) subcommand is
344
345
346 Mitchell, et al. Expires September 5, 2005 [Page 7]
347 Internet-Draft IRC CAP March 2005
348
349 issued, all non-"sticky" capabilities are disabled, and a set of ACK
350 subcommands will be generated by the server with the disable modifier
351 preceding each capability.
352
353 The third usage is when, in the preceding two cases, some capability
354 names have been preceded with the ack modifier. ACK in this case is
355 used to fully enable or disable the capability. Clients MUST NOT
356 issue an ACK subcommand for any capability not marked with the ack
357 modifier in a server-generated ACK subcommand.
358
359 ABNF [4] description of the ACK subcommand:
360
361 ackcmd = "ACK" SP [ "*" SP ] caplist
362
363 3.5 CAP NAK
364
365 The NAK subcommand MUST be sent by the server in response to a REQ
366 (Section 3.3) subcommand when any capability change requested cannot
367 be performed for any reason. The server MUST NOT make any change to
368 the set of capabilities for the client if it responds with a NAK
369 subcommand. The argument of the NAK subcommand MUST consist of at
370 least the first one hundred characters of the capability list in the
371 REQ (Section 3.3) subcommand which triggered the NAK.
372
373 ABNF [4] description of the NAK subcommand:
374
375 nakcmd = "NAK" SP ":" acklist
376 ; acklist is at least 100 characters of the
377 ; capability list from the REQ
378
379 3.6 CAP CLEAR
380
381 The CLEAR subcommand requests that the server clear the capability
382 set for the client. The server MUST respond with a set of ACK
383 (Section 3.4) subcommands indicating the capabilities being
384 deactivated.
385
386 ABNF [4] description of the CLEAR subcommand:
387
388 clearcmd = "CLEAR"
389
390 3.7 CAP END
391
392 The END subcommand signals to the server that capability negotiation
393 is complete and requests that the server continue with client
394
395
396 Mitchell, et al. Expires September 5, 2005 [Page 8]
397 Internet-Draft IRC CAP March 2005
398
399 registration. If the client is already registered, this command MUST
400 be ignored by the server.
401
402 Clients that support capabilities but do not wish to enter
403 negotiation SHOULD send CAP END upon connection to the server.
404
405 ABNF [4] description of the END subcommand:
406
407 endcmd = "END"
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429 Mitchell, et al. Expires September 5, 2005 [Page 9]
430 Internet-Draft IRC CAP March 2005
431
432 4. Capability Negotiation
433
434 Clients implementing this extension SHOULD take one of the following
435 three actions upon initial connection to a server:
436
437 o Issue an LS (Section 3.1) subcommand (with an empty capability
438 list) to solicit a list of supported capabilities from the server;
439
440 o Issue the REQ (Section 3.3) subcommand to request a particular set
441 of capabilities without knowing what capabilities the server
442 supports or if it supports the capabilities extension; or
443
444 o Issue the END (Section 3.7) subcommand to signal implementation of
445 the capabilities extension without entering into capability
446 negotiation.
447
448 Although a client is permitted to not issue any CAP commands upon
449 connection, this is NOT RECOMMENDED. Servers MAY assume a client
450 does not implement the capabilities extension if it does not issue
451 any CAP commands upon initial connection.
452
453 Clients SHOULD follow CAP commands issued upon connection with the
454 standard IRC client registration commands without waiting for any
455 responses from the server. See RFC 1459 [2] for more details about
456 the client registration procedure.
457
458 If a client issues the LS (Section 3.1) or REQ (Section 3.3)
459 subcommands during the client registration procedure, a server
460 implementing the capabilities extension MUST NOT complete the client
461 registration until the client issues the END (Section 3.7)
462 subcommand. A client that sees a RPL_WELCOME (001) numeric response
463 before it sends CAP END (Section 3.7) SHOULD assume that the server
464 does not support the capabilities extension.
465
466 Once the client is registered, CAP commands SHALL have no effect on
467 other connection operations, except that a client MAY change the
468 capabilities it has set. In particular, CAP commands and their
469 responses MAY be interspersed with other protocol messages. The END
470 (Section 3.7) subcommand SHALL have no effect once client
471 registration has been completed.
472
473
474
475
476
477
478 Mitchell, et al. Expires September 5, 2005 [Page 10]
479 Internet-Draft IRC CAP March 2005
480
481 5. Capabilities
482
483 Capabilities are designated by a name composed of one or more
484 elements. Name elements are not case-sensitive. They must begin
485 with a letter and may contain any number of letters, numbers, and the
486 dash character ('-'). Names containing more than one name element
487 MUST also contain a period character ('.') in the first name element.
488 Name elements are separated from each other via the slash character
489 ('/').
490
491 There are two capability name spaces:
492
493 Network Specific: Names whose first element contains a period
494 character ('.') designate a delegated capability name space. The
495 first element MUST be a valid, existing DNS domain name. These
496 names MUST contain at least two elements.
497
498 Standardized: All other names MUST correspond to capabilities
499 documented by an RFC. Further, these names MUST contain only one
500 element.
501
502 These rules are summarized by the following ABNF [4] representation:
503
504 elem = ALPHA *( ALPHA / DIGIT / "-" )
505
506 netname = elem 1*( "." elem )
507
508 netDeleg = netname 1*( "/" elem )
509
510 standardized = elem
511
512 capab = netDeleg / standardized
513
514 where ALPHA and DIGIT are as designated in Appendix A of RFC 2234
515 [4].
516
517 5.1 Capability Modifiers
518
519 There are various capability modifiers available. If a capability
520 modifier is to be used, it MUST directly precede the capability name.
521 The following are the modifiers defined for capabilities. Certain
522 modifiers MAY be combined.
523
524 The disable modifier is used by both the server and the client to
525 indicate that a capability should be disabled. The disable modifier
526 is defined as the dash character ('-'). A client MUST only use the
527 disable modifier in the REQ (Section 3.3) and ACK (Section 3.4)
528 subcommands. A server MUST use the disable modifier in the ACK
529
530
531 Mitchell, et al. Expires September 5, 2005 [Page 11]
532 Internet-Draft IRC CAP March 2005
533
534 (Section 3.4) subcommand when disabling a capability, or in
535 conjunction with a ack modifier in the LIST (Section 3.2) subcommand.
536 The server MUST NOT use the disable modifier in any other command
537 response.
538
539 The sticky modifier is used by the server to indicate a capability
540 that, once enabled, cannot be disabled. The sticky modifier is
541 defined as the equals character ('='). A client MUST NOT use the
542 sticky modifier. A server MUST only use the sticky modifier in the
543 ACK (Section 3.4), LIST (Section 3.2) and LS (Section 3.1)
544 subcommands and MUST use the modifier for all such capabilities.
545
546 The ack modifier is used by the server to indicate that the client
547 must issue an ACK (Section 3.4) subcommand to fully enable or disable
548 the capability. The ack modifier is defined as the tilde character
549 ('~'). The ack modifier indicates that traffic originating from the
550 server SHALL make use of the capability, but the server SHALL NOT
551 expect traffic originating from the client to make use of the
552 capability. When combined with the disable modifier, it indicates
553 traffic originating from the server SHALL NOT make use of the
554 capability, but the server expects traffic originating from the
555 client SHALL make use of the capability. The ack modifier MAY be
556 combined with the sticky modifier.
557
558 A server MUST use the ack modifier in the ACK (Section 3.4) and LIST
559 (Section 3.2) subcommands to indicate capabilities that require an
560 ACK (Section 3.4) subcommand from the client to be fully enabled or
561 disabled. Servers MUST also use the ack modifier in the response to
562 an LS (Section 3.1) subcommand to indicate capabilities which will
563 require ACK (Section 3.4) subcommands from the client. Clients MUST
564 NOT use the ack modifier, but SHOULD issue the ACK (Section 3.4)
565 subcommand as soon as possible after receiving an ACK (Section 3.4)
566 or REQ (Section 3.3) subcommand from the server that contains a
567 capability marked with the ack modifier.
568
569 In ABNF [4] notation:
570
571 dismod = "-"
572 stickymod = "="
573 ackmod = "~"
574
575 capmod = dismod / stickymod / ackmod
576
577
578
579
580
581 Mitchell, et al. Expires September 5, 2005 [Page 12]
582 Internet-Draft IRC CAP March 2005
583
584 6. IANA Considerations
585
586 The standardized capability name space shall be managed by IANA in
587 accordance with the description of capability names in Section 5. In
588 particular, any name not containing the period character ('.') must
589 be specified by an RFC.
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613 Mitchell, et al. Expires September 5, 2005 [Page 13]
614 Internet-Draft IRC CAP March 2005
615
616 7. Security Considerations
617
618 Capabilities are an extension to a preexisting, insecure chat
619 protocol. This extension does not add and does not purport to add
620 any security to the IRC protocol. Capability negotiation occurs
621 after client registration has already begun. Moreover, no mechanism
622 is defined that allows parameters to be passed for specific
623 capabilities. Although such a mechanism could be added,
624 cryptographic security systems frequently require several exchanges
625 to establish a secure context, particularly if authentication must
626 also be negotiated. Thus, the capabilities extension is unsuited to
627 the implementation of those protocols, and other mechanisms, such as
628 SSL-encapsulated IRC, should be used.
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648 Mitchell, et al. Expires September 5, 2005 [Page 14]
649 Internet-Draft IRC CAP March 2005
650
651 8. Acknowledgments
652
653 The authors wish to gratefully acknowledge the participation of Aaron
654 Wiebe and the members of the proto-desc@dal.net email list in the
655 design of this protocol extension.
656
657 9 References
658
659 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
660 Levels", BCP 14, RFC 2119, March 1997.
661
662 [2] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC
663 1459, May 1993.
664
665 [3] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812,
666 April 2000.
667
668 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
669 Specifications: ABNF", RFC 2234, November 1997.
670
671 [5] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
672 February 2004.
673
674 Authors' Addresses
675
676 Kevin L. Mitchell
677 Undernet IRC Network
678 38 Eighth St., Apt. 7
679 Cambridge, Massachusetts 02141
680 US
681
682 Phone: +1-617-230-1021
683 EMail: klmitch@mit.edu
684 URI: http://www.mit.edu/~klmitch/
685
686 Perry Lorier
687 Undernet IRC Network
688 3 Liston Cres
689 Hamilton, Waikato 2001
690 NZ
691
692 Phone: +64-7-859-1109
693 EMail: isomer@undernet.org
694
695
696
697 Mitchell, et al. Expires September 5, 2005 [Page 15]
698 Internet-Draft IRC CAP March 2005
699
700 Lee Hardy
701 ircd-ratbox Development Team
702
703 EMail: lee@leeh.co.uk
704 URI: http://www.leeh.co.uk
705
706 Piotr Kucharski
707 IRCnet
708
709 EMail: Beeth@irc.pl
710 URI: http://42.pl/
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731 Mitchell, et al. Expires September 5, 2005 [Page 16]
732 Internet-Draft IRC CAP March 2005
733
734 Appendix A. Examples
735
736 In the following examples, lines preceded by "CLIENT:" indicate
737 protocol messages sent by the client, and lines preceded by "SERVER:"
738 indicate protocol messages sent by the server. For clarity, the
739 origin field for server-originated protocol messages has been
740 omitted. This field would consist of a colon (':') followed by the
741 full server name, and would be the first field in the command.
742
743 A client communicating with a server not supporting CAP.
744
745 CLIENT: CAP LS
746 CLIENT: NICK nickname
747 CLIENT: USER username ignored ignored :real name
748 SERVER: 001 [...]
749
750 A client which does not wish to enter capability negotiation.
751
752 CLIENT: CAP END
753 CLIENT: NICK nickname
754 CLIENT: USER username ignored ignored :real name
755 SERVER: 001 [...]
756
757 A client entering into capability negotiation during registration,
758 and requesting a set of capabilities that the server does not
759 support.
760
761 CLIENT: CAP LS
762 CLIENT: NICK nickname
763 CLIENT: USER username ignored ignored :real name
764 SERVER: CAP LS * :A B C D E F G H
765 SERVER: CAP LS :I J
766 CLIENT: CAP REQ :A B C D E F
767 SERVER: CAP NAK :A B C D E F
768 CLIENT: CAP REQ :A C E F
769 SERVER: CAP ACK :A C E F
770 CLIENT: CAP REQ :B
771 SERVER: CAP ACK :B
772 CLIENT: CAP REQ :D
773 SERVER: CAP NAK :D
774 CLIENT: CAP END
775 SERVER: 001 [...]
776
777
778
779
780
781 Mitchell, et al. Expires September 5, 2005 [Page 17]
782 Internet-Draft IRC CAP March 2005
783
784 A client requesting a capability that requires an ACK (Section 3.4)
785 subcommand from the client to be enabled.
786
787 CLIENT: CAP LS
788 SERVER: CAP LS :~I ~J K
789 CLIENT: CAP REQ :I J K
790 SERVER: CAP ACK :~I ~J K
791 CLIENT: CAP ACK :I J
792
793 A client requesting a capability that requires an ACK (Section 3.4)
794 subcommand from the client to be enabled and disabled, using the LIST
795 (Section 3.2) subcommand in between.
796
797 CLIENT: CAP LS
798 SERVER: CAP LS :~A ~B
799 CLIENT: CAP REQ :A B
800 SERVER: CAP ACK :~A ~B
801 CLIENT: CAP LIST
802 SERVER: CAP LIST :~A ~B
803 CLIENT: CAP ACK :A B
804 CLIENT: CAP LIST
805 SERVER: CAP LIST :A B
806 CLIENT: CAP REQ :-B
807 SERVER: CAP ACK :-~B
808 CLIENT: CAP LIST
809 SERVER: CAP LIST :A -~B
810 CLIENT: CAP ACK :-B
811 CLIENT: CAP LIST
812 SERVER: CAP LIST :A
813
814 A client requesting a capability that is sticky.
815
816 CLIENT: CAP LS
817 SERVER: CAP LS :=I J
818 CLIENT: CAP REQ :I J
819 SERVER: CAP ACK :=I J
820
821 A client requesting a capability be disabled.
822
823 CLIENT: CAP LIST
824 SERVER: CAP LIST :=A B C D
825 CLIENT: CAP REQ :-B -C
826 SERVER: CAP ACK :-B -C
827
828
829
830
831 Mitchell, et al. Expires September 5, 2005 [Page 18]
832 Internet-Draft IRC CAP March 2005
833
834 Appendix B. ABNF Description of Capabilities
835
836 This section summarizes the ABNF [4] description of the capabilities
837 extension.
838
839 capcmd = [ ":" servername SP ] "CAP" SP subcmd
840
841 subcmd = lscmd / listcmd / reqcmd / ackcmd /
842 nakcmd / clearcmd / endcmd
843
844 capcmderr = ":" servername SP "410" SP nick SP badcmd
845 SP ":Invalid CAP subcommand"
846 ; badcmd is the unrecognized subcommand
847
848 caplist = [ ":" ] *( capmod ) capab
849 caplist =/ ":" *( capmod ) capab 1*( SP *( capmod ) capab )
850
851 lscmd = "LS"
852 lscmd =/ "LS" SP [ "*" SP ] caplist
853
854 listcmd = "LIST"
855 listcmd =/ "LIST" SP ":"
856 listcmd =/ "LIST" SP [ "*" SP ] caplist
857
858 reqcmd = "REQ" SP caplist
859
860 ackcmd = "ACK" SP [ "*" SP ] caplist
861
862 nakcmd = "NAK" SP ":" acklist
863 ; acklist is at least 100 characters of the
864 ; capability list from the REQ
865
866 clearcmd = "CLEAR"
867
868 endcmd = "END"
869
870 elem = ALPHA *( ALPHA / DIGIT / "-" )
871
872 netname = elem 1*( "." elem )
873
874 netDeleg = netname 1*( "/" elem )
875
876 standardized = elem
877
878 capab = netDeleg / standardized
879
880 dismod = "-"
881 stickymod = "="
882
883
884 Mitchell, et al. Expires September 5, 2005 [Page 19]
885 Internet-Draft IRC CAP March 2005
886
887 ackmod = "~"
888
889 capmod = dismod / stickymod / ackmod
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914 Mitchell, et al. Expires September 5, 2005 [Page 20]
915 Internet-Draft IRC CAP March 2005
916
917 Appendix C. ChangeLog
918
919 Note to RFC Editor: This section may be removed on publication as an
920 RFC.
921
922 Here is a log of changes to this document:
923
924 2004-12-15 KLM Initial draft written.
925
926 2004-12-16 KLM
927
928 * Added description of the argument to some CAP commands in
929 Section 3.
930
931 * Clarified that requirements of Section 3 only apply to clients
932 and servers implementing capabilities.
933
934 * Substitution of "performed" for "done" in Section 3.5
935
936 * Added LIST (Section 3.2) subcommand to provide a mechanism to
937 query active capabilities.
938
939 * Added reference to RFC 2812 [3].
940
941 * Moved Examples (Appendix A) section into the back matter.
942
943 * Corrected Perry Lorier's email address.
944
945 * Added this ChangeLog section.
946
947 * Corrected typo in Section 3.7: "sent" for "send".
948
949 * Added <vspace> elements to enhance readability.
950
951 * Changed to non-compact form.
952
953 * Changed anchor for Section 5 to "capabilities" from "caps" to
954 reduce possible confusion.
955
956 * Revise last sentence of first paragraph of Section 2 to remove
957 redundancy.
958
959 * Revise last sentence of second paragraph of Section 2
960
961 * Added email addresses for Lee H and Beeth; updated contact
962 information for Isomer.
963
964
965
966 Mitchell, et al. Expires September 5, 2005 [Page 21]
967 Internet-Draft IRC CAP March 2005
968
969 2004-12-17 KLM
970
971 * Augmented description of CAP command and subcommands with ABNF
972 description.
973
974 * Revised Section 5 to remove "net." name space and replace it
975 with a delegated name space beginning with a DNS domain name
976 (suggested by Isomer).
977
978 * Augmented ABNF description of capability names.
979
980 * Revised Section 6 to reflect change in capability name space.
981
982 * Added Appendix B to bring together the entire ABNF description
983 of capabilities.
984
985 2004-12-18 KLM
986
987 * Added explanation of what should happen if an unrecognized
988 subcommand is given.
989
990 * Clarified what to do if a client sends a subcommand that
991 shouldn't come from a client.
992
993 * Add references to LIST (Section 3.2) to LSL and Section 3.1.
994
995 * Section 3.3 omitted the caplist argument for the REQ command;
996 corrected.
997
998 * Relax the prohibition against a client acknowledging a
999 capability that doesn't modify the protocol stream in Section
1000 3.4
1001
1002 * Relax the requirement for a client that understands
1003 capabilities to send CAP END in Section 3.7
1004
1005 2004-12-19 KLM
1006
1007 * Converted a number of common xrefs into internal entities to
1008 simplify the text.
1009
1010 * Inserted some white space to make the <front> section a bit
1011 more readable.
1012
1013 * Added the keyword "Protocol".
1014
1015
1016 Mitchell, et al. Expires September 5, 2005 [Page 22]
1017 Internet-Draft IRC CAP March 2005
1018
1019 * Added the term "NOT RECOMMENDED" to the note on "Requirements
1020 Language".
1021
1022 * Moved LIST (Section 3.2) up in the list of CAP subcommands.
1023
1024 * Minor formatting change to the ABNF representation of subcmd.
1025
1026 * Capitalized "MAY" in "empty" subcommand.
1027
1028 * Added text about capability list order and what to do if no
1029 capabilities are implemented to "empty" subcommand.
1030
1031 * Mention LIST (Section 3.2) also in LSL when talking about
1032 sending more than one LSL subcommand.
1033
1034 * Clarify language in Section 3.1 a little bit.
1035
1036 * Substitute "set of capabilities" for "list of capabilities" in
1037 Section 3.3.
1038
1039 * Fix minor typo in preamble to ABNF description of NAK (Section
1040 3.5) subcommand: substitution of "ACK" for "NAK".
1041
1042 * Add note about servers ignoring END (Section 3.7) after client
1043 registration.
1044
1045 * Fix minor typo in preamble to ABNF description of LIST (Section
1046 3.2) subcommand: substitution of "END" for "LIST".
1047
1048 * Added Section 4 discussing capability negotiation.
1049
1050 * Add ".xml" extension to include files in references section.
1051
1052 * Simplification of preamble of first example (Appendix A).
1053
1054 * Add 'type="ABNF"' to <artwork> sections so that they can be
1055 extracted and used to create the abnf.xml now included in
1056 Appendix B.
1057
1058 * It's now RFC 3667 [5], not RFC 2026...
1059
1060 2004-12-27 KLM
1061
1062 * Minor wording changes to second paragraph of Section 1
1063
1064 * Minor wording change to first paragraph of Section 2
1065
1066
1067 Mitchell, et al. Expires September 5, 2005 [Page 23]
1068 Internet-Draft IRC CAP March 2005
1069
1070 * Minor wording changes to first paragraph of Section 3; remove
1071 redundant note about the IRC colon sentinel.
1072
1073 * Change a "must" to a "MUST" in Section 3.4; note that
1074 capability list may be truncated if it would otherwise exceed
1075 the 512 character limit.
1076
1077 * In Section 3.5, note that capability list may be truncated if
1078 it would otherwise exceed the 512 character limit.
1079
1080 * Remove redundant line about ignoring END (Section 3.7) commands
1081 after registration.
1082
1083 * Correct spelling of "acknowledgments".
1084
1085 * Empty <organization> elements for Lee H and Beeth; put Beeth's
1086 real name, Piotr Kucharski, in the right place.
1087
1088 * Switch to using a new preprocessor that consolidates all the
1089 ABNF artwork and inserts it with the processing instruction
1090 <?art type="foo"?>.
1091
1092 * Remove deliberate page break after <abstract> section.
1093
1094 * Reorder authors section to consolidate <organization> elements
1095 for everyone.
1096
1097 * Drop abbreviation for Undernet.
1098
1099 * Expand Section 7 a bit to try to explain why capabilities are
1100 not suited to securing IRC.
1101
1102 2005-01-04 KLM
1103
1104 * Add Lee Hardy's information to the list of authors.
1105
1106 2005-01-05 KLM
1107
1108 * Replace UNKNOWNCAPCMD with INVALIDCAPCMD.
1109
1110 * Begin rewriting LS (Section 3.1) documentation
1111
1112
1113
1114
1115 Mitchell, et al. Expires September 5, 2005 [Page 24]
1116 Internet-Draft IRC CAP March 2005
1117
1118 2005-01-19 KLM
1119
1120 * Redesign the protocol substantially to simplify it.
1121
1122 2005-01-20 KLM
1123
1124 * Update Piotr's contact information.
1125
1126 * Drop the "x-" namespace...
1127
1128 2005-01-20 LH
1129
1130 * Some servers do issue banner responses, now.
1131
1132 * The CAP subcommand is now a requirement.
1133
1134 * Minor grammatical fix-up in documentation of REQ (Section 3.3)
1135 ("acceptance of or rejection of"--strike first "of").
1136
1137 * Clarify that sticky capabilities cause a REQ (Section 3.3) to
1138 be NAK (Section 3.5)ed.
1139
1140 * Mark the third case of an ACK (Section 3.4) with an explicit
1141 indicator that it's the third case...
1142
1143 * Strike redundant mention of not suspending client registration
1144 in documentation for END (Section 3.7).
1145
1146 2005-01-21 LH
1147
1148 * Move all references on capability modifiers to its own section
1149
1150 * Clarify instructions on the ack ('~') modifier, indicating it
1151 can be used with sticky capabilities.
1152
1153 * Add a note into CAP section about capability modifiers
1154
1155 2005-01-21 KLM
1156
1157 * Subcommands are not optional anymore; updated the description
1158 of CAP and the ABNF to reflect this.
1159
1160 * More than one modifier may precede a capability name.
1161
1162
1163 Mitchell, et al. Expires September 5, 2005 [Page 25]
1164 Internet-Draft IRC CAP March 2005
1165
1166 * Move ABNF for capmod into the "Capability Modifiers" section.
1167
1168 * Fix a few minor grammatical errors (I think).
1169
1170 * Note that capability names may be preceded by modifiers in the
1171 first form of ACK.
1172
1173 * Remove an unnecessary "MAY" in documentation for the third
1174 usage of ACK.
1175
1176 * Explicitly note in the ABNF for NAK that the parameter is an
1177 opaque repeat of at least the first 100 characters of the
1178 argument to REQ.
1179
1180 * CLEAR may result in more than one ACK.
1181
1182 * Clarify the language of what composes a capability name.
1183
1184 * Add missing </figure>.
1185
1186 * ACK subcommand should be sent in response to ACK with ack
1187 modifier as soon as possible...
1188
1189 * Allow disable modifier in LIST, but only in conjunction with an
1190 ack modifier.
1191
1192 * The ack modifier may also show up in an LS response; rewrote
1193 the final paragraph to indicate that and clarify the language.
1194
1195 * Add "Client" to the title in the appropriate place...
1196
1197 * The "capability" rule in the ABNF got changed to "capab" for
1198 brevity.
1199
1200 * Update "date" to be current.
1201
1202 2005-01-22 LH
1203
1204 * Clarify a client must not act upon an ACK spread across
1205 multiple lines until it receives the final ACK of the set.
1206
1207 2005-01-23 KLM
1208
1209 * Bump version number in preparation for any suggested edits...
1210
1211
1212
1213 Mitchell, et al. Expires September 5, 2005 [Page 26]
1214 Internet-Draft IRC CAP March 2005
1215
1216 2005-01-26 LH
1217
1218 * Clarify a server also must not change capabilities until its
1219 finished sending its ACKs.
1220
1221 2005-01-27 KLM
1222
1223 * Acknowledge Aaron Wiebe as participating.
1224
1225 2005-03-01 LH
1226
1227 * Add examples on sticky modifiers, the removal modifier and the
1228 sticky modifier.
1229
1230 2005-03-07 KLM
1231
1232 * Submit second draft...
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249 Mitchell, et al. Expires September 5, 2005 [Page 27]
1250 Internet-Draft IRC CAP March 2005
1251
1252 Intellectual Property Statement
1253
1254 The IETF takes no position regarding the validity or scope of any
1255 Intellectual Property Rights or other rights that might be claimed to
1256 pertain to the implementation or use of the technology described in
1257 this document or the extent to which any license under such rights
1258 might or might not be available; nor does it represent that it has
1259 made any independent effort to identify any such rights. Information
1260 on the procedures with respect to rights in RFC documents can be
1261 found in BCP 78 and BCP 79.
1262
1263 Copies of IPR disclosures made to the IETF Secretariat and any
1264 assurances of licenses to be made available, or the result of an
1265 attempt made to obtain a general license or permission for the use of
1266 such proprietary rights by implementers or users of this
1267 specification can be obtained from the IETF on-line IPR repository at
1268 http://www.ietf.org/ipr.
1269
1270 The IETF invites any interested party to bring to its attention any
1271 copyrights, patents or patent applications, or other proprietary
1272 rights that may cover technology that may be required to implement
1273 this standard. Please address the information to the IETF at
1274 ietf-ipr@ietf.org.
1275
1276 Disclaimer of Validity
1277
1278 This document and the information contained herein are provided on an
1279 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1280 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1281 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1282 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1283 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1284 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1285
1286 Copyright Statement
1287
1288 Copyright (C) The Internet Society (2005). This document is subject
1289 to the rights, licenses and restrictions contained in BCP 78, and
1290 except as set forth therein, the authors retain all their rights.
1291
1292 Acknowledgment
1293
1294 Funding for the RFC Editor function is currently provided by the
1295 Internet Society.
1296
1297
1298 Mitchell, et al. Expires September 5, 2005 [Page 28]

Properties

Name Value
svn:eol-style native
svn:keywords "Id Revision"

svnadmin@ircd-hybrid.org
ViewVC Help
Powered by ViewVC 1.1.28