Re: Current PING/PONG implementation to violate the RFC

[Kaspar Landsberg <kl@xxxxxxxxxxx>]

Hello,

On Wed, Feb 10, 1999 at 06:23:10PM +0100, Q wrote:

| > 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.
| 
| "should not" != "is not allowed". "should not" means that he can send a
| ping, but he shouldn't. 

Exactly. That´s why i said that the implementation is violating _the
spirit_ of the RFC and not the letter. It´s in the spirit of the RFC not
to respond to PINGs because it says "should not".

| It means that any message received (like a
| ping), is enough for the connection to be alive. If you read what's just
| below, you see that PONG is the reply to a PING. You say that I never
| should send a PONG ....

I don´t understand that. If i read what´s there it tells me that servers
should not reply to PINGs (not with a PONG and not with anything other)
but that PONG should be used by clients to respond to PINGs.

| > (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).
| 
| "daemon" is not defined in the rfc, but probably means just the same as
| server, and can be interpreted as the client. 

Well, there are a lot of words in the RFC which are not defined. This
doesn´t mean that you get a card blanche for wild interpretations. ;-)

"daemon" is never a client.

| > 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.
| 
| <server> is either the name of a server, or a cient using that server.
| If you fail to set your own nick in <server1>, the server should not
| return ERR_NOSUCHSERVER, because <server1> isn't a "server".

I can´t read that in the RFC.

| > 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.
| which is normal.

ACK.

| > Most servers allow clients to send out remote PINGs.
| which is normal.

ACK.

| > Most servers allow clients to send PINGs with random data to the server
| would you like it to generate a (new) error, or just change your data
| your nick?

This is getting a bit beside the essence of my argumentation. What i
pointed out that the so called fix to the PING/PONG behavior which aimed
to make it RFC compliant failed to meet RFC compliancy and thus made the
argumentation for it nil.

| > and then get that data back in the corresponding PONG reply.
| > Most servers replace <daemon2> with a nickname in the PONG reply when
| > appropriate.
| 
| What do most server do? They return both the nick and the data? Or only
| nick or data?

Only the data.

Bye, Kasi

-- 
Kaspar Landsberg, <kl@xxxxxxxxxxx>