| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2008.
Copyright © The IETF Trust (2007).
Most ChanServ-based IRC services share basic common features and syntax, still IRC clients, automations and robots are unable to interact with these services across IRC networks in a generic way due to varying translations, versions and local modifications. The goal of this Internet Draft is to make it possible for IRC users to understand IRC's service messages in their native language, and successfully interact with them. Also to allow client applications to produce easy graphical interfaces to fulfil the requirements of elaborate persistent conference control on IRC systems.
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 RFC 2119.
The style of this specification still needs clean-ups. It shouldn't address users as "you." It shouldn't say "should" and "must" in non-final lower case. And there are details left to work out. Let us not add anything else to this specification or we just won't finish it! Rather reduce it further than add more, and put future extensions into future IRC+ drafts.
1.
Dependencies
2.
Introduction
2.1.
Background
2.2.
Overview
3.
Detecting IRC+ network and switching to IRC+ mode
4.
Replies
4.1.
800 RPL_SERVICES_SUPPORTS_IRCPLUS - List of supported IRC+ features
4.2.
801 RPL_SERVICES_NEEDPASS - Need password
4.3.
804 RPL_SERVICES_COMMAND_SUCCESS - Command Success
4.4.
805 RPL_SERVICES_COMMAND_ERROR - Command Error
4.5.
806 RPL_SERVICES_INFO - Information about nick/channel
4.6.
807 RPL_SERVICES_INFO_END - End of information about nick/channel
4.7.
823 RPL_SERVICES_CHANSERV_CHANKEY - Channel key
5.
Queries
5.1.
Common
5.1.1.
IRCPLUS - enabling/disabling IRC+ mode
5.1.2.
INFO
5.1.3.
DROP
5.1.4.
Set
5.2.
Conference Control
5.2.1.
REGISTER
5.2.2.
DROP
5.2.3.
OP
5.2.4.
DEOP
5.2.5.
VOICE
5.2.6.
DEVOICE
5.2.7.
HALFOP
5.2.8.
DEHALFOP
5.2.9.
PROTECT
5.2.10.
DEPROTECT
5.2.11.
OWNER
5.2.12.
DEOWNER
5.2.13.
INVITE
5.2.14.
UNBAN
5.2.15.
KICK
5.2.16.
BAN
5.2.17.
TOPIC
5.2.18.
CLEAR
5.2.19.
GETKEY
6.
Normative References
Appendix A.
Error codes
Appendix B.
XML definition of the services capabilities
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Many operations specified in this document require the user to be authenticated to the IRC network. Thus, to implement this protocol, the IRC+ Identity Protocol defined in its own document must already be successfully available.
| TOC |
| TOC |
Ever since the invention of channel operatorship in 1989 conference control on IRC has been powerfully flexible, but at the same time unreliable and vulnerable. The new hierarchical structure in fact triggered a continuous wish to be in power, and channel operatorship was never an unpleasant technical job, but always seen as a status of importance, and handing out channel operatorship a gesture of elementary respect. Yet each such gesture jeopardized the channel as the recipient of power might find it funny to 'take over' the control of the channel and make everyone else angry or desperate.
It is truly amazing how a bunch of technical modes in the IRC protocol managed to cause so many troubles and years of conference control battle. On networks which do not provide any stabilizing channel service, conference control politics and abuse are still the number one discussion topic today, creating the impression that IRC is a chat technology that primarily chats about itself.
Due to the decentralized nature of the IRC protocol, only a centralized external service could solve the problem of conference control stability. In 1995 the DALnet operators introduced a tool called ChanServ, which added a new abstraction layer to conference control on IRC. By having the final word on the state of a channel on the IRC network, ChanServ brings order and admittedly strict regulation to the system. Still, by having conference control simply work, it took the focus away from channel power fights and back to the actual topics of the conversations.
Today dozens of derivates and variations of the ChanServ tool have been put in operation on all IRC networks but a few. These services were inspired by the original ChanServ, but have evolved into many different and incompatible flavors. This specification proposes a common protocol for services to ensure interoperability.
Additionally to the messaging interface the end users are familiar with, although they are different on each network, this protocol adds a more generalized, abstract and client developer friendly interface to the typical function needed for managing and securing conference control in all its complexity on IRC.
| TOC |
Numerics SHOULD fit RFC 1459 requirements. Services SHOULD send numeric replies, where all meaningful parts SHOULD be message parameters, and not the text part. For example:
:prefix 8xx ChanServ #channel FOUNDER NICK :is channel founder
But not
:prefix 8xx ChanServ NICK :is #channel founder
ABNF for service message or reply
Many of these commands may not actually have an appropriate BNF/ABNF syntax.
ServicesMessage = prefix numeric service parameterList [":" trailing] service = "ChanServ" / "NickServ" / "MemoServ" / "BotServ" / "OperServ" parameterList = singleParameter [parameterList]
The prefix is a standard IRC prefix, containing ":" and server name.
Numerics should be in an otherwise unused range (as of this draft, 800-899). This range may be reassigned or reorganized later, and this list is not to be considered authoritative.
Some services provide functionality which isn't covered by this specification. Please keep on sending NOTICEs in that case, do not come up with your own numerics, help IRC+ provide further specifications to fill in the gaps.
| TOC |
An IRC+ compliant IRCd SHOULD include the IRCPLUS parameter in its server RPL_ISUPPORT message.
IRC+ compliant services MUST send an 800 code to the user with a list of the supported IRC+ features.
If the IRC client supports IRC+ mode, it MAY send a command to NickServ and the IRC server with enabling IRC+ mode request (IRCPLUS - enabling/disabling IRC+ mode). IRC+ mode MUST be set only on a per-session basis. If services and the server are not given this request, they MUST NOT use IRC+ mode.
| TOC |
| TOC |
Tells the client what IRC+ features the local service supports.
800 RPL_SERVICES_SUPPORTS_IRCPLUS
Syntax
:prefix 801 MESSAGE_TARGET DEFINITION_URL TOKENLIST
DEFINITION_URL - address of the XML definition of the services capabilities (XML definition of the services capabilities).
TOKENLIST is a list of supported features for IRC+. This list does not exist yet as of this draft.
| TOC |
Requires client to identify or use password with command.
801 RPL_SERVICES_NEEDPASS
Syntax
:prefix 801 MESSAGE_TARGET SERVICE PASS_TARGET COMMAND [SUPPORTED_AUTH_METHODS]
Where PASS_TARGET – registered target. Nick or Channel.
SUPPORTED_AUTH_METHODS SHOULD give a user list of supported auth methods and required tags.
Example
//both methods :prefix 801 Alexey NickServ Alexey PLAIN SASL[...] //only secure auth :prefix 801 Alexey ChanServ #kvirc SASL[...]
| TOC |
Indicates, that the command completed successfully.
Syntax
:prefix 804 MESSAGE_TARGET SERVICE COMMAND :command ok
Where COMMAND – last used command.
Example
:prefix 804 NickServ SET :command ok
| TOC |
Indicates that command failed or is unknown. 805 RPL_SERVICES_COMMAND_ERROR
Syntax
:prefix 805 MESSAGE_TARGET SERVICE COMMAND ERRNO :error text
Where COMMAND – last used command. ERRNO – error code.
See also: Error codes (Error codes)
Example
| TOC |
806 RPL_SERVICES_INFO
Syntax
prefix 806 MESSAGE_TARGET SERVICE INFO_TARGET INFO_TAG :VALUE
Where INFO_TAG can be:
Example
:prefix 806 Alexey NickServ #kvirc REGISTERED :1000000
| TOC |
Indicates end of information about nick/channel 807 RPL_SERVICES_INFO_END
Syntax
:prefix 807 MESSAGE_TARGET SERVICE INFO_TARGET :End of info
Example
:prefix 807 Alexey NickServ #kvirc :End of info
| TOC |
Returns the key of the given channel.
Syntax
:prefix 823 CHANNEL CHAN_KEY
Example
:prefix 823 #kvirc qwerty
| TOC |
| TOC |
| TOC |
Enables or disables IRC+ mode.
Syntax
Query = ServiceNick "IRCPLUS" ( "ON" / "OFF" )
Numeric replies:
| TOC |
Displays information about the given target
Syntax
Query = ServiceNick "INFO" target ["ALL"]
If the keyword "ALL" is appended to the request, additional information will be returned in the reply.
Numeric replies:
| TOC |
Drops a channel from the service database. A channel that has been dropped is free for anyone to re-register.
Syntax
Query = ServiceNick "DROP" target
Numeric replies:
| TOC |
Sets various options.
Syntax
Query = ServiceNick "SET" [target] option value
In order to use this command, the user is required to identify first.
Numeric replies:
| TOC |
| TOC |
Registers a <channel> in the ChanServ database.
Syntax
Query = ChanServ REGISTER channel [password] [:description]
Numeric replies:
| TOC |
Unregisters the named channel.
Syntax
Query = ChanServ DROP channel
Numeric replies:
| TOC |
Ops a selected nick on a channel.
Syntax
Query = ChanServ OP channel [nick]
Numeric replies:
| TOC |
Deops a selected nick on a channel.
Syntax
Query = ChanServ DEOP channel [nick]
Numeric replies:
| TOC |
Voices a selected nick on a channel.
Syntax
Query = ChanServ VOICE channel [nick]
Numeric replies:
| TOC |
Devoices a selected nick on a channel.
Syntax
Query = ChanServ DEVOICE channel [nick]
Numeric replies:
| TOC |
Halfops a selected nick on a channel.
Syntax
Query = ChanServ HALFOP channel [nick]
Numeric replies:
| TOC |
Dehalfops a selected nick on a channel.
Syntax
Query = ChanServ DEHALFOP channel [nick]
Numeric replies:
| TOC |
Protects a selected nick on a channel.
Syntax
Query = ChanServ PROTECT channel [nick]
Numeric replies:
| TOC |
Deprotects a selected nick on a channel.
Syntax
Query = ChanServ DEPROTECT channel [nick]
Numeric replies:
| TOC |
Gives you owner status on channel.
Syntax
Query = ChanServ OWNER channel
Numeric replies:
| TOC |
Removes your owner status on channel.
Syntax
Query = ChanServ DEOWNER channel
Numeric replies:
| TOC |
Tells ChanServ to invite you (or someone else) into the given channel.
Syntax
Query = ChanServ INVITE channel [target]
Numeric replies:
| TOC |
Tells ChanServ to remove all bans preventing you (or someone else) from entering the given channel.
Syntax
Query = ChanServ UNBAN channel [nick]
Numeric replies:
| TOC |
Kicks a selected nick on a channel.
Syntax
Query = ChanServ KICK channel nick [reason]
Numeric replies:
| TOC |
Bans a selected nick on a channel.
Syntax
Query = ChanServ BAN channel nick
Numeric replies:
| TOC |
Causes ChanServ to set the channel topic to the specified one.
Syntax
Query = ChanServ TOPIC channel topic
Numeric replies:
| TOC |
Tells ChanServ to clear certain settings on a channel.
Syntax
Query = ChanServ CLEAR channel what
Numeric replies:
| TOC |
Returns the key of the given channel.
Syntax
Query = ChanServ GETKEY channel
Numeric replies:
| TOC |
| TOC |
| TOC |
The example (not ready yet):
| TOC |
| Alexey | |
| KVIrc Development Team | |
| Bibliotechnaya | |
| Volgograd, Volgograd | |
| Russia | |
| Phone: | +7 905 333 50 50 |
| Fax: | |
| Email: | |
| URI: | http://www.kvirc.ru |
| Anna Gulchouk | |
| KVIrc Development Team | |
| Maydan Nezalezhnosti | |
| Kiev, 01140 | |
| Ukraine | |
| Phone: | +380 96 978 67 50 |
| Fax: | |
| Email: | inviolatums@gmail.com |
| URI: | http://www.kvirc.ru |
| Adam Schrotenboer | |
| SurrealServices project | |
| El Camino Real | |
| Mountain View, California 94040 | |
| United States | |
| Phone: | |
| Fax: | |
| Email: | |
| URI: | http://www.surrealchat.net/wiki/SurrealServices |
| William Pitcock | |
| atheme.org | |
| 1428 S Evanston Ave. | |
| Tulsa, Oklahoma 74104 | |
| United States of America | |
| Phone: | +1 (918) 814-0311 |
| Fax: | |
| Email: | nenolod@atheme.org |
| URI: | http://www.nenolod.net |
| Carlo v. Loesch | |
| psyc://psyced.org/~lynX | |
| Berlin, Berlin | |
| Phone: | |
| Fax: | |
| Email: | psyc://psyced.org/~lynX |
| URI: | http://my.pages.de/ |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).