CTCP Version 1 | Klaus Zeuge
Troy Rollo Ben Mesander May 1993 |
CTCP Version 1 | Klaus Zeuge
Troy Rollo Ben Mesander May 1993 |
A request/reply pair is sent between the two clients in two phases. The first phase is to send the request. This is done with a "privmsg" command (either to a nick or to a channel -- it doesn't matter).
The second phase is to send a reply. This is done with a "notice" command.
The known request/reply pairs are for the following commands.
This is used to get a user's real name, and perhaps also the idle time of the user (this usage has been obsoleted by enhancements to the IRC protocol. The request is in a "privmsg" and looks like
\001FINGER\001
while the reply is in a "notice" and looks like
\001FINGER :#\001
where the # denotes contains information about the users real name, login name at clientmachine and idle time and is of type X-N-AS.
This is used to get information about the name of the other client and the version of it. The request in a "privmsg" is simply
\001VERSION\001
and the reply
\001VERSION #:#:#\001
where the first # denotes the name of the client, the second # denotes the version of the client, the third # the enviroment the client is running in.
Using
X-N-CLN ::= '\000' .. '\071' | '\073' .. '\377'
the client name is a string of type X-N-CLN saying things like "Kiwi" or "ircII", the version saying things like "5.2" or "2.1.5c", the enviroment saying things like "GNU Emacs 18.57.19 under SunOS 4.1.1 on Sun SLC" or "Compiled with gcc -ansi under Ultrix 4.0 on VAX-11/730".
This is used to get information about where to get a copy of the client. The request in a "privmsg" is simply
\001SOURCE\001
and the reply is zero or more CTCP replies of the form
\001SOURCE #:#:#\001
followed by an end marker
\001SOURCE\001
where the first # is the name of an Internet host where the client can be gotten from with anonymous FTP the second # a directory names, and the third # a space separated list of files to be gotten from that directory.
Using
X-N-SPC ::= '\000' .. '\037' | '\041' .. '\377'
the name of the FTP site is to be given by name like "cs.bu.edu" or "funic.funet.fi".
The file name field is a directory specification optionally followed by one or more file names, delimited by spaces. If only a directory name is given, all files in that directory should be copied when retrieving the clients source. If some files are given, only those files in that directpry should be copied. Note that the spcification allows for all characters but space in the names, this includes allowing :. Examples are "pub/emacs/irc/" to get all files in directory pub/emacs/irc/, the client should be able to first login as user "ftp" and the give the command "CD pub/emacs/irc/", followed by the command "mget *". (It of course has to take care of binary and prompt mode too). Another example is "/pub/irc Kiwi.5.2.el.Z" in which case a "CD /pub/irc" and "get Kiwi.5.2.el.Z" is what should be done.
This is used to transmit a string which is settable by the user (and never should be set by the client). The query is simply
\001USERINFO\001
with the reply
\001USERINFO :#\001
where the # is the value of the string the client's user has set.
This is for client developers use to make it easier to show other client hackers what a certain client knows when it comes to CTCP. The replies should be fairly verbose explaining what CTCP commands are understood, what arguments are expected of what type, and what replies might be expected from the client.
The query is the word CLIENTINFO in a "privmsg" optionally followed by a colon and one or more specifying words delimited by spaces, where the word CLIENTINFO by itself,
\001CLIENTINFO\001
should be replied to by giving a list of known tags (see above in section TAGGED DATA). This is only intended to be read by humans.
With one argument, the reply should be a description of how to use that tag. With two arguments, a description of how to use that tag's subcommand. And so on.
This is used as a reply whenever an unknown query is seen. Also, when used as a query, the reply should echo back the text in the query, together with an indication that no error has happened. Should the query form be used, it is
\001ERRMSG #\001
where # is a string containing any character, with the reply
\001ERRMSG # :#\001
where the first # is the same string as in the query and the second # a short text notifying the user that no error has occurred.
A normal ERRMSG reply which is sent when a corrupted query or some corrupted extended data is received, looks like
\001ERRMSG # :#\001
where the first # is the the failed query or corrupted extended data and the second # a text explaining what the problem is, like "unknown query" or "failed decrypting text".
Ping is used to measure the time delay between clients on the IRC network. A ping query is encoded in a privmsg, and has the form:
\001PING timestamp\001
where `timestamp' is the current time encoded in any form the querying client finds convienent. The replying client sends back an identical message inside a notice:
\001PING timestamp\001
The querying client can then subtract the recieved timestamp from the current time to obtain the delay between clients over the IRC network.
Time queries are used to determine what time it is where another user's client is running. This can be useful to determine if someone is probably awake or not, or what timezone they are in. A time query has the form:
\001TIME\001
On reciept of such a query in a privmsg, clients should reply with a notice of the form:
\001TIME :human-readable-time-string\001
For example:
\001TIME :Thu Aug 11 22:52:51 1994 CST\001
Sending
PRIVMSG victim :\001FINGER\001
might return
:victim NOTICE actor :\001FINGER :Please check my USERINFO instead :Klaus Zeuge (sojge@mizar) 1 second has passed since victim gave a command last.\001
(this is only one line) or why not
:victim NOTICE actor :\001FINGER :Please check my USERINFO instead :Klaus Zeuge (sojge@mizar) 427 seconds (7 minutes and 7 seconds) have passed since victim gave a command last.\001
if Klaus Zeuge happens to be lazy? :-)
Sending
PRIVMSG victim :\001CLIENTINFO\001
might return
:victim NOTICE actor :\001CLIENTINFO :You can request help of the commands CLIENTINFO ERRMSG FINGER USERINFO VERSION by giving an argument to CLIENTINFO.\001
Sending
PRIVMSG victim :\001CLIENTINFO CLIENTINFO\001
might return
:victim NOTICE actor :\001CLIENTINFO :CLIENTINFO with 0 arguments gives a list of known client query keywords. With 1 argument, a description of the client query keyword is returned.\001
while sending
PRIVMSG victim :\001clientinfo clientinfo\001
probably will return something like
:victim NOTICE actor :\001ERRMSG clientinfo clientinfo :Query is unknown\001
as tag "clientinfo" isn't known.
Sending
PRIVMSG victim :\001CLIENTINFO ERRMSG\001
might return
:victim NOTICE actor :\001CLIENTINFO :ERRMSG is the given answer on seeing an unknown keyword. When seeing the keyword ERRMSG, it works like an echo.\001
Sending
PRIVMSG victim :\001USERINFO\001
might return the somewhat pathetically long
:victim NOTICE actor :\001USERINFO :I'm studying computer science in Uppsala, I'm male (somehow, that seems to be an important matter on IRC:-) and I speak fluent swedish, decent german, and some english.\001
Sending
PRIVMSG victim :\001VERSION\001
might return:
:victim NOTICE actor :\001VERSION Kiwi:5.2:GNU Emacs 18.57.19 under SunOS 4.1.1 on Sun SLC:FTP.Lysator.LiU.SE:/pub/emacs Kiwi-5.2.el.Z Kiwi.README\001
if the client is named Kiwi of version 5.2 and is used under GNU Emacs 18.57.19 running on a Sun SLCwith SunOS 4.1.1. The client claims a copy of it can be found with anonymous FTP on FTP.Lysator.LiU.SE after giving the FTP command "cd /pub/emacs/". There, one should get files Kiwi-5.2.el.Z and Kiwi.README; presumably one of the files tells how to proceed with building the client after having gotten the files.
PREVIOUS PAGE | TABLE OF CONTENTS | NEXT PAGE
Comments about this page? Send them to
webmaster (at) invlogic.com.
Return to Innovative Logic's Home Page.
Last modified: 17-Sep-2004 01:04PM.
Pages copyright ©1996-1997,
Innovative Web Creations.
All rights reserved.