Protocols/TOC/1.0 - Revision history

Animadoria at 01:12, 28 December 2024

2024-12-28T01:12:08Z

← Older revision		Revision as of 01:12, 28 December 2024
Line 183:		Line 183:

	==== toc_rvous_propose ====		==== toc_rvous_propose ====
	'''Command Syntax''': <code>toc_rvous_propose</code>		'''Command Syntax''': <code>toc_rvous_propose <nick> <cookie> <service> <tlvlist></code>

	~~Syntax unknown~~, ~~or not implemented~~.		Sends a rendezvous proposal to the user <nick>. <cookie> is a 8-byte cookie (see [http://Protocols/OSCAR/Foodgroups/ICBM#Datatype:_Cookie ICBM Datatype: Cookie] that will be sent in the ICBM and in the propose message, base64 encoded. <service> is the UUID the proposal was for. <tlvlist> contains a list of tlv tags followed by base64 encoded values.

	==== toc_rvous_accept ====		==== toc_rvous_accept ====
Line 422:		Line 422:
	Working with the TOC protocol in C is only slightly harder then in a language that treats strings as first class object. Just create yourself some nice split and join routines like in perl. An even better method is to just link your application with perl or tcl, and use their routines to splits the strings into parts. The TOC server is written in C, for those of you who are curious.		Working with the TOC protocol in C is only slightly harder then in a language that treats strings as first class object. Just create yourself some nice split and join routines like in perl. An even better method is to just link your application with perl or tcl, and use their routines to splits the strings into parts. The TOC server is written in C, for those of you who are curious.

			'''Note''': The NINA TOC server isn't written in C.

	[[Category:AOL]]		[[Category:AOL]]

AD: Fixed name origin highlighting

2023-10-09T19:39:34Z

Fixed name origin highlighting

← Older revision		Revision as of 19:39, 9 October 2023
Line 17:		Line 17:

	-->		-->
	TOC ('''T'''alk to '''O'''s'''C'''ar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a [[Protocols/OSCAR/FLAP\|FLAP]] packet. As the data transmitted is string-based, it is referred to as SFLAP.		TOC ('''T'''alk t'''o''' Os'''C'''ar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a [[Protocols/OSCAR/FLAP\|FLAP]] packet. As the data transmitted is string-based, it is referred to as SFLAP.

	Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.		Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.

Animadoria at 12:30, 9 October 2023

2023-10-09T12:30:59Z

← Older revision		Revision as of 12:30, 9 October 2023
Line 1:		Line 1:
	{{Protocols/TOC}}		{{Protocols/TOC}}


	<!--		<!--

Line 19:		Line 17:

	-->		-->

	TOC ('''T'''alk to '''O'''s'''C'''ar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a [[Protocols/OSCAR/FLAP\|FLAP]] packet. As the data transmitted is string-based, it is referred to as SFLAP.		TOC ('''T'''alk to '''O'''s'''C'''ar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a [[Protocols/OSCAR/FLAP\|FLAP]] packet. As the data transmitted is string-based, it is referred to as SFLAP.

Animadoria: /* UPDATE_BUDDY */

2023-10-09T12:30:39Z

UPDATE_BUDDY

← Older revision		Revision as of 12:30, 9 October 2023
Line 247:		Line 247:
	This one command handles arrival/depart/updates. Evil Amount is a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class) is a two/three character string.		This one command handles arrival/depart/updates. Evil Amount is a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class) is a two/three character string.

	~~<pre>~~uc[0]</~~pre~~>		'''uc[0]'''<br/>
	* <code>' '</code> - Ignore		* <code>' '</code> - Ignore
	* <code>'A'</code> - On AOL		* <code>'A'</code> - On AOL
	* <pre>uc[1]</~~pre~~>
	<code>' '</code> - Ignore		'''uc[1]'''<br/>
			* <code>' '</code> - Ignore
	* <code>'A'</code> - Oscar Admin		* <code>'A'</code> - Oscar Admin
	* <code>'U'</code> - Oscar Unconfirmed		* <code>'U'</code> - Oscar Unconfirmed
	* <code>'O'</code> - Oscar Normal		* <code>'O'</code> - Oscar Normal
	~~<pre>~~uc[2]</~~pre~~>
			'''uc[2]'''<br/>
	* <code>'\0'</code> - Ignore		* <code>'\0'</code> - Ignore
	* <code>' '</code> - Ignore		* <code>' '</code> - Ignore

Animadoria: /* Server */

2023-10-09T12:29:57Z

Server

Show changes

Animadoria at 12:19, 9 October 2023

2023-10-09T12:19:30Z

Show changes

Animadoria at 11:46, 9 October 2023

2023-10-09T11:46:34Z

← Older revision		Revision as of 11:46, 9 October 2023
Line 65:		Line 65:

	* Client sends TOC toc_init_done message		* Client sends TOC toc_init_done message

			=== Sign-On Frame Type ===
			Sequence Number contains the initial sequence number used in each direction. Data Length contains the payload length, with the payload described below. The payload area is NOT null terminated.

			Host To Client:
			* 4 byte FLAP version (1)

			Client To Host:
			* 4 byte FLAP version (1)
			* 2 byte TLV Tag (1)
			* 2 byte Normalized User Name Length
			* N byte Normalized User Name (NOT null terminated)

	== FAQ ==		== FAQ ==

Animadoria at 11:45, 9 October 2023

2023-10-09T11:45:20Z

← Older revision		Revision as of 11:45, 9 October 2023
Line 23:		Line 23:

	Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.		Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.
			== Protocol ==
			The TOC protocol is ASCII based, and special attention must be placed argument separation. The separator and the rules of separation are different for messages inbound to TOC and outbound to the client. The rules of separation are described in sections below.

			The TOC server is built mainly to service the TIC and TiK clients. Since the TIC client is a Java applet, and downloadable, TOC will NOT support multiple TOC protocol versions at the same time. Therefore, TiK users will be forced to upgrade if the protocol version changes. TOC sends down the protocol version it expects the client to speak and understand. Note, the protocol version is a string.

			=== Important Notes ===
			* TOC will drop the connection if a command exceeds the maximum length, which is currently 2048 bytes. So the client needs to spend special attention to im, chat, and config message lengths. There is an 8k length maximum from TOC to the client.
			* No commands should be sent to TOC (besides toc_signon) before a SIGN_ON is received. If you do send a command before SIGN_ON the command will be ignored, and in some case the connection will be dropped.

			* Initial permit/deny items should be sent after receiving SIGN_ON but before sending toc_init_done, otherwise the user will flas on peoples buddylist who the user has denied. You will probably want to send the toc_add_buddies at this time also.

			* After TOC sends the PAUSE message to a client, all messages sent to TOC will be ignored, and in some cases the connection will be dropped. Another SIGN_ON message will be sent to the client when it is online again. The buddy list and permit/deny items must be sent again, followed by the toc_init_done. In most cases the SIGN_ON message will be sent between 1-2 seconds after the PAUSE message. Therefore a client could choose to ignore the PAUSE message and hope nothing bad happens.

			== Client ==

			The commands and the arguments are usually separated by whitespaces. Arguments with whitespace characters should be enclosed in quotes. Dollar signs, curly brackets, square brackets, parentheses, quotes, and backslashes must all be backslashed whether in quotes or not. It is usually a good idea just to use quotes no matter what. All user names from clients to TOC should be normalized (spaces removed and lowercased), and therefore are the one exception to the always use quotes rule.

			When sending commands to the server you will not get a response back confirming that the command format was correct or not! However in some cases if the command format was incorrect the connection will be dropped.

			== Server ==

			All user names from TOC to client are NOT normalized, and are sent as they should be displayed. String are NOT encoded, instead we use colons as separators. So that you can have colons inside of messages, everything after the colon before :<Message> should be considered part of the message (ie don't just "split" on colons, instead split with a max number of results.)

			== Typical Sign-on Process ==

			Except for the section marked optional this is an sequential process. Each line MUST occur before the following line.

			* Client connects to TOC
			* Client sends "FLAPON\r\n\r\n"
			* TOC sends Client FLAP SIGNON
			* Client sends TOC FLAP SIGNON
			* Client sends TOC "toc_signon" message
			* If login fails, TOC drops client's connection. If not, TOC sends client SIGN_ON reply
			* If Client doesn't support version it drops the connection

			'''[BEGIN OPTIONAL]'''
			* TOC sends Client CONFIG
			* Client sends TOC permit/deny stuff
			* Client sends TOC toc_add_buddy message
			'''[END OPTIONAL]'''

			* Client sends TOC toc_init_done message
	== FAQ ==		== FAQ ==

Animadoria at 11:39, 9 October 2023

2023-10-09T11:39:35Z

← Older revision		Revision as of 11:39, 9 October 2023
Line 19:		Line 19:

	-->		-->

			TOC ('''T'''alk to '''O'''s'''C'''ar) is a protocol, and a server which connects to the AIM service. At its core, the TOC protocol is string-based, and incapsulated in a [[Protocols/OSCAR/FLAP\|FLAP]] packet. As the data transmitted is string-based, it is referred to as SFLAP.

			Compared to OSCAR, TOC is more simple, however it is not as flexible and doesn't contain all the features of OSCAR. It does, however, contain the essential features to communicate with the AIM service: IMs, Chat rooms, Warnings, and Privacy Management.


			== FAQ ==

			This FAQ was originally created by AOL, and is written verbatim. The NINA team has added some notes at the bottom of each answer.

			=== What does TOC stand for? ===
			TOC, pronounced /talk/, currently stands for TOC to OsCar for lack of a better acronym. Really it just has to do with the members of the TicToc project obsession with useless 3 letter meaningless words. Since TOC is just a proxy protocol, it kind of makes sense.

			'''Note''': TOC means "Talk to OSCAR", not "TOC to OSCAR".

			=== How does the TOC protocol differ from the OSCAR protocol? ===
			The TOC and the OSCAR protocol are very different. The TOC protocol is a high level abstraction of the OSCAR protocol. The TOC protocol is entirely string based while the OSCAR protocol is binary based. Since the TOC protocol is entirely string based there are NO network byte ordering problems, while the OSCAR protocol will require careful packaging of data. (This is excluding the 6 byte FLAP transport layer header, used by both TOC and OSCAR, and will require network byte ordering.) Finally, the TOC protocol is currently the only one officially released and documented.

			At the protocol level currently there is nothing in TOC that isn't in OSCAR. However there are things in the OSCAR protocol that are not in TOC. For example TOC will probably never support directory look up, password changing, or other non "core" features. Obviously this translates to the TIC/TiK clients vs AIM clients.

			Are there benefits to the TOC protocol vs OSCAR protocol? Well not really, except TOC is extremely easy to work with, and it is at least public. Once you create your OSCAR/TOC independent FLAP layer you don't have to worry about network byte ordering with TOC, which makes portability much simpler. String termination can still lead to memory issues, but a good split routine will solve that problem.

			'''Note''': Ironically enough, TOC does support directory look up and password changing.

			=== What is FLAP? ===
			FLAP is a low-level communications protocol that facilitates the development of higher-level, record-oriented, communications layers. It is used on the TCP connection between all clients and servers. TOC adds a few extra requirements to TOC which are documented in the PROTOCOL file.

			'''Note''': Check [[Protocols/OSCAR/FLAP\|FLAP]] for more thorough information.

			=== Where can I get more information on the TOC Protocol? ===
			Download TiK and look in the PROTOCOL file included. TiK should always contain the latest PROTOCOL file, since the maintainer of TiK also maintains the PROTOCOL document. Most of the protocol and the ordering of messages is documented in this file. For support send your questions to the tictoc-users mailing list.

			=== But strings in C are ...? ===
			Many folks think working with strings in C is hard, inefficient, cpu intensive, buggy. While there are some gotchas to worry about, in most cases this is simply not true.

			Working with the TOC protocol in C is only slightly harder then in a language that treats strings as first class object. Just create yourself some nice split and join routines like in perl. An even better method is to just link your application with perl or tcl, and use their routines to splits the strings into parts. The TOC server is written in C, for those of you who are curious.

AD at 10:58, 11 February 2021

2021-02-11T10:58:45Z

← Older revision	Revision as of 10:58, 11 February 2021
Line 2:	Line 2:


		<!--


		toc_get_status <screenname>

		This useful command wasn't ever really documented. It returns either an UPDATE_BUDDY message or an ERROR message depending on whether or not the guy appears to be online.



		Misc TOC notes:

		If you connect with an empty buddy list, other people can't see you online. You can work around this by simply sending "toc_add_buddy a" if the user's buddy list is empty. This has been corrected in TOC2.0.

		In TOC1.0 there is a toc_add_deny command, but no toc_remove_deny. In order to remove people from your block list, you need to send a "toc_add_permit" command and then send your entire deny list without the screenname you want to unblock. Reverse the deny and permit commands if you want to add someone to your permit list. Again, TOC2.0 fixes this.


		-->