Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

[CS] Protocol Proposal

Última Actualización: 23 de Febrero de 1.999 - Martes 

Message-ID: <3569FCF6.F6BB2F16@argo.es>
Date: Mon, 25 May 1998 23:21:26 +0000
From: Jesús Cea Avión <jcea@argo.es>
Organization: Argo Redes y Servicios Telematicos, S.A.
To: clientserver@dal.net
Subject: [CS] Protocol Proposal

I sent this text last March to Undernet Coding Mailing list. What do you think?

>>>>>
[...]
d) PROTOCOL. I was waiting to propose things like data compression (at ESNET we are checking ideas using an experimental java client), local client proxying (like clones but eliminating duplicate messages like privmsg to common channels), nick authentication at server level or encryption. PROTOCOL seems to be the correct container.

Somebody suggests TELNET like negotiation, but WILL, WON'T, DO, DON'T telnet procedures (see RFCs) are a a bit cumbersome. I'd suggest something more in the PPP line (see RFCs, also). Simplified (and supposing that each "mode" negociated is bidirectional):

  1. Client connects.

  2. It sends a "protocol" message asking several features.

  3. Options unknown by the server are refused. Parametriced modes with invalid params return "suggested" values. Mutually exclusive modes are rejected, keeping "best" option (see example below).

  4. Client changes its "protocol" demanded string and go point 2

  5. If all options demanded can be granted, server sends an ACK. Options take effect here.

  6. Client sees the ACK and changes modes.

You can renegociate connections any time unless a negotiation phase is in progress.

Nodes don't require "advertise" its possible modes. And clients only "sees" modes that they support. You could see possible modes using a wilcard like "*" (server will "refuse" all its nodes :). You can check modes without activating them using an invalid mode in the string.

Check modes: (usually, manually issued by the user, just curious :)

C: Protocol (or "Protocol *")
S: Protocol nick-1, compress-zlib-1, undernet:compress-1, undernet:compress-2, esnet:channel_service-1

Another example:

C: Protocol nick-1, esnet:compress-1, undernet:compress-2, undernet:compress-2, compress-zlib-1, maxlen(65536)
S: Protocol !esnet:compress-1, !undernet:compress-2, !undernet:compress-2, maxlen(1024)

First option is refused, since it is not supported. Second and third are refused because they are mutually exclusive and zlib is prefered. Maxlen returns a suggested parameter.

So client continues:

C: Protocol nick-1, compress-zlib-1, maxlen(1024)
S: Protocol ACK

And new options are effective here.

Time later the user writes a new script (for example) which demands a new feature. He only wants to know if the server supports the feature, in order to display funny statistics on the screen.

C: Protocol nick-1, compress-zlib-1, maxlen(1024), fortune-1, DUMMY
S: Protocol !DUMMY

DUMMY is a false protocol to force the fail. In the example, server supports "fortune-1" but doesn't activate it since "DUMMY" is not supported.

If the client wants the feature:

C: Protocol nick-1, compress-zlib-1, maxlen(1024), fortune-1
S: Protocol ACK

And changes take effect here.

A server which don't support "protocol" sends a "unknown command".

In any case, clients can't send a "protocol" command if they issued one already and server hasn't replied yet.

<<<<< 

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz

Python Zope ©1999 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS