The E T O V P Protocol Erpoumimcs Toe Operation Verification Protocol (Document/Protocol Version 1.0) E R P O U I M C S (Document/Protocol Version 1.0) Ertsartachzartaavnua Rireeutyuiasazachzaara Protocol Oversimplified and Unrecommended for Instant Messages and Chat Services 2000, Uiewera Ruirarchzatrea 2000, Millueradfa Software Foundry http://www.geocities.com/millueradfa millueradfa@yahoo.com You are free to use and redistribute, and modify this document however you wish, as long as the above headers, this text, and the below disclaimer remain intact and are located near the top of teh file. We do kindly request and ask that if you improve or modify this protocol document that you could do us teh favor of sending us a copy of the improved work. Also, if you improve the protocol in some software, please consider sending us some mail describing the improvements, and of course, software sources are always nice to have. /* * THIS DOCUMENT IS PROVIDED BY UIEWERA RUIRARCHZATREA, AND THE MILLUERADFA * SOFTWARE FOUNDRY (UR and MSF), AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE UIEWERA RUIRARCHZATREA OR THE * MILLUERADFA SOFTWARE FOUNDRY OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ -------------NOTICE-------------- If you are having troubel reading this document, I did not use returns to wrtap the lines. I prefer the editor to do that instead. Turn on soft line wrapping (or whatetever ist called), this is where the editor wraps the lines in your document automatically without returns. Introduction This protocol was created originally for the purpose of having a chat protocol where comnmands could be typed from a telent terminal in order to test the alogorithms and management, chat, im and such other functiosn of a chat server, specifically I am using it to test and check the capabilities of my TOE chat server, with telnet. It is possible that this protcol could also be used with cleints, however for those looking for a good, reliable, well developed protocol, I would highly recommend TOC instead of this. It has more features to assure reilability and is more "well cooked" and more effort was spent on a good design than this protocol. In fact, TOE is being created with the intention of excellent TOC support and recommend TOC as a higher choice than this protocol when you connect to TOE. This protocol is plain text and used over tcp/ip stream interfaces. There is one connection for each cleint server connection. /* ---Note---- A note on the the fomrat of the document, when we list commands, we are going to use parenthesis to indicate arguments which are optional. FOr instance, if we list and argument as hello:(howareyou,areyoufine), hello: can be followed by either one of those two, such as hello:howareyou or hello:areyoufine. Please not, that in the list of commands in this document, although we may not include the last end-cmd argument that should be in every command, but every command should end with with end-cmd, such as /command arg1 arg2 end-cmd. */ Coomand Format Comamnd are always preceded by a slash /. Immediately follwoing the slash is teh command name. Following the command by one space is a space seperate list of a argumenst/attrinutes to teh commands to the commands. Each command string is finnally terminated by and end-cmd or ec argument, this is spaced just like any other argument, yet it must be the last arguymnet always. Each comamnd must only inlcude alpahebetsic and numeric characters, and dashes. The sma egoes for each argument. although we may allow a few more characters in cases. Colons can be used to seperate an argument from a variable, such as color:red, but it is not limited to being used this way. With the arguemnts an exceptioon to which characters may be used is the text payload format argument as we will explain below, and that coloons may be used. Colons can be used to seperate an argument from a variable, such as color:red, but it is not limited to being used this way. Text format Payload Argument This is used to carry a block of text attached to an argument, the block of text may contain all sort of ASCII characters, spaces, etc. It is of the format: /* This is no longer used argument"Contained text" */ /* Use this now: */ argument[Contained Text] or argument:[Contained Text] All ASCII characters are valid withinn the square brackets, with the following exceptions: all square brackets and quotes and angle brackets in the users message must be represented by thier respective entitities. The angle brackets may only be used to surround HTML tags. Standard format for entities should be followed. &entitity;, and no spaces are required surrounding it. If it is not formed right or not recognized, it should be passed verbatim to the user. All spaces are included in the message to the user, unlike true html. It has been decided that it may be desiribel for the standard system of entity (". etc) format should be used rather than the system we described below. Each entity must be followed by a semicolon with no spaces between the semicolon and the entity, such as ", or it will not be recognized by the cleint as a quote, and thus sent verbatim to the user. As far as we can see, no spaces need to surround teh entity. So, if we wanted to send:'I said "hello" , and talked.', without the single quotes, it should be sent over the net as 'I said "hello" , and talked.' Even if the entity is formatted correctly, but not recognized by cleint, it should be sent verbatim to the user. /** The following few paragrpahs include a discusion of teh various problems and solutions found when implementing the chat protocol, but may not be nessecary readinmg and include discussiosn on solutiosn that were not implemented. As far as html goes and its angle brackets, I thought of whether all angle brackets included in a messsage by the user shall be sent using entities. This solves several problems, such as what would happen with quotes included in html tags. We woulodnt want those quoted being confused with the end of message quote. One alternativw would be to have clients use &quopte in the the html tags, the cleint at the other end, would recorgnize the "6e and know intereprete the html commands as if they were regaular quotes. Another possibility was simply to rely on the fact that hopefullyt cleint would recognize an html tag and its enclosing brackets, and would recognize the quotes in it not as an end of message, and that the sending cleint would not allow a ASCII quote to be sent unless it is contained within two angle brackets and is a properly formatted HTML tag. If we choose this, then the rule should be that even if the html tag isnt supported, it still must be noticed by the client and the cleint should assure the quotes in it are not interpreted as end of message, although the cleint if it doesnt recognize the html can then still send it verbatim to the user. */ This does bring us to an importnat rule that should be followed in any case, all html commands shall be enclosed in two angle brackets, immediately following the first bracket with no intervening spaces should be the html command. Following this, each seperated by one space, is each attribute, the attribute can carry a payload, the attribute comes first, than an equal sign, and then the payload. There should be no spaces between teh three or in the attribute, but within the quotes there may be spaces. There should be no space between the end of the last attribute and the angle bracket. An example: . In light of the troubles we discussed above, I have foudn that using quotes to contain the text format was a bad idea since would also be used as a protocol level demarcater in html tags. So, I have decided that maybe its a good idea to instead use brackets ([ ]) to contain teh payload. Since I have already written teh command examples in this document with quotes, It would take a lot of time to change it. So whenever you see quotes used to contain a payload, this should be read as brackets being used in thier place. This aviods the conflicts between quotes in HTML tags and the text payload demarcaters. Now we have another character that we must now represent with entities in the payloads, the brackets, and quotes still have to be represented in message text with entities, I think this will help ETOVP to be eisier to implement. New Text Payload Format: /command attribute1 attribute2:[Hello 123 website] ec If a cleint does not support an entity, it should pass it through verbatim to the user. If the user types in a recognized entity in thier message, the celint sh For instance. if teh user types in 'We have decided our protocol will use "', the cleint should send this as 'We have decided our protocol will use &quot;'. The last woudl then be rendered correctly as the user typed it in on the recieving end as '"'. This should be the defualt behaviour, however the cleint may implement special features wghich may be turned on by teh user, which will take all text and send it right over the exactly as they type it in. In fact as client could offer several modes of this, for instance, one where ony html commands are sent as the user types them, another that adds verbatim sending of entities. The cleint shall recognize and support &, ", and < and > (angle brackets), and &lsqb and &rsqb(square brackets). /* Some of the below information on quote codes is obsolete since we are using the standard format for entitities, &entity;, which need not be surrounded with spaces In order to facilitate the inclusion of quotes in the text payload, and to aviod confusion of the quotes surreounding the payload and quotes within the text playload, all text contained within the payload must use the &q438290 code, or ", to indicate a quoyte. This coomand must be seperated by at least one space. The cleinst should ignore the space immediately following and preceding the above code, in rendering text output to the user. So, for instance, if I wanted to something to be rendered 'I Said "Hello" to him' 9note that the singel quotes are not part of teh example), you would want your text sent out as this: 'I Said &q438290 Hello &q438290 to him' or 'I Said " Hello " to him'. Notice the double spaces on each outside side of the quote code. Since the cleinst on the other end will throw away one apce on each side of the code, if we want a space seperation we must add our additioanl spaces we want rendered to the output to the user in addition to the first one, since the first space on each side of teh code will be thrown away by the cleint before output to the user. Another example 'I was walking and said " Hello" .' This would be rendered as: 'I was walking and said &q438290 Hello &q438290 .' *or* 'I was walking and said " Hello " .' */ ALso, with this protocol, as many spaces as we wish are allowed in the text payload, and all will be interpreted and included in the output to the user except for the exception above in regards to the quote command. However, all carraige retiurns shall be ignored by the recieving cleint, in fact there reallyu shouldnt be any returns at all in the entire command text string. Instead, the client sjhall use HTML tage for tetx formatting and carriage returns, such as
, for a return, and so forth. In regards to html commands, the command shall only be intepretied as an html command if it is surrounded by angle brackets and of the format (and (and also the end tage with slash as well). Additionally, misformed or tags (the "htmltag" in the above example) are not supported by the cleint, the cleint shall pass them through to the output to the user. Clients shall also support the & character code. Differinatation from Server and Client Commands In this protocol, a server can send messages to teh cleint (server messages), and the cleint can send messages to the server. These are differeinated by the fact that cleint commands always are in lower case, and server commands always in uppercase. Please not, that only the command, and not the following atributes/arguments must follow this rule. Attributes/arguments may be case-sensitive. However, the last end-cmd attribute must always follow the differntiation by capatization rule, end-cmd for a cleint command, END-CMD for a server command. Please note that in this protocol if there is both a server and a client command with both the same name, they may be seperate coomands, be used in different ways, etc, but not nessacirely so. Many times the uppercase instance of a named command might be used to send response info in response to the lowercase instance of the named command, but this may vary from command to command, it doesnt have to be true, it depends on the implementation of the command. Examples: server command: /COMMAND atribute1:hello attribute-2:[hello there] END-CMD cleint command: /command atribute1:hello attribute-2:[hello there] end-cmd -or- server command: /COMMAND atribute1:hello attribute-2:[hello there] EC cleint command: /command atribute1:hello attribute-2:[hello there] ec Sign-On Seqaunce The following is a numbered list of the sequances of commands which must be exchanged in order to login the cleint to the server. Almost all commands for uploading buddy lists, etc., (basically everything but the commands which we mention in the sign-on sequance below) are done after the sign on sequance, they are normal commands which can be used at anytime. 1. Client sends to server /erpoumics start:ETOVP seqask:(yes/no) end-cmd. The client shall now wait until it recieves the repsonse to this command, /ERPOUMICS serverdomain*or*ip:port:portrange(x-x) "servername" serverversion "installationname" protocolversion END-CMD. Example: /ERPOUMICS 127.0.0.1:8001:8001-8001 [AcmeChatServer] 1.0 [A Good IM Service] 1.0 seqconf:(ok/nouse) END-CMD. 2. Once the cleint recives that command, the cleint then sends this command: /cleintinfo [cleintname] cleintversion protocolversion seq:0x1 end-cmd. In Response the server will send the /CLIENTINFO ok (seq:0x1) END-CMD command. 3. The cleint now sends the signon command: /so username (xor, clear):userpassword useripaddressordns:port (seq:0x2) end-cmd The client will now recieve the following command from the server: /SO username useripaddressordns:port result:[OK/ Logged In] rname:[Real Name] (seq:0x2) END-CMD At this piont the user is logged and now the clint may begin sending regular "any time" commands, and teh server can do the same. The cleint for instance can pull down its buddy list at anytime, or upload (store) at any time. It can also update the listen list at any time. The password can be xored or sent clear text, cleints chioce. If xor used, use, xor:password, or if clear, user clear:password. The process of xoring passords used in this protocol is the same as which used in the TOC protocol. Please refer to the TOC protocol document for info on roasting passwords. Sign-Off Sequence 1. First, the /signoff ourusername command issued by cleint. 2. The server sends the /SIGNOFF ourusername ok command. 3. The client shall not send any messages after receiving the above message. 4. The server wait one or twoseconds and drops teh connection. Commands /* ---NOTE---- I created this protocol witha long list of commands, how are some may be optional. At first, i may only implement the importnat commands, such as signon and im and chat communicatiosn commands. There are extra error commands for instance which may not need to be used on the server. There are more than one mode for the info service and for chat room ids, but only one may wish to be used at first. */ These are the commands used in the protocol. Arguments in parenthesis means there are several options. msg:(away, here), would indicate that either msg:away or msg:here would suffice. Arguments with (*opt) preceding them are optional. /erpoumics end-cmd This command tells the server that the cleint wishes to use the ERPOUMICS protocol The server will return the follwing server command: /ERPOUMICS serverdomain*or*ip:port*or*portrange(x-x) servername serverversion protocolversion END-CMD /cleintinfo cleintname cleintversion protocolversion end-cmd /bls list:"User1, User2, User3, User4, etc" end-cmd (Buddy List Status) Thsi command sends a list of any number of usernames to the server, this tells teh server the cleints wants status updates, such as the user logging on or off. /rmbls list:"User1, User2, User3, User4, etc" (Remove Buddy List Status) Remove users from the buddy list status list. /BLSUC user:"username1,useR namE2,etc." status:(away, present) idle:12345 logged:(in, off) END-CMD (Buddy List Status Update to Client) All arguments but the user and end-cmd are optional in a given message. /BLSUCLS user:"username1,UserName 2,etc" class:classid evil:100% os:"hh:mm:ss,MM/DD/YYYY,dayname" (U/A) (Buddy List Update Class Info) All arguments but the user and end-cmd are optional in a given message. The last argument is avialable or uavialable. os is online since. Classes etovs - Normal Etovs Protocol User etovs-ad - Etovs Admin etovs-u - Etovs Unavialable etovs-i - Etovs Ignore I havent decided if I am going to use this all the time. Should be included with the cleints cabailities, the server may not use them though. aol - AOL Online Service User aim - Normal TOC user aim-ad - TOC Admin aim-tr - TOC Trial aim-u - TOC Unavialable f - Normal Foreign user f-ad - Foreign Admin f-tr - Foriegn Trial f-u - Foreign Unavialable /blsu username ask:(status,logged) end-cmd (Buddy List Status Update) This command asks for status updtes on any user, does not nesscarily have to be on the listen list, the server will return the full list of status information requested from the cleint, although the server will give any notify the cleint of any applicable changes to a user as they happen, this allows the the status infor when it wants, and for users not on the listen list. If status is used, /BLSUC will be sent, if logged is used, /BLSUCLS will be sent. /!-- Ignore This, dont know how it got here This command follows the above ---/ /* The following coammnds send comamnd to store a buddy list onto the server so it will be rembered for when the user logs in next. This does not tell the server to send status updates or watch these users. /bls does that, however names sent by /bls will not be stored. This allows the cleint to control whether the users buddy list is stored on the server, on the users hard drive, or both. If the client wants to use list stored on the server on an erlier date, it gets the stored list by /abl, and then sends it back to server with /bls. */ /sbln list:"{Buddies}Username1,username2,etc" (Send Buddy List New) This erases an existing list. Client, do not use it automatically. /sbla list:"{Buddies}Username1{My Buddies}Username2,etc" (send Buddy List Add) /sblr list:"{Buddies}Username1,Username2,etc." (Send Buddy List Remove) /abl The cleint asks for its stored buddy list. /ABL list:"{Buddies}username1,UserName2{My Buddies}Username 3,username4,etc" See Above. /* on the following, two, ethier rem or add can be used, or both at the same time. */ UFWP, t /sdl add:"username1,username2,etc" rem:"username1,username2,etc" Set Deny List /spl add:"username1,username2,etc" rem:"username1,username2,etc" Set Permission List /spdm (da, ds, pa, ps) Set Permission/Deny mode da Deny all ds Deny some pa Permit all ps Permit some /sc plist:"username1,username2" dlist:"username1,username2" bl:"{Buddies}user1,user2{More buddies}user3,user4" dmode:(da,ds,pa,ps) Send all config in one coomand. /SC plist:"username1,username2" dlist:"username1,username2" bl:"{Buddies}user1,user2{More buddies}user3,user4" dmode:(da,ds,pa,ps) Same as above, to client. /rname user1 user2 user3 etc Ask server for the name of a user, if we wish ourselves, in the form of proper capatilization and spacing. /RNAME name:"User1,User2,USer3,etc" The response /sim ourusername destusername msg:"Hello, blah, blah, blah" end-cmd Send an IM to a user. /RIM senderusername ourusername msg:"Hello, How are you" END-CMD Server sends an IM to the client. /* The following commands are used for the cleint to access chat rooms. We are actually allowing the server two different modes of addressing the chat rooms, either with a toc style ID number or a the chatroom and exchnage. We included the ID option since that may ease adding this protocol to an existing TOC server. The server only needs to support one or the other, the cleint should support both. The other is simply using chat room names and exchanges in chat messages to tell which room the messages are going to/coming from. The server must support one of these methods, or a server may support both. Also, there is a third mode which the server accepts messages with both an id and name/exchnage, however the server internally may only wish to use one of those (id or name/ex) to route the message, even though the cleint includes both. The cleint, before entering the first chat room, must ask the server which method it uses with the /acm command. The client need not ask this more than once, it can just remember which method the server used, but the cleint can use /acm whenever it wants, indeed, before opening each chat room instead of remembering the result from teh first use of /acm. */ /acm /ACM (name-ex, id, nameexid) /ecr ourusername roomname exchangenum mode:"(name-ex, id, nameexid)" Last argument optional (mode). If not included the client is saying it wants name-ex mode. The server may include more than one supported mode, for instance mode:"name-ex, id". Tell the server we would like to enter a chatroom. /ECR ourusername roomname exchangenum stat:"(OK, RNA, UE, INS, NNS NINS)" mode:(name-ex, id, nameexid) id:(NU, 12345) admsg:"Anything can go here" Server tells us if we entered the chatroom ok. This sognals that the server is ready for the user to send messages with /scm and /scmw. RNA is "room not avialable. UE is unidentified error. INS is ID mode not supported, NNS, Name Mode not supported, Name/ID mode not supported. The id is for use with TOC style IDs. If NU is returned, the cleint may simply use the room name to send messages, otherwise, the ID must also be included. Note, on all chat communicatiosn commands, if ID mode is used by the server instead, use the id in place of destchatroom and use NU for exchange. id:12345 needs only be used in name-id (nameexid) mode, otherwise it should be id:NU or not included at all. /scm ourusername destchatroom destchatroomexchange msg:"hello, hello" Send a message to a chat room. /RCM roomname exchangenum ourusername msg:"hello hello" The server is sending us a message from the chat room. /scmw ourusername roomname exchangenum destusername msg:"hello, hello" Whsiper to one user in a chat room. /RCMW roomname exchangenum destusername ourusername msg:"hello, hello" Recieve a whsiper from one user in a chat room. /ci ourusername destusername chatroom exchange msg:"Come to my chat room" Invite a user to a chat room. msg is optional. /CI thiername ourname chatroom exchange msg:"Come to my chat room" The server sends the cleint an invite message from a user. /rl chatroom exchange Ask server for a list of users in a room. /RL chatroom exchange list:"user1,user2,user3,etc" Response to /rl /CRA chatroom exchange username Chat user add. This tells the client someone has entered teh room. Only send if the user has logged into the room. /CRR chatroom exchnage username Chat user remove. Someone has left the room. /lc ourusername chatroom chatexchnage Tell server we would like to leave a chatroom. /LC ok chatroom chatexchange Response. /LCSF chatroom chatexchange msg:"Optional message" The server tells us it is forcefully dropping us from a chat room. /time The cleint can send this to ask for the time. /TIME strng:"hh:mm:ss,MM/DD/YYYY,dayname" This is the respinse to /time. The client may do what it wishes with this, but the cleint could for instance create its own internel clock and calculate teh difference between the users system clock and the time returned by /TIME. We do not recoomend and greatly discourage a cleint from setting the users computer clock without permission, however the cleint may implement a feature which the user chooses to use to do so. /sdirinfo ourusername msg:"firstname:,lastname:,city:,state:,country:,age:,bdate.day:,bdate.month:,bdate.year:,computer:,os:," Send Directory Info /askdirinfo username /ASKDIRINFO username ourusername msg:"firstname:,lastname:,city:,state:,country:,age:,email:,bdate.day:,bdate.month:,bdate.year:,computer:,os:," /schdirinfo msg:"firstname:,lastname:,city:,state:,country:,age:,email:,bdate.day:,bdate.month:,bdate.year:,computer:,os:," /SCHDIRINFO sid:1234567 range:"1-10" msg:"username1,username2,username3,username4,etc." This returns a list of usernames which match. Range can be 1-10, 10-20, etc. sid is teh search ID. /getdirsl sid:1234567 range:"1-10" Returns /SCHDIRINFO. Get a certian part of the resultes list. /infotx ourusername info:"This is our info
We can include html too" Send our information to the server. /inforx ourusername thierusername Ask for info on a user /INFORX thierusername ourusername url:"http://www.123.com/32323124" The servers response with URL for users info. /inforawtxt ourusername thierusername This requests direct text instead of URL for info. /INFORAWTXT thierusername ourusername info:"Hello, this is my info" The text of the users info. /setmode (away, here, idle) idletimebegin This is to set the users current status. Idletimebegin is the idle time for the user. /askawaymsgmode This is to ask the server what away msg mode it uses. With cleint mode, the server doesnt store away messages but when it recives a request froma user for an away message it asks the cleint and forwards the cleints response to the requesting cleint. In server mode, the cleint will load its away message to the server and the server wills tore, so when a user asks for it, the server just gives what it has stored. /ASKAWAYMSGMODE (server, cleint, server-cleint) Response from the server with supported mode. Server-cleint mode means the server supports both and the cleint may choose. /setawaymsgmode (server, cleint) This should be supported by server even if it only supports one mode. The client, as long as it uses /askawaymsgmode first, does not have to send this if teh cleint supports only one mode, but it may choose to do so anyway. /SETAWAYMSGMODE (OK, NS) msg:"Any test here" The servers confimation. It returns OK if the mode was supported, or NS (not-supported) if the server does not support the mode requested. The msg is optional, but it may contain a message from the server that the cleint might wish to display to the user. /setawaymsg msg:"This is my away msg" This will only be recognized by the server if the away msg mode is set to server, and the server has been to server away msg mode. /* The following two commands are only used if the server is in cleint away msg mode */ /REQAWAYMSG This is the server asking the cleint for its away msg. Te cleint really shouldnt send /getawaymsg if the user is not in away mode, it should request the users current mode first. The server should only send this if it is in client away msg mode. /reqawaymsg status:(OK, NA) ourusername msg:"Hello, im away" This is the cleint returning it. If the client returning it to the server. The first argument tells the server OK, here is the message, or returns NA, which means not away, meaning the user is not away. If teh latter is used, the msg: argument need not be included. /* end client away mode commands */ /getawaymsg destuser This gets the users away message. Although the message may be returned by the cleint in an IM, the cleint should also sends its away message to the server as above. This way a user can get it without IMing. /GETAWAYMSG destuser msg:"This is my away message" /SERVERERROR msg:"errorcode#,arg%1,arg%2,etc" This command is used to send an error code to a user. The error code and arguments are the same as used in TOC, under the TOC ERROR command. Please consult the TOC protocol document for a list of the error codes. /* The following too are additioanl error command formats, servers chioce if it wants to use these */ /error cmd:"/COMMAND arg1 arg2" (UC, FE):"(all-cmd,arg1(arg2,arg3,arg4,etc)" errmsg:"Anything can go here" This is used primarily for the cleint to tell the server that the cleint does not support a particular command or implementation, that the server sent. UC is Unkown Command, FE is formattinge error. /ERROR cmd:"/command arg1 arg2" (UC, FE):"(all-cmd,arg1(arg2,arg3,arg4,etc)" errmsg:"Anything can go here" end-cmd This is used by the server to send a message to the cleint that a command the cleint sent is not supported. /pingsvr clocktime:"hh:mm:ss,MM/DD/YYYY" clienttime:"hh:mm:ss,MM/DD/YYYY" This is a ping command sent by the cleint to teh server. Clocktime is the time on the computers clock when the cleint sends the command. Client-time, however, is the time using the difference between the computers time and the time recieved from the time command. Both feilds are optional, but at least clocktime is recommended. /PINGSVR clocktime:"hh:mm:ss,MM/DD/YYYY" The response to /pingsvr, the above. /PINGCLNT clocktime:"hh:mm:ss,MM/DD/YYYY" This is a ping command sent from the server to client. /pingclnt clocktime:"hh:mm:ss,MM/DD/YYYY" clienttime:"hh:mm:ss,MM/DD/YYYY" This is the cleints response to /PINGCLNT /fortune (normal, offensive) Ask the server for a fortune. The server can implement this in many ways. It can run BSD fortune each time the users asks, or it may run it once a day or once a hour or whatever, store teh result and feed that to users who ask. BSD fortune doesnt have to be used, any other fortune can be sent, whatever the admin likes. Normal and offensive indicators tell the server if the user wants BSD fortunes offensive fortunes. This can also be applied to whatever fortune messages the admin wishes to use, or the admin can just disregard the offensie mode and use the same message for both modes. /FORTUNE msg:"The Fortune Text Goes Here" END-CMD The server may include, if it does not want to support fortune, any text in the message instead, such as "this feature is not supported" /BCAST msg:"This is a broadcast message to all users on the system" END-CMD Server Optional. /UMSG ourusername msg:"This is a message from the server/admin to specific user(s)" Server Optional. /HOLD Tells the cleint not to send any data until /END-HOLD is recieved. /END-HOLD (BO,WC) See above. BO is Begin Operation whiuch means the cleint may now begin operating normally and sending comamnds. WC, however tells the cleint to now wait for a few commands, and the cleint shall repsond to those comamnds. These commands will ussually the ones we will list below which ask the cleint to resend signon, buddy list, and other informatiom. Cleint shall not send new commands while in WC mode, only repsond to those sent by teh server in the proper way. /ENDWC If teh server sent /END-HOLD WC, then this tells the cleint to now begin normal operation and the servers interrogation is over. /SENDSO The server asks cleint to send the /so signon agian. This the only time the cleint may send it besides the sign-on sequance. /SENDSOSTAT (CO,RS) (ERR,OK) TEC msg:"Anything here, optional" CO- We will continue to the next request RS- Send it agian ERR- The was an error OK - everything was fine TEC - optional, TOC error code, see the TOC PROTOCOL doc, the TOC ERROR command If /SENDSOSTAT CO, the cleint shall wait for next request. The server shall not send a different request, till it has sent this. /SENDBL Send the buddy list info agian, such as /bls. /SENDBLSTAT (CO,RS) (ERR,OK) TEC msg:"Anything here, optional" CO- We will continue to the next request RS- Send it agian ERR- The was an error OK - everything was fine TEC - optional, TOC error code, see the TOC PROTOCOL doc, the TOC ERROR command If /SENDBLSTAT CO, the cleint shall wait for next request. The server shall not send a different request, till it has sent this. /SENDPD Send the Permit/Deny list and mode Agian. /SENDPDSTAT (CO,RS) (ERR,OK) TEC msg:"Anything here, optional" CO- We will continue to the next request RS- Send it agian ERR- The was an error OK - everything was fine TEC - optional, TOC error code, see the TOC PROTOCOL doc, the TOC ERROR command If /SENDPDSTAT CO, the cleint shall wait for next request. The server shall not send a different request, till it has sent this. /reqrvous destuser msg:"OPtional Msg" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" ourip:"123:123" Cleint asks for another cleints IP/port. Service is the service type that the cleint wanst to use with the recieving cleint. This is often used to send a file to a user. HTTPFTX indicates sending a file with http protocol, for instance. Ourip will be withheld till reciever accepts. /RVOUS id:12345 A Unique ID from the server to reference this rvous session, to requesting client. /ASKRVOUS sendinguser msg:"Optional msg (from /reqrvous)" service:"HTTPFTX"serviceargs:"123.wav,12345bytes" id:12345 Server asks receiving cleint. /askrvous (OK,DENY) ip:"123:123" msg:"Optional" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" id:12345 Cleint says Ok, with ip and port. /REQRVOUS destuser (OK, DENY) ip:"123:123" msg:"Optional, from /askrvous" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" id:12345 Server returns repsonse to sender. /RVOUSSENDERIP ip:"123:123: Send sender IP to reciever. /REQRVOUS and /RVOUSSENDERIP shall be simultanoeous (or nearly so) /* This may not really be necessary */ /rvousok destuser sendinguser ip:"123:123" msg:"Optional" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" id:12345 /RVOUSOKFS destuser sendinguser ip:"123:123" msg:"Optional" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" id:12345 Server sends the ok ask from the sending cleint. /rvousokfs OK destuser sendinguser ip:"123:123" msg:"Optional" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" id:12345 Client sends the ok. /RVOUSOK destuser sendinguser ip:"123:123" msg:"Optional" service:"HTTPFTX" serviceargs:"123.wav,12345bytes" id:12345 /* end may not really be nessacary */ /signoff ourusername The cleint sends this when it wants the server to disconnect it. AFter sending this, the cleint shall wait for the sign off command which shall come next. /SIGNOFF ourusername ok This is the servers response to /signoff. One or two seconds after this si sent the server will break the connection. /SERVERSIGNOFF ourusername interval msg:"You may give some text for the user here. This is optional" END-CMD Server Optional. This message is sent by teh server to tell the cleint that the server is disconnecting it. The cleint should send any more messages besides /serversignoff, if interval is 0. If interval is 0 the server will disconnect very shortly. However, if interval is another number, it is the number of seconds in which the server will allow the cleint to stay connected. If it is a number 1 or greater, the cleint should notify the user of the time remaining, and/or provide a count down. During the time specified by interval the cleint can send messages. The server should stop accepting commands three seconds after interval has elapsed, except the /serversignoff command. The cleint shall send the serversignoff command 1 second after interval has elapsed. Open recieving that message the server should break the connection for seconds later, or if the server does not recive /serversignoff in 10 seconds, it may break the connection. /serversignoff ourusername ok The cleinst response to teh above.