Re: Current PING/PONG implementation to violate the RFC

[Christophe Kalt <kalt@xxxxxxxxxxx>]

On Feb 10, Kaspar Landsberg wrote:
| On Wed, Feb 10, 1999 at 06:23:10PM +0100, Q wrote:
| | "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".

Try and read RFC 2119

[..]
| | > (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.

many bots could be considered daemons.
but arguing on this is really stupid.

| | > 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.

nor can I read what you read.  The RFC does NOT say how/when
to reply with ERR_NOSUCHSERVER, only that this numeric is
used as a reply.  (And _it is_).