comparison: libgaim/protocols/toc/PROTOCOL
libgaim/protocols/toc/PROTOCOL
- branch
- cpw.khc.msnp14
- changeset 20472
- 6a6d2ef151e6
- parent 2285
- a84919d96fe8
- parent 14254
- 77edc7a6191a
- child 20471
- 1966704b3e42
equal
deleted
inserted
replaced
| 13912:463b4fa9f067 | 20472:6a6d2ef151e6 |
|---|---|
| 1 # Copyright (c) 1998-9 America Online, Inc. All Rights Reserved. | |
| 2 # | |
| 3 # This program is free software; you can redistribute it and/or | |
| 4 # modify it under the terms of the GNU General Public License | |
| 5 # as published by the Free Software Foundation; either version 2 | |
| 6 # of the License, or (at your option) any later version. | |
| 7 # | |
| 8 # This program is distributed in the hope that it will be useful, | |
| 9 # but WITHOUT ANY WARRANTY; without even the implied warranty of | |
| 10 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
| 11 # GNU General Public License for more details. | |
| 12 # | |
| 13 # You should have received a copy of the GNU General Public License | |
| 14 # along with this program; if not, write to the Free Software | |
| 15 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | |
| 16 | |
| 17 # Note from Jim Duchek, gaim maintainer -- this may not be the latest | |
| 18 # version of this document, I provide it as a service. Download a copy | |
| 19 # of TiK (http://www.aim.aol.com/tik/) for the latest version of this | |
| 20 # doc. | |
| 21 | |
| 22 # Note from Eric Warmenhoven, random guy -- this appears to be the last | |
| 23 # published version of the protocol, and AOL has stopped hosting the TiK | |
| 24 # program. TiK is still being maintained and is hosted on sourceforge.net; | |
| 25 # this appears to be the same version of the protocol they're using. | |
| 26 | |
| 27 Version: TOC1.0 | |
| 28 | |
| 29 This document describes the protocol between TOC and TOC clients. | |
| 30 The protocol is built on TCP. Framing is done by SFLAP, | |
| 31 described at the bottom of this document. Inside each | |
| 32 SFLAP frame is a TOC command. | |
| 33 | |
| 34 The TOC protocol is ASCII based, and special attention | |
| 35 must be placed argument separation. The separator and | |
| 36 the rules of separation are different for messages inbound | |
| 37 to TOC and outbound to the client. The rules of separation | |
| 38 are described in sections below. | |
| 39 | |
| 40 The TOC server is built mainly to service the TIC and TiK clients. Since | |
| 41 the TIC client is a Java applet, and downloadable, TOC will NOT support | |
| 42 multiple TOC protocol versions at the same time. Therefore, TiK | |
| 43 users will be forced to upgrade if the protocol version changes. | |
| 44 TOC sends down the protocol version it expects the client | |
| 45 to speak and understand. Note, the protocol version is a string. | |
| 46 | |
| 47 Important Notes | |
| 48 =============== | |
| 49 * TOC will drop the connection if a command exceeds the maximum | |
| 50 length, which is currently 2048 bytes. So the client needs to | |
| 51 spend special attention to im, chat, and config message lengths. | |
| 52 There is an 8k length maximum from TOC to the client. | |
| 53 | |
| 54 * No commands should be sent to TOC (besides toc_signon) before | |
| 55 a SIGN_ON is received. If you do send a command before SIGN_ON | |
| 56 the command will be ignored, and in some case the connection | |
| 57 will be dropped. | |
| 58 | |
| 59 * Initial permit/deny items should be sent after receiving SIGN_ON | |
| 60 but before sending toc_init_done, otherwise the user will flash | |
| 61 on peoples buddylist who the user has denied. You will probably | |
| 62 want to send the toc_add_buddies at this time also. | |
| 63 | |
| 64 * After TOC sends the PAUSE message to a client, all messages sent | |
| 65 to TOC will be ignored, and in some cases the connection will | |
| 66 be dropped. Another SIGN_ON message will be sent to the client | |
| 67 when it is online again. The buddy list and permit/deny items must | |
| 68 be sent again, followed by the toc_init_done. In most cases the | |
| 69 SIGN_ON message will be sent between 1-2 seconds after the | |
| 70 PAUSE message. Therefore a client could choose to ignore the | |
| 71 PAUSE message and hope nothing bad happens. | |
| 72 | |
| 73 | |
| 74 Client -> TOC | |
| 75 ============== | |
| 76 The commands and the arguments are usually separated by whitespaces. Arguments | |
| 77 with whitespace characters should be enclosed in quotes. Dollar signs, | |
| 78 curly brackets, square brackets, parentheses, quotes, and backslashes | |
| 79 must all be backslashed whether in quotes or not. It is usually | |
| 80 a good idea just to use quotes no matter what. All user names from clients | |
| 81 to TOC should be normalized (spaces removed and lowercased), and therefore | |
| 82 are the one exception to the always use quotes rule. | |
| 83 | |
| 84 When sending commands to the server you will not get a response | |
| 85 back confirming that the command format was correct or not! However | |
| 86 in some cases if the command format was incorrect the connection | |
| 87 will be dropped. | |
| 88 | |
| 89 | |
| 90 RoastingString="Tic/Toc" | |
| 91 | |
| 92 toc_signon <authorizer host> <authorizer port> <User Name> <Password> | |
| 93 <language> <version> | |
| 94 The password needs to be roasted with the Roasting String if | |
| 95 coming over a FLAP connection, CP connections don't use | |
| 96 roasted passwords. The language specified will be used | |
| 97 when generating web pages, such as the get info pages. | |
| 98 Currently the only supported language is "english". | |
| 99 If the language sent isn't found, the default "english" | |
| 100 language will be used. The version string will be used | |
| 101 for the client identity, and must be less then 50 | |
| 102 characters. | |
| 103 | |
| 104 Passwords are roasted when sent to the host. This is done so they | |
| 105 aren't sent in "clear text" over the wire, although they are still | |
| 106 trivial to decode. Roasting is performed by first xoring each byte | |
| 107 in the password with the equivalent modulo byte in the roasting | |
| 108 string. The result is then converted to ascii hex, and prepended | |
| 109 with "0x". So for example the password "password" roasts to | |
| 110 "0x2408105c23001130" | |
| 111 | |
| 112 toc_init_done | |
| 113 Tells TOC that we are ready to go online. TOC clients should first | |
| 114 send TOC the buddy list and any permit/deny lists. However toc_init_done | |
| 115 must be called within 30 seconds after toc_signon, or the connection | |
| 116 will be dropped. Remember, it can't be called until after the SIGN_ON | |
| 117 message is received. Calling this before or multiple times after a | |
| 118 SIGN_ON will cause the connection to be dropped. | |
| 119 | |
| 120 toc_send_im <Destination User> <Message> [auto] | |
| 121 Send a message to a remote user. Remember to quote and encode the | |
| 122 message. If the optional string "auto" is the last argument, then the | |
| 123 auto response flag will be turned on for the im. | |
| 124 | |
| 125 toc_add_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] | |
| 126 Add buddies to your buddy list. This does not change your | |
| 127 saved config. | |
| 128 | |
| 129 toc_remove_buddy <Buddy User 1> [<Buddy User2> [<Buddy User 3> [...]]] | |
| 130 Remove buddies from your buddy list. This does not change your | |
| 131 saved config. | |
| 132 | |
| 133 toc_set_config <Config Info> | |
| 134 Set the config information for this user. The config information | |
| 135 is line oriented with the first character being the item type, | |
| 136 followed by a space, with the rest of the line being the item | |
| 137 value. Only letters, numbers, and spaces should be used. Remember | |
| 138 you will have to enclose the entire config in quotes. | |
| 139 | |
| 140 Item Types: | |
| 141 g - Buddy Group (All Buddies until the next g or the end of config | |
| 142 are in this group.) | |
| 143 b - A Buddy | |
| 144 p - Person on permit list | |
| 145 d - Person on deny list | |
| 146 m - Permit/Deny Mode. Possible values are | |
| 147 1 - Permit All | |
| 148 2 - Deny All | |
| 149 3 - Permit Some | |
| 150 4 - Deny Some | |
| 151 | |
| 152 toc_evil <User> <norm|anon> | |
| 153 Evil/Warn someone else. The 2nd argument is either the string | |
| 154 "norm" for a normal warning, or "anon" for an anonymous | |
| 155 warning. You can only evil people who have recently sent you | |
| 156 ims. The higher someones evil level, the slower they can | |
| 157 send message. | |
| 158 | |
| 159 toc_add_permit [ <User 1> [<User 2> [...]]] | |
| 160 ADD the following people to your permit mode. If | |
| 161 you are in deny mode it will switch you to permit | |
| 162 mode first. With no arguments and in deny mode | |
| 163 this will switch you to permit none. If already | |
| 164 in permit mode, no arguments does nothing | |
| 165 and your permit list remains the same. | |
| 166 | |
| 167 toc_add_deny [ <User 1> [<User 2> [...]]] | |
| 168 ADD the following people to your deny mode. If | |
| 169 you are in permit mode it will switch you to | |
| 170 deny mode first. With no arguments and in permit | |
| 171 mode, this will switch you to deny none. If | |
| 172 already in deny mode, no arguments does nothing | |
| 173 and your deny list remains unchanged. | |
| 174 | |
| 175 toc_chat_join <Exchange> <Chat Room Name> | |
| 176 Join a chat room in the given exchange. Exchange is | |
| 177 an integer that represents a group of chat rooms. | |
| 178 Different exchanges have different properties. For | |
| 179 example some exchanges might have room replication (ie | |
| 180 a room never fills up, there are just multiple | |
| 181 instances.) and some exchanges might have navigational | |
| 182 information, and some exchanges might have ... Currently | |
| 183 exchange should always be 4, however this may | |
| 184 change in the future. You will either | |
| 185 receive an ERROR if the room couldn't be joined | |
| 186 or a CHAT_JOIN message. The Chat Room Name | |
| 187 is case insensitive and consecutive spaces | |
| 188 are removed. | |
| 189 | |
| 190 toc_chat_send <Chat Room ID> <Message> | |
| 191 Send a message in a chat room using the chat room | |
| 192 id from CHAT_JOIN. Since reflection is always on in | |
| 193 TOC, you do not need to add the message to your chat UI, | |
| 194 since you will get a CHAT_IN with the message. | |
| 195 Remember to quote and encode the message. | |
| 196 | |
| 197 toc_chat_whisper <Chat Room ID> <dst_user> <Message> | |
| 198 Send a message in a chat room using the chat room | |
| 199 id from CHAT_JOIN. This message is directed at | |
| 200 only one person. (Currently you DO need to add this to | |
| 201 your UI.) Remember to quote and encode the message. | |
| 202 Chat whispering is different from IMs since it is linked | |
| 203 to a chat room, and should usually be displayed in the chat | |
| 204 room UI. | |
| 205 | |
| 206 toc_chat_evil <Chat Room ID> <User> <norm|anon> | |
| 207 Evil/Warn someone else inside a chat room. The 3rd argument is either | |
| 208 the string "norm" for a normal warning, or "anon" for an anonymous | |
| 209 warning. Currently chat evil is not turned on in the chat complex. | |
| 210 | |
| 211 toc_chat_invite <Chat Room ID> <Invite Msg> <buddy1> [<buddy2> [<buddy3> [...]]] | |
| 212 Once you are inside a chat room you can invite other people into | |
| 213 that room. Remember to quote and encode the invite message. | |
| 214 | |
| 215 toc_chat_leave <Chat Room ID> | |
| 216 Leave the chat room. | |
| 217 | |
| 218 toc_chat_accept <Chat Room ID> | |
| 219 Accept a CHAT_INVITE message from TOC. The server will send a | |
| 220 CHAT_JOIN in response. | |
| 221 | |
| 222 toc_get_info <username> | |
| 223 Gets a user's info a GOTO_URL or ERROR message will be sent back to the | |
| 224 client. | |
| 225 | |
| 226 toc_set_info <info information> | |
| 227 Set the LOCATE user information. This is basic HTML. | |
| 228 Remember to encode the info. | |
| 229 | |
| 230 toc_set_away [<away message>] | |
| 231 if the away message is present, then the unavailable | |
| 232 status flag is set for the user. If the away message | |
| 233 is not present, then the unavailable status flag is | |
| 234 unset. The away message is basic HTML, remember to | |
| 235 encode the information. | |
| 236 | |
| 237 toc_get_dir <username> | |
| 238 Gets a user's dir info a GOTO_URL or ERROR message will be sent back to the | |
| 239 client. | |
| 240 | |
| 241 toc_set_dir <info information> | |
| 242 Set the DIR user information. This is a colon separated fields as in: | |
| 243 "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email":"allow web searches" | |
| 244 Should return a DIR_STATUS msg. Having anything in the "allow web searches" | |
| 245 field allows people to use web-searches to find your directory info. | |
| 246 Otherwise, they'd have to use the client. | |
| 247 | |
| 248 toc_dir_search <info information> | |
| 249 Perform a search of the Oscar Directory, using colon separated fields as in: | |
| 250 "first name":"middle name":"last name":"maiden name":"city":"state":"country":"email" | |
| 251 Returns either a GOTO_URL or ERROR msg. | |
| 252 | |
| 253 toc_set_idle <idle secs> | |
| 254 Set idle information. If <idle secs> is 0 then the user isn't idle at all. | |
| 255 If <idle secs> is greater then 0 then the user has already been idle | |
| 256 for <idle secs> number of seconds. The server will automatically | |
| 257 keep incrementing this number, so do not repeatedly call with new | |
| 258 idle times. | |
| 259 | |
| 260 toc_set_caps [ <Capability 1> [<Capability 2> [...]]] | |
| 261 Set my capabilities. All capabilities that we support need to | |
| 262 be sent at the same time. Capabilities are represented by | |
| 263 UUIDs. | |
| 264 | |
| 265 toc_rvous_propose - Not Implemented Yet | |
| 266 | |
| 267 toc_rvous_accept <nick> <cookie> <service> <tlvlist> | |
| 268 Accept a rendezvous proposal from the user <nick>. | |
| 269 <cookie> is the cookie from the RVOUS_PROPOSE | |
| 270 message. <service> is the UUID the proposal was | |
| 271 for. <tlvlist> contains a list of tlv tags followed by | |
| 272 base64 encoded values. | |
| 273 | |
| 274 toc_rvous_cancel <nick> <cookie> <service> <tlvlist> | |
| 275 Cancel a rendezvous proposal from the user <nick>. | |
| 276 <cookie> is the cookie from the RVOUS_PROPOSE | |
| 277 message. <service> is the UUID the proposal was | |
| 278 for. <tlvlist> contains a list of tlv tags followed by | |
| 279 base64 encoded values. | |
| 280 | |
| 281 toc_format_nickname <new_format> | |
| 282 Reformat a user's nickname. An ADMIN_NICK_STATUS or ERROR message will | |
| 283 be sent back to the client. | |
| 284 | |
| 285 toc_change_passwd <existing_passwd new_passwd> | |
| 286 Change a user's password. An ADMIN_PASSWD_STATUS or ERROR message will | |
| 287 be sent back to the client. | |
| 288 | |
| 289 | |
| 290 TOC -> Client | |
| 291 ============== | |
| 292 All user names from TOC to client are NOT normalized, and are | |
| 293 sent as they should be displayed. String are NOT encoded, instead | |
| 294 we use colons as separators. So that you can have colons inside | |
| 295 of messages, everything after the colon before :<Message> should | |
| 296 be considered part of the message (ie don't just "split" on colons, | |
| 297 instead split with a max number of results.) | |
| 298 | |
| 299 | |
| 300 SIGN_ON:<Client Version Supported> | |
| 301 This is sent after a successful toc_signon command is sent to TOC. | |
| 302 If the command was unsuccessful either the FLAP connection will | |
| 303 be dropped or you will receive a ERROR message. | |
| 304 | |
| 305 CONFIG:<config> | |
| 306 A user's config. Config can be empty in which case the host was not able to | |
| 307 retrieve it, or a config didn't exist for the user. See toc_set_config | |
| 308 above for the format. | |
| 309 | |
| 310 NICK:<Nickname> | |
| 311 Tells you your correct nickname (ie how it should be capitalized and | |
| 312 spacing) | |
| 313 | |
| 314 IM_IN:<Source User>:<Auto Response T/F?>:<Message> | |
| 315 Receive an IM from some one. Everything after the third colon is | |
| 316 the incoming message, including other colons. | |
| 317 | |
| 318 UPDATE_BUDDY:<Buddy User>:<Online? T/F>:<Evil Amount>:<Signon Time>:<IdleTime>:<UC> | |
| 319 This one command handles arrival/depart/updates. Evil Amount is | |
| 320 a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class) | |
| 321 is a two/three character string. | |
| 322 uc[0]: | |
| 323 ' ' - Ignore | |
| 324 'A' - On AOL | |
| 325 uc[1] | |
| 326 ' ' - Ignore | |
| 327 'A' - Oscar Admin | |
| 328 'U' - Oscar Unconfirmed | |
| 329 'O' - Oscar Normal | |
| 330 uc[2] | |
| 331 '\0' - Ignore | |
| 332 ' ' - Ignore | |
| 333 'U' - The user has set their unavailable flag. | |
| 334 | |
| 335 | |
| 336 | |
| 337 ERROR:<Error Code>:Var args | |
| 338 * General Errors * | |
| 339 901 - $1 not currently available | |
| 340 902 - Warning of $1 not currently available | |
| 341 903 - A message has been dropped, you are exceeding | |
| 342 the server speed limit | |
| 343 | |
| 344 * Admin Errors * | |
| 345 911 - Error validating input | |
| 346 912 - Invalid account | |
| 347 913 - Error encountered while processing request | |
| 348 914 - Service unavailable | |
| 349 | |
| 350 * Chat Errors * | |
| 351 950 - Chat in $1 is unavailable. | |
| 352 | |
| 353 * IM & Info Errors * | |
| 354 960 - You are sending message too fast to $1 | |
| 355 961 - You missed an im from $1 because it was too big. | |
| 356 962 - You missed an im from $1 because it was sent too fast. | |
| 357 | |
| 358 * Dir Errors * | |
| 359 970 - Failure | |
| 360 971 - Too many matches | |
| 361 972 - Need more qualifiers | |
| 362 973 - Dir service temporarily unavailable | |
| 363 974 - Email lookup restricted | |
| 364 975 - Keyword Ignored | |
| 365 976 - No Keywords | |
| 366 977 - Language not supported | |
| 367 978 - Country not supported | |
| 368 979 - Failure unknown $1 | |
| 369 | |
| 370 * Auth errors * | |
| 371 980 - Incorrect nickname or password. | |
| 372 981 - The service is temporarily unavailable. | |
| 373 982 - Your warning level is currently too high to sign on. | |
| 374 983 - You have been connecting and | |
| 375 disconnecting too frequently. Wait 10 minutes and try again. | |
| 376 If you continue to try, you will need to wait even longer. | |
| 377 989 - An unknown signon error has occurred $1 | |
| 378 | |
| 379 | |
| 380 EVILED:<new evil>:<name of eviler, blank if anonymous> | |
| 381 The user was just eviled. | |
| 382 | |
| 383 CHAT_JOIN:<Chat Room Id>:<Chat Room Name> | |
| 384 We were able to join this chat room. The Chat Room Id is | |
| 385 internal to TOC. | |
| 386 | |
| 387 CHAT_IN:<Chat Room Id>:<Source User>:<Whisper? T/F>:<Message> | |
| 388 A chat message was sent in a chat room. | |
| 389 | |
| 390 CHAT_UPDATE_BUDDY:<Chat Room Id>:<Inside? T/F>:<User 1>:<User 2>... | |
| 391 This one command handles arrival/departs from a chat room. The | |
| 392 very first message of this type for each chat room contains the | |
| 393 users already in the room. | |
| 394 | |
| 395 CHAT_INVITE:<Chat Room Name>:<Chat Room Id>:<Invite Sender>:<Message> | |
| 396 We are being invited to a chat room. | |
| 397 | |
| 398 CHAT_LEFT:<Chat Room Id> | |
| 399 Tells tic connection to chat room has been dropped | |
| 400 | |
| 401 GOTO_URL:<Window Name>:<Url> | |
| 402 Goto a URL. Window Name is the suggested internal name of the window | |
| 403 to use. (Java supports this.) | |
| 404 | |
| 405 DIR_STATUS:<Return Code>:<Optional args> | |
| 406 <Return Code> is always 0 for success status. | |
| 407 | |
| 408 ADMIN_NICK_STATUS:<Return Code>:<Optional args> | |
| 409 <Return Code> is always 0 for success status. | |
| 410 | |
| 411 ADMIN_PASSWD_STATUS:<Return Code>:<Optional args> | |
| 412 <Return Code> is always 0 for success status. | |
| 413 | |
| 414 | |
| 415 PAUSE | |
| 416 Tells TIC to pause so we can do migration | |
| 417 | |
| 418 RVOUS_PROPOSE:<user>:<uuid>:<cookie>:<seq>:<rip>:<pip>:<vip>:<port> | |
| 419 [:tlv tag1:tlv value1[:tlv tag2:tlv value2[:...]]] | |
| 420 Another user has proposed that we rendezvous with them to | |
| 421 perform the service specified by <uuid>. They want us | |
| 422 to connect to them, we have their rendezvous ip, their | |
| 423 proposer_ip, and their verified_ip. The tlv values are | |
| 424 base64 encoded. | |
| 425 | |
| 426 Typical Signon Process | |
| 427 ====================== | |
| 428 Except for the section marked optional this is an sequential | |
| 429 process. Each line MUST occur before the following line. | |
| 430 | |
| 431 * Client connects to TOC | |
| 432 * Client sends "FLAPON\r\n\r\n" | |
| 433 * TOC sends Client FLAP SIGNON | |
| 434 * Client sends TOC FLAP SIGNON | |
| 435 * Client sends TOC "toc_signon" message | |
| 436 * if login fails TOC drops client's connection | |
| 437 else TOC sends client SIGN_ON reply | |
| 438 * if Client doesn't support version it drops the connection | |
| 439 | |
| 440 [BEGIN OPTIONAL] | |
| 441 * TOC sends Client CONFIG | |
| 442 * Client sends TOC permit/deny stuff | |
| 443 * Client sends TOC toc_add_buddy message | |
| 444 [END OPTIONAL] | |
| 445 | |
| 446 * Client sends TOC toc_init_done message | |
| 447 | |
| 448 | |
| 449 SFLAP Documentation | |
| 450 =================== | |
| 451 SFLAP is pretty much a FLAP connection except the DATA frame payload is a null | |
| 452 terminated string when traveling from client to host, it is NOT null | |
| 453 terminated when traveling from host to client. The FLAP Header is binary | |
| 454 data, and is in network byte order. The data portion is at offset 6, after the | |
| 455 header. The sequence number is sequential in each direction. So | |
| 456 packets from the server to client have one sequence number, while | |
| 457 the packets from the client to server have an independent | |
| 458 increasing number. | |
| 459 | |
| 460 FLAP Header (6 bytes) | |
| 461 ----------- | |
| 462 Offset Size Type | |
| 463 0 1 ASTERISK (literal ASCII '*') | |
| 464 1 1 Frame Type | |
| 465 2 2 Sequence Number | |
| 466 4 2 Data Length | |
| 467 | |
| 468 | |
| 469 Valid Frame Type Values | |
| 470 ----------------------- | |
| 471 1 SIGNON | |
| 472 2 DATA | |
| 473 3 ERROR (Not used by TOC) | |
| 474 4 SIGNOFF (Not used by TOC) | |
| 475 5 KEEP_ALIVE | |
| 476 | |
| 477 | |
| 478 TOC SIGNON FRAME TYPE | |
| 479 --------------------- | |
| 480 Sequence Number contains the initial sequence number used in each direction. | |
| 481 Data Length contains the payload length, with the payload described | |
| 482 below. The payload area is NOT null terminated. | |
| 483 | |
| 484 Host To Client: | |
| 485 4 byte FLAP version (1) | |
| 486 | |
| 487 Client To Host: | |
| 488 4 byte FLAP version (1) | |
| 489 2 byte TLV Tag (1) | |
| 490 2 byte Normalized User Name Length | |
| 491 N byte Normalized User Name (NOT null terminated) | |
| 492 | |
| 493 | |
| 494 TOC DATA FRAME TYPE | |
| 495 ------------------- | |
| 496 Sequence Number contains the next sequence number. | |
| 497 Data Length is the length of the payload, including the null termination | |
| 498 from client to host. | |
| 499 |
