comparison doc/PROTOCOL @ 141:f90b022235fe

[gaim-migrate @ 151] Updates to the FAQ (there's been a few changes since 0.9.5), and found a new (and presumably the last, since AOL stopped publishing it) copy of the protocol. committer: Tailor Script <[e-mail]>

140:436bead8f65d

# Note from Jim Duchek, gaim maintainer -- this may not be the latest
# version of this document, I provide it as a service.  Download a copy
# of TiK (http://www.aim.aol.com/tik/) for the latest version of this
# doc.

Version: TOC1.0

This document describes the protocol between TOC and TOC clients.
The protocol is built on TCP.  Framing is done by SFLAP,
described at the bottom of this document.  Inside each

    mode first.  With no arguments and in deny mode
    this will switch you to permit none. If already
    in permit mode, no arguments does nothing
    and your permit list remains the same.

toc_add_deny [ <User 1> [<User 2> [... ]]]
    ADD the following people to your deny mode. If
    you are in permit mode it will switch you to
    deny mode first.  With no arguments and in permit
    mode, this will switch you to deny none. If
    already in deny mode, no arguments does nothing

    Set idle information. If <idle secs> is 0 then the user isn't idle at all.
    If <idle secs> is greater then 0 then the user has already been idle
    for <idle secs> number of seconds.  The server will automatically
    keep incrementing this number, so do not repeatedly call with new
    idle times.


TOC -> Client
==============
All user names from TOC to client are NOT normalized, and are

   * General Errors *
   901   - $1 not currently available
   902   - Warning of $1 not currently available
   903   - A message has been dropped, you are exceeding
	   the server speed limit
   * Chat Errors  *
   950   - Chat in $1 is unavailable.

   * IM & Info Errors *
   960   - You are sending message too fast to $1

GOTO_URL:<Window Name>:<Url>
   Goto a URL.  Window Name is the suggested internal name of the window
   to use.  (Java supports this.) 

DIR_STATUS:<Return Code>
   

PAUSE
   Tells TIC to pause so we can do migration

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

141:f90b022235fe

# Note from Jim Duchek, gaim maintainer -- this may not be the latest
# version of this document, I provide it as a service.  Download a copy
# of TiK (http://www.aim.aol.com/tik/) for the latest version of this
# doc.

# Note from Eric Warmenhoven, random guy -- this appears to be the last
# published version of the protocol, and AOL has stopped hosting the TiK
# program. This was taken from the last version of TiK I could find, version
# 0.75.

Version: TOC1.0

This document describes the protocol between TOC and TOC clients.
The protocol is built on TCP.  Framing is done by SFLAP,
described at the bottom of this document.  Inside each

    mode first.  With no arguments and in deny mode
    this will switch you to permit none. If already
    in permit mode, no arguments does nothing
    and your permit list remains the same.

toc_add_deny [ <User 1> [<User 2> [...]]]
    ADD the following people to your deny mode. If
    you are in permit mode it will switch you to
    deny mode first.  With no arguments and in permit
    mode, this will switch you to deny none. If
    already in deny mode, no arguments does nothing

    Set idle information. If <idle secs> is 0 then the user isn't idle at all.
    If <idle secs> is greater then 0 then the user has already been idle
    for <idle secs> number of seconds.  The server will automatically
    keep incrementing this number, so do not repeatedly call with new
    idle times.

toc_set_caps [ <Capability 1> [<Capability 2> [...]]]
    Set my capabilities.  All capabilities that we support need to
    be sent at the same time.  Capabilities are represented by
    UUIDs.  

toc_rvous_propose  - Not Implemented Yet

toc_rvous_accept <nick> <cookie> <service> <tlvlist>
    Accept a rendezvous proposal from the user <nick>.
    <cookie> is the cookie from the RVOUS_PROPOSE
    message.  <service> is the UUID the proposal was
    for. <tlvlist> contains a list of tlv tags followed by
    base64 encoded values.

toc_rvous_cancel <nick> <cookie> <service> <tlvlist>
    Cancel a rendezvous proposal from the user <nick>.
    <cookie> is the cookie from the RVOUS_PROPOSE
    message.  <service> is the UUID the proposal was
    for. <tlvlist> contains a list of tlv tags followed by
    base64 encoded values.

toc_format_nickname <new_format>
    Reformat a user's nickname.  An ADMIN_NICK_STATUS or ERROR message will 
    be sent back to the client.

toc_change_passwd <existing_passwd new_passwd>
    Change a user's password.  An ADMIN_PASSWD_STATUS or ERROR message will 
    be sent back to the client.


TOC -> Client
==============
All user names from TOC to client are NOT normalized, and are

   * General Errors *
   901   - $1 not currently available
   902   - Warning of $1 not currently available
   903   - A message has been dropped, you are exceeding
	   the server speed limit

   * Admin Errors  *
   911   - Error validating input
   912   - Invalid account
   913   - Error encountered while processing request
   914   - Service unavailable

   * Chat Errors  *
   950   - Chat in $1 is unavailable.

   * IM & Info Errors *
   960   - You are sending message too fast to $1

GOTO_URL:<Window Name>:<Url>
   Goto a URL.  Window Name is the suggested internal name of the window
   to use.  (Java supports this.) 

DIR_STATUS:<Return Code>:<Optional args>
   <Return Code> is always 0 for success status.

ADMIN_NICK_STATUS:<Return Code>:<Optional args>
   <Return Code> is always 0 for success status.

ADMIN_PASSWD_STATUS:<Return Code>:<Optional args>
   <Return Code> is always 0 for success status.
   

PAUSE
   Tells TIC to pause so we can do migration

RVOUS_PROPOSE:<user>:<uuid>:<cookie>:<seq>:<rip>:<pip>:<vip>:<port>
              [:tlv tag1:tlv value1[:tlv tag2:tlv value2[:...]]]
   Another user has proposed that we rendezvous with them to
   perform the service specified by <uuid>.  They want us
   to connect to them, we have their rendezvous ip, their 
   proposer_ip, and their verified_ip. The tlv values are 
   base64 encoded.

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