Re: Extensions to the protocol.

[Kurt Roeckx <Q@xxxxxxx>]

On Thu, Nov 16, 2000 at 01:04:43AM +0200, Timo Sirainen wrote:
> > Since the client is going to have to wait, it should probably
> > default to short (10 seconds?) timeout, or no timeout, if it's
> > sure that the server supports it.
> 
> 10 seconds wait every time some server is connected? I'd never do that
> myself, 1 second at maximum. But of course if the server is busy I could
> easily miss the notice then. And specifying for each server if it supports
> or doesn't support that feature isn't that good idea either.

10 seconds would be the time it waits max, under normal
situations, it should go pretty fast.

> How about this:
> 
> c: pass, nick, user
> s: numeric/notify: options blah blah
> s: ping server (the normal ping without any weirdness)
> c (optionally): reply to options request
> c: pong server
> s: 001, etc.
> 
> The ping/pong part being imporant, when server receives pong it knows the
> client didn't want to respond to options request. Without it either server
> or client would need to wait for some time to be sure the option
> requests/responses weren't missed. I don't think this could even break
> anything.

I would really like to see it happen before PASS, USER, NICK, but
this might work.  This one has the advantage that the client doesn't
have to wait before sending them tho.

I'm thinking about encryption, you probably want to use
encryption before you send a PASS message, but maybe that
encryption layer can do some other for of authenication itself.

What I'm also thinking about is things like the length of a nick
that some nets have changed.  It could be usefull for clients to
know the length of the nick before they send a nick request.
Altho, if they send a too long nicki and it wasn't accepted - for
instance, it's in use - the server should only send back a reply
with the correct length of the nick.

There might be other things you would like to know before you
register yourself, but so far I'm not really against it.


Kurt