Current PING/PONG implementation to violate the RFC

[Kaspar Landsberg <kl@xxxxxxxxxxx>]

Hi all.

Everyone, who has been watching the recent discussion about the
PING/PONG implementation in the current ircnet ircd, has probably noticed
that the change it underwent some time ago aimed to fix the traditional
behavior in order to make the new one RFC compliant.

Well, as you will see below, the current implementation of the PING/PONG
procedure is still violating the RFC both in its spirit and in its letter.

The RFC says in section 4.6.2:

   Servers should not respond to PING commands but rely on PINGs from
   the other end of the connection to indicate the connection is alive.

The current implementation is violating the spirit of this by responding
to PINGs with a PONG.


Furthermore, the RFC says in section 4.6.3:

   Command: PONG
   Parameters: <daemon> [<daemon2>]

   PONG message is a reply to ping message.  If parameter <daemon2> is
   given this message must be forwarded to given daemon.  The <daemon>
   parameter is the name of the daemon who has responded to PING message
   and generated this message.

The current implementation is violating the letter of this by responding
to a PING (from a client) with 

":prefix PONG <server name> [:]<nickname>"

(that´s a quote from syrk´s first reply on the other thread). According to
the quoted paragraph above, a second argument to PONG may only be present
if it´s a server ("daemon" designates always a server). But in the current
implementation the second argument to PONG is a nickname (see the quote).


And finally (this one is for the RFC compliancy die-hards ;) the RFC says
in section 4.6.2:

   Command: PING
   Parameters: <server1> [<server2>]

The current implementation is violating this in addition to the
first mentioned violation by not responding with an ERR_NOSUCHSERVER
numeric reply to a PING in which the first argument is not a valid
(existing) server name and in general by letting clients use PING.


Therefore, since we want to be RFC compliant whereever we can and since
the is the only thing the outside world has, i ask those violations to be
fixed ASAP in the ircnet implementation of the RFC protocol.


Ok, now let´s have a look at the whole issue from a reasonable point of
view:

Most servers allow clients to send PINGs out.
Most servers allow clients to send out remote PINGs.
Most servers allow clients to send PINGs with random data to the server
and then get that data back in the corresponding PONG reply.
Most servers replace <daemon2> with a nickname in the PONG reply when
appropriate.

Strictly speaking all of those extensions violate the RFC, yet they are
reasonable, they _make sense_.

So why should we throw out just one of them with the pretention of not
being RFC conform whereas we are keeping all the others?

The RFC 1459 aimed to document the existing irc2.8. I´m sure that irc2.8
was already violating the RFC which may sound a bit paradox. But the
reason for this is probably that the PING/PONG procedure was just not well
documented by the RFC. Because, if you use it strictly according to the
RFC it´s not very useful. :p

So could we all PLEASE have a reasonable look at the whole issue and get
the useful extension of the PING/PONG procedure (as described in the other
thread) back?

Bye, Kasi

-- 
Kaspar Landsberg, <kl@xxxxxxxxxxx>