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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 503 - (hide annotations)
Fri Mar 3 19:53:47 2006 UTC (15 years, 2 months ago) by michael
File MIME type: text/plain
File size: 43886 byte(s)
- Backported CAP changes from HEAD since it doesn't affect
  any of the ircd's core components and should be supported
  as soon as possible.

1 michael 503
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