| 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 identification services on IRC share basic common features and syntax and even the name 'NickServ'. Yet 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 basic needs of electronic identity 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.
Introduction
1.1.
Background
1.2.
Overview
2.
Detecting IRC+ network and switching to IRC+ mode
3.
Replies
3.1.
800 RPL_SERVICES_SUPPORTS_IRCPLUS - List of supported IRC+ features
3.2.
801 RPL_SERVICES_NEEDPASS - Need password
3.3.
802 RPL_SERVICES_PASSOK - Auth Ok
3.4.
803 RPL_SERVICES_BADPASS - Password incorrect
3.5.
804 RPL_SERVICES_COMMAND_SUCCESS - Command Success
3.6.
805 RPL_SERVICES_COMMAND_ERROR - Command Error
3.7.
806 RPL_SERVICES_INFO - Information about nick/channel
3.8.
807 RPL_SERVICES_INFO_END - End of information about nick/channel
3.9.
808 RPL_SERVICES_ERROR_NEEDREGISTRATION - You must register the nick
3.10.
809 RPL_SERVICES_NICKSTATUS - Returns nick status
3.11.
810 RPL_SERVICES_MEMO_READ - Your memo was read
3.12.
814 RPL_SERVICES_LIST_START - Start list output
3.13.
815 RPL_SERVICES_LIST - List output
3.14.
816 RPL_SERVICES_LIST_END - End list output
3.15.
820 RPL_SERVICES_MEMO_START - Start memo output
3.16.
821 RPL_SERVICES_MEMO - Memo output
3.17.
822 RPL_SERVICES_MEMO_END - End memo output
4.
Queries
4.1.
Common
4.1.1.
IRCPLUS - enabling/disabling IRC+ mode
4.1.2.
IDENTIFY
4.1.3.
INFO
4.1.4.
DROP
4.1.5.
SET
4.2.
Identity Services
4.2.1.
REGISTER
4.2.2.
LINK
4.2.3.
LOGOUT
4.2.4.
ACCESS
4.2.5.
RECLAIM
4.2.6.
LIST LINKS
4.2.7.
STATUS
4.2.8.
SENDPASS
4.3.
Offline Messaging Service
4.3.1.
SEND
4.3.2.
LIST
4.3.3.
READ
4.3.4.
DEL
5.
Normative References
Appendix A.
Error codes
Appendix B.
Nick status codes
Appendix C.
XML definition of the services capabilities
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
| TOC |
One day in 1991, Jupiter killed NickServ. That day marked the beginning of a dark period in the evolution of IRC: Nicknames weren't owned. Virtual identities were not reliable. Sixteen years later, most large IRC networks have overcome this wrong attitude.
Since the IRC protocol does not protect identities natively, external programs called services have been employed. These services were inspired by the original NickServ, 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 functions needed for managing and securing your digital identity on IRC.
| TOC |
Numerics MUST fit RFC 1459 requirements. Services SHOULD send numeric replies, where all meaningful parts SHOULD be message parameters, not the text part.
ABNF for numeric messages or replies from services:
ServicesMessage = prefix numeric parameterList [":" trailing]
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 IRC server SHOULD include the IRCPLUS parameter in its server RPL_ISUPPORT message.
IRC+ compliant services MUST send an 800 code to any client as it enters the IRC network, containing a list of the supported IRC+ features.
If the IRC client supports IRC+ mode, it MAY send a command to the ircplus service enabling IRC+ mode (IRCPLUS - enabling/disabling IRC+ mode). IRC+ mode MUST be set on a per-session basis only. If services and the server are not given this request, they MUST NOT use IRC+ mode.
| TOC |
In the subsequent paragraphs MESSAGE_TARGET is the current nickname of the recipient of the message.
| TOC |
Tells the client which IRC+ services are available and how to access them.
800 RPL_SERVICES_SUPPORTS_IRCPLUS
Syntax
:prefix 800 MESSAGE_TARGET IRCPLUS_SERVICES_LIST :TRAILING
IRCPLUS_SERVICES_LIST is a list of supported services by IRC+. This document defines a IRCPLUS and an IDENTITY service feature set. Further documents will define further services listable in this message.
Each service is assigned a protocol message command to use to submit requests to it. These MAY differ from network to network. It is recommended to use the service name itself as a command, but you MAY use historic nicknames such as NickServ or even a combined command and argument string such as "PRIVMSG NickServ".
TRAILING MAY be used to deliver a visual message to legacy client users. It SHOULD NOT be displayed by IRC+ compliant clients. TRAILING is optional.
Example of Typical Configuration:
:NickServ 800 tabris IRCPLUS="NickServ" IDENTITY="NickServ" :are our IRC+ services
In this example the command used to send identity service requests is "NickServ". The command used to send generic services requests, like enabling IRC+ mode, is also called "NickServ".
Example of Ideal Configuration:
:irc.example.net 800 WiZ IRCPLUS="IRCPLUS" IDENTITY="IDENTITY"
Note: The design rationale here is to be able to adapt to existing network infrastructure and not require modification to deployed IRC server software, but also to indicate a path for future simplification, should all networks agree on this common syntax in a distant future, thus making the service to nickname mapping unnecessary.
| 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 password was accepted.
802 RPL_SERVICES_PASSOK
Syntax
:prefix 802 MESSAGE_TARGET SERVICE PASS_TARGET :password accepted
Where PASS_TARGET – registered target. Nick or Channel.
Example
:prefix 802 Alexey NickServ Alexey :password accepted :prefix 802 Alexey ChanServ #kvirc :password accepted
| TOC |
Indicates, that the password is invalid.
803 RPL_SERVICES_BADPASS
Syntax
:prefix 803 MESSAGE_TARGET SERVICE PASS_TARGET :password wrong
Where PASS_TARGET – registered target. Nick or Channel.
Example
:prefix 803 Alexey NickServ Alexey :password wrong :prefix 803 Alexey ChanServ #kvirc :password wrong
| 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 |
Indicates that the user is required to register the nick.
Syntax
:prefix 808 MESSAGE_TARGET SERVICE :Your nick must be registered first
Example
:prefix 808 Alexey NickServ :Your nick must be registered first
| TOC |
Returns whether the user using the given nickname is recognized as the owner of the nickname.
Syntax
:prefix 809 NICKNAME STATUS_CODE
Where nickname is the nickname sent with the command, and status-code is one of the following:
Example
:prefix 809 Inviolatum OWNER_VIA_PASSWORD
See also: Nick status codes (Nick status codes)
| TOC |
Syntax
:prefix 810 MESSAGE_TARGET SERVICE INFO_TARGET :Your memo to <INFO_TARGET> was read.
Where <INFO_TARGET> is memo recipient.
Example
:prefix 810 Inviolatum MemoServ Alexey :Your memo to Alexey was read.
| TOC |
Start list command tag
Syntax
:prefix 814 MESSAGE_TARGET SERVICE LIST_TITLE [[PARAM1] ...]
LIST_TITLE - is the type of list; PARAMs is used to identify list targets
Example
:prefix 814 Inviolatum ChanServ AOP #kvirc :prefix 814 Inviolatum NickServ ACCESS Alexey
| TOC |
List item content
Syntax
:prefix 815 MESSAGE_TARGET SERVICE ITEM_NUM [LEVEL]: ITEM_TEXT
Where ITEM_NUM is number of item in the list. LEVEL is used for permission lists.
Example
:prefix 815 Inviolatum ChanServ 1 99999 :Inviolatum
| TOC |
End of list
Syntax
:prefix 816 MESSAGE_TARGET SERVICE :End of list
Example
:prefix 816 Inviolatum ChanServ :End of list
| TOC |
Starts memo output
Syntax
:prefix 820 MESSAGE_TARGET MemoServ MEMO_SENDER MEMO_TARGET :Memo start
Example
:prefix 820 Inviolatum MemoServ Alexey Inviolatum :Memo start
This message should provide a time stamp, either as a regular argument or in form of an embedded CTCP TS. The latter has the advantage of being generically embeddable in any message.
| TOC |
Memo text
Syntax
:prefix 821 MESSAGE_TARGET MemoServ MEMO_SENDER MEMO_TARGET :TEXT
Where MEMO_SENDER - sender nick and TEXT is memo text.
Example
:prefix 821 Inviolatum MemoServ Alexey #kvirc :Hi! :prefix 821 Inviolatum MemoServ Alexey Inviolatum :Hi!
| TOC |
End of memo
Syntax
:prefix 822 MESSAGE_TARGET MemoServ MEMO_SENDER MEMO_TARGET :End of memo
Example
:prefix 822 Inviolatum MemoServ Alexey Inviolatum :End of memo
| TOC |
| TOC |
| TOC |
Enables or disables IRC+ mode.
Syntax
Query = ServiceNick "IRCPLUS" ( "ON" / "OFF" ) [Locale [ CharSet ]]
Numeric replies:
| TOC |
Confirm nick or channel ownership.
Syntax
Query = ServiceNick "IDENTIFY" target [method auth-data]
target being a target entity to identify, a user nickname in the case of NickServ or a channel in the case of ChanServ. ServiceNick can thus be one of:
If no METHOD AUTH-DATA given, server SHOULD send a greeting message (801 RPL_SERVICES_NEEDPASS - Need password) with a list of supported methods.
PLAIN auth sends password in open and unsecure way. It is not recommended to use it with a non-SSL connection. The syntax of plain auth is:
Syntax
Query = ServiceNick "IDENTIFY" target "PLAIN" password
Where pasword MUST be the password specified before using the REGISTER command.
SASL is a rather better system, that may use Diffie-Hellman key-exchange and Blowfish encryption.
Syntax
Query = ServiceNick "IDENTIFY" target "SASL" [auth-data]
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 given nickname from the service database. A nickname 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 your nickname in the NickServ database.
Syntax
Query = NickServ REGISTER [password [email]]
The parameter email is optional and will set the email associated with your nick immediately. However, it may be required on certain networks. Your privacy is respected; this e-mail won't be given to any third-party person.
Numeric replies:
| TOC |
This command makes your nickname join the target nickname's group.
Syntax
Query = NickServ LINK target password
Where target is primary nick with password password.
Numeric replies:
| TOC |
This reverses the effect of the IDENTIFY command, i.e. make you not recognized as the real owner of the nick anymore. Note, however, that you won't be asked to reidentify yourself.
Syntax
Query = NickServ logout
Numeric replies:
| TOC |
Modifies or displays the access list for your nick.
| TOC |
Adds allowed hostmask.
Syntax
Query = NickServ ACCESS ADD mask
Numeric replies:
| TOC |
Delete allowed hostmask.
Syntax
Query = NickServ ACCESS DEL mask
Numeric replies:
| TOC |
This is the list of addresses which will be automatically recognized by NickServ as allowed to use the registered nick.
Syntax
Query = NickServ ACCESS LIST
Numeric replies:
| TOC |
Defines situations in which the user needs to reclaim a nickname.
| TOC |
Allows you to recover your nickname if someone else has taken it.
Syntax
Query = NickServ RECLAIM RECOVER nickname [password]
When you give this command, NickServ will bring a fake user online with the same nickname as the user you're trying to recover your nick from.
Numeric replies:
| TOC |
Instructs NickServ to remove any hold on a user's nickname caused by automatic kill protection or use of the RECOVER command.
Syntax
Query = NickServ RECLAIM RELEASE nickname [password]
In order to use the RECLAIM RELEASE command for a nick, the user's current address (as shown in /WHOIS) MUST be on nickname's access list and the user MUST be identified with a nick in the same group of nickname, or the user MUST supply the correct password for nickname.
Numeric replies:
| TOC |
Terminates a "ghost" IRC session using your nick.
Syntax
Query = NickServ RECLAIM GHOST nickname [password]
In order to use the RECLAIM GHOST command for a nick, the user's current address (as shown in /WHOIS) MUST be on nickname's access list and the user MUST be identified with a nick in the same group of nickname, or the user MUST supply the correct password for nickname.
Numeric replies:
| TOC |
Lists all nicks in your group.
Syntax
Query = NickServ LIST LINKS [nick]
Numeric replies:
| TOC |
Returns whether the user using the given nickname is recognized as the owner of the nickname.
Syntax
Query = NickServ STATUS [nickname1 [nickname2 [nickname3]]]
Up to sixteen nicknames may be sent with each command, the rest will be ignored. The nicknames may be specified either comma-delimited or space delimited. If no nickname is given, the status of the requesting nickname will be returned.
Numeric replies:
| TOC |
Sends the password of the given nickname to the e-mail address set in the nickname record.
Syntax
Query = NickServ SENDPASS nickname
May be limited to IRC operators on certain networks.
Numeric replies:
| TOC |
| TOC |
Sends to the specified nick or channel a memo containing memo-text.
Syntax
Query = MemoServ SEND memo-target memo-text
Numeric replies:
| TOC |
Lists all your currently pending memos.
Syntax
Query = MemoServ "LIST" [Channel [( List / "NEW" )]]
Numeric replies:
| TOC |
Sends you the text of the memos specified.
Syntax
Query = MemoServ "READ" [Channel [( Num / List / "LAST" / "NEW" )]]
Numeric replies:
| TOC |
Deletes the specified memo or memos.
Syntax
Query = MemoServ DEL [channel] (list / "LAST" / "ALL")
List SHOULD be a number range, such as 1-9 or 1-9,12
If LAST is given, the last memo will be deleted. If ALL is given, deletes all of your memos.
Numeric replies:
| TOC |
| TOC |
| TOC |
| TOC |
The example (not ready yet):
Example:
<ircplus>
<identity text="NS">
<REGISTER><required>
<!-- alternatives: <password/> -->
<page src="http://somewhere/register.pike" />
</required>
<!-- optional email doesn't make sense in this case,
just an example -->
<optional><email/></optional>
</REGISTER>
<!-- also known as DROP, or should this be an on/off thing? -->
<UNREGISTER><required><SASL/></required></UNREGISTER>
<CONNECT>
<required><SASL/></required>
TODO: on/off (= IDENTIFY, LOGOUT)
</CONNECT>
<SET>
<!-- you can freestyle on properties -->
<property>HOMEPAGE</property>
</SET>
<INFO>
<required><entity/></required>
<optional><ALL/></optional>
</INFO>
<RECLAIM>
<required><entity/><SASL/></required>
TODO: once (= GHOST), on/off (= RECOVER, RELEASE)
... technically it's a per-nick setting, right?
</RECLAIM>
<NICK>
<!-- could be interpreted as account merger in some cases -->
<required></modifier><entity/><SASL/></required>
<!-- modifier is + or - for LINK or UNLINK -->
</NICK>
<ACCESS>
<!-- modifier is + or - for ADD or DEL -->
<required><modifier/><mask/></required>
</ACCESS>
</identity>
<memos>
<SEND><optional><notification/></optional></SEND>
</memos>
</ircplus>| 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).