[dcc2] DCC Chat suggestions

[codemastr]

Well, no one seems to have any real thoughts on any additional features for
DCC2's DCC Chat feature, so I thought I might make some suggestions myself.
I think the new DCC Chat should encompass everything the current DCC Chat
has, but add some more useful features as well.


Current non-standard features:
CTCP ACTION is maintained and handled as it would be for regular IRC text
A client should format a DCC Chat message just as one from IRC (font codes,
color codes, etc.)

New stuff:
CTCP is the means of control within a DCC Chat session.

CTCP NICK
Currently, there is no way to change the nickname you appear as in a DCC
Chat. Most clients I've seen just display the nick that was given in the
CTCP response. If I, as codemastr, send a DCC chat request, no matter what I
change my nickname to, I still appear as codemastr in the DCC session. The
CTCP
NICK feature changes this:

\1NICK newnick\1

I think it is rather useful. First off it makes things uniform. If I change
to "codemastr-away," why shouldn't I appear that way to people in DCC Chat
too? Also, think of it differently, DCC is independant of the IRC server.
So, for example, when DCC Server support is addressed, it could be rather
useful to allow users to change their nicknames. To do this, a legal set of
characters would need to be defined. Probably those from RFC1459 or RFC2812,
though, if we wanted to look the the future, we could again realize that DCC
is seperate from IRC and use a Unicode scheme. I'm sure that would please
people in non Latin-charset areas. The only other problem I see is the issue
of trying to change your nickname to the nick of the other party. To address
these, a new CTCP ERROR would be introduced.

CTCP KEEPALIVE
This is something similar to a PING (command, not CTCP) on IRC. It's just
something I was thinking of as a means to try and make sure the connection,
hasn't been, and won't be, dropped. Basically, when I send a CTCP KEEPALIVE,
you respond back with a CTCP KEEPALIVE.

CTCP ERROR
As I said, this would be used with CTCP NICK, but it can also be used for
other things. The syntax is:
\1ERROR type text\1

The type can be one of the following:
NICKINUSE (the nickname specified in the NICK CTCP is already in use. Not
only is this needed for the other party saying "that's my nickname!" it also
works for partyline scripts so that the "server" can tell the client that
the nick specified is already in use by another partyline member)

NICKILLEGAL (the nickname specified in the NICK CTCP contains illegal
characters)

x-* (The x- prefix is used for private error types. This can be used for
individual implementations that wish to add extended features and may need
to report errors for those features).

Lastly, the client SHOULD treat all CTCPs (FINGER, VERSION, PING, TIME,
etc.) sent through DCC as it would for a regular IRC connection. This is for
2 reasons. One, clients support DCC Server (which as I said, I'd like to see
standardized as well). This means, I can start a DCC chat with someone
without ever being connected to an IRC server! Doesn't it make sense to
allow such users to get this information? Also, even if you forget about DCC
Server, I can initiate a DCC Chat over IRC, then disconnect from IRC and the
DCC remains open. It'd be nice to still be able to get this information.

I'm sure some people will disagree with the ideas, but I'm throwing them out
there anyway :)

P.S. Are there any plans to begin discussion of the other proposed DCC
extensions (voice/video/whiteboard)? For filesends and chat, it's pretty
easy. We have "standardized" existing implementations to work from.
Voice/video/whiteboard are going to need much more fundamental thought work
done (several implementations exist, and it's possible none are truly
perfect), and so, imho they should probably be something people begin to
think about sooner rather than later...

-- codemastr