This is the status of the TS4 implementation:
*) I'm a client coder; what should my client do to support TS4?       

        TS4's new features have been designed to avoid confusing older  
        clients whenever possible.  ircII, EPIC and sirc all mostly work
        with TS4 without modifications [someone needs to check the
        Windows and Mac clients; I can't.]

        Still, there are a number of ways a client (or script) can      
        explicitly support TS4, to make things easier for the user. 

        1) The very basics, that every client should do:

        .  When parsing mode changes, it's good to know that +h and +e   
           take an argument.  Clearing channels sets mode +z temporarily
           (as in "zapped channel"), so the client shoulnd't crash on
           seeing a mode +z or -z either.

--> The client fully supports the +h <nick> channel mode.
--> The client fully supports the +z channel mode.
--> The client ignores any argument for +e, the same as it does for +b.

        .  When parsing NAMES, WHOIS and WHO replies, it's good to know
           that '%' is a user flag, and that more than one flag can   
           appear at a time (so you can have things like "@%+nick").     

--> The client fully supports multiple user-modifiers in the NAMES reply.
--> The client fully supports all three user-modifiers (@, %, and +)
--> The client may not fully support multiple user-modifiers in WHO replies
--> The client may not fully support multiple user-modifiers in WHOIS replies.

        .  The "End of Exception List" numeric shouldn't be displayed
           by default.

--> Without knowing what numeric this is, this is not supported.

        .  Expect to get PRIVMSGs for @#channel, @%#channel and
           @+#channel, and show them in the same area as the channel's 
           messages (but marked in some way).  Same with @&channel,    
           @%&channel and @+&channel for local channels.

--> There is no special support for these targets.  They are handled
	as any other non-channel target would be handled.

        .  Do NOT ever automatically deop people opped by servers.  This 
           is the best and easiest way to end up with an opless channel,
           and it defeats the whole purpose of channel passwords and op
           recovery.

--> The client does not automatically deop anyone, ever.

        .  If your client kicks people from banned addresses, make sure
           it also checks against exception lists (mode +e).

--> The client does not automatically kick anyone, ever.

        .  Expect 3 parameters rather than 1 from numeric 329
           (RPL_CREATIONTIME);  see also the list of changed and added
           numerics on README.TS4.

--> The client fully supports three arguments to the 329 numeric, if present.

        2) Possible additions:

        .  If the client has ban management functions, the same
           functions should be offered to manage exception lists.     

--> The client does not have ban management, so no change is required.

        .  There should be a command or button to join a channel using a
           password, prompting the user for the password without        
           displaying it on the screen.

--> The client already permits passwords in the /join command, so no change
	is required.

        .  Even better, a list of known passwords could be saved to a
           file (readable only by the user); the client would then use
           the saved password (if there's one), instead of prompting.
           The user should have a way to add, remove and change elements
           in the list, from within the client.

--> The client does not manage or store passwords on any permanent medium,
	and no intention to change this is planned.

        .  Whenever the client sees a "mode +c" on a channel, it could
           query the server for the password, and remember it.  It
           should _not_ show it on the screen by default (you don't want
           passwords shown automatically when there could be someone
           looking behind the user's shoulder).

--> There is no support for this currently.

        .  Expect to get PART commands for yourself from the server,
           even if the user has not requested to leave any channels (this
           happens with recovered nick collisions).  For GUI clients,   
           you might want to leave the client a chance to read the   
           channel window contents.

--> As the client does not track when the user PARTs a channel, the client
	has no way to know whether a recieved PART was initiated by the
	user.  Thus, no recovery for the channel can be made automatically
	by the client.  Perhaps the designer of this "feature" ought to have
	considered sending a numeric before the PARTs come flowing so as not
	to make it gratuitously difficult to support this.

        .  When you get the "nick lost" numeric (453), prompt the user 
           for a new nick, and send an ordinary nick change command to
           the server.  Any commands sent in between can get ignored with
           "not registered" errors from the server.

--> The 453 numeric handled just like any other non-disruptive nick collision.

        .  Clients should be able to handle reconnection cookies
           automatically: whenever you connect to a server and get back
           a cookie (with the numeric 014, "<cookie> :is your  
           reconnection cookie"), the client should store the cookie,  
           along with the server name and the current time, in a file. 
           At that same moment, the client should look if there is a
           previously saved cookie for that server; if there is one,
           delete it from the file, and send it to the server, unless it 
           is more than 10 minutes old.

--> The client will remember cookies from previous connections and will
	always send the cookie upon the next connection.  The client makes
	no attempt to determine if the cookie is "too old" to be used.
	The client makes no attempt to store cookies on a permanent medium
	for use by a subsequent client.

Last updated, November 17, 1998.
