Re: bug in the whois/wais query?
From owner-db-wg@ripe.net Wed Apr 3 19:00:08 1996
Dear David,
Janos Zsako writes :
I have noticed a problem with a person called Matyas Matyas. I needed him in the RIPE database. I queried the database and got:
whois -h whois.ripe.net "Matyas Matyas" person: Dedi Matyas address: RADCOM Ltd. address: 8 Hanechoshet St. Tel-Aviv 69710, Israel phone: +972 3 6472694 fax-no: +972 3 6474681 e-mail: dedi@radcom.co.il nic-hdl: DM55-RIPE notify: lir@NetVision.net.il mnt-by: NNCC changed: steiff@NetVision.net.il 960225 source: RIPE
I therefore registered the following person:
person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40 65 16 65 16 fax-no: +40 65 16 62 90 e-mail: matyi@hotsoft.vsat.ro nic-hdl: MM200-RIPE notify: ncc@banknet.net changed: zsako@banknet.net 960403 source: RIPE
I queried the database in the same way and I got the same result as the first time!
Therefore I suspected the person had been registered earlier and I queried the database with the WAIS option (through telnet info.ripe.net). I looked for the word "Matyas" and I got three results, one of them was the object below:
person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40-65-166516 fax-no: +40-65-166290 e-mail: matyi@hotsoft.vsat.ro nic-hdl: MM184-RIPE changed: alina@u1.ici.ro 960326 source: RIPE
and two irrelevant person objects, but the person with the NIC-handle MM200-RIPE was not there! I got a similar result with a different keyword ("matyi" from the e-mail address) and again got MM184-RIPE, but not MM200-RIPE.
Is this normal (did I miss something) or is this a bug? (I see two different problems which might have the same cause: - why does the whois not give me both MM184-RIPE and MM200-RIPE as an answer to the 'whois -h whois.ripe.net "Matyas Matyas"'? - why does the WAIS not give me the person object MM200-RIPE? ).
I could explain however the behaviour of the WAIS query by the fact that it does not search the "real" database, but a copy of it, which is updated in bigger chunks. Is this the explanation for the second problem?
Correct, WAIS gets updated only once a day. We can should be able to see the object tomorrow.
I find no explanation for the first problem though...
I think that we are dealing with a 'feature' and possibly a bug (I need to investigate this in more detail to be sure).
The database uses the following algoritm to find an object:
- break up the search key on space boundaries:
Matyas Matyas ----> (Matyas, Matyas)
Thank you for your detailed answer. I think I have now better delimited the problem, which seems to be a _bug_ also after the explanation you gave. Based on your description of the algorithm I would definitely assume that the result of the query whois -h whois.ripe.net "Matyas Matyas" should be the same as the result of the query whois -h whois.ripe.net Matyas Am I correct? The problem is that they are NOT the same! The correct result is provided only by the second query. :( The first one _excludes_ only the correct answers, instead of _returning_ only those values? This looks like a condition written in a negated form... Best regards, Janos
- Then it looks for objects that match the keys
Dedi Matyas (Dedi, Matyas)
Example:
Matyas -> 3,5,10 Dedi -> 5
- It returns the objects that are pointed by all the keys (not one of them) but ignores keys that don't reference anything:
Thus a query for:
Matyas Matyas
will give you back any objects that have a Matyas key (objects 3,5,10)
and
Dedi Matyas
will give you object 5 (not 3 & 10)
It looks like the database gives consistent output except for the following case:
$ whois -r Matyas Matyas
person: Dedi Matyas
because the above described algoritm should give you all objects that have a key Matyas and should give the same result as the following query:
$ whois -r Matyas
person: Dedi Matyas ... person: Matyas Matyas ... person: Matyas Matyas ...
I made some completely new code for this part of the RIPE database in my own time but it is far from production quality but the problem is on the list (This code also solves the 'too many hits' problem for people with very common first and last names).
Note that it is recommended to do your first search with a not too refined key: You cannot always be sure that people that registered a person had the same idea of the first name of a person (only initials, full name).
Thanks for noticing and informing me of this problem. It will certainly be looked into,
Kind regards,
David Kessens RIPE Database maintainer ----
Dear Janos,
Janos Zsako writes :
Janos Zsako writes :
I have noticed a problem with a person called Matyas Matyas. I needed him in the RIPE database. I queried the database and got:
whois -h whois.ripe.net "Matyas Matyas" person: Dedi Matyas address: RADCOM Ltd. address: 8 Hanechoshet St. Tel-Aviv 69710, Israel phone: +972 3 6472694 fax-no: +972 3 6474681 e-mail: dedi@radcom.co.il nic-hdl: DM55-RIPE notify: lir@NetVision.net.il mnt-by: NNCC changed: steiff@NetVision.net.il 960225 source: RIPE
I therefore registered the following person:
person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40 65 16 65 16 fax-no: +40 65 16 62 90 e-mail: matyi@hotsoft.vsat.ro nic-hdl: MM200-RIPE notify: ncc@banknet.net changed: zsako@banknet.net 960403 source: RIPE
I queried the database in the same way and I got the same result as the first time!
Therefore I suspected the person had been registered earlier and I queried the database with the WAIS option (through telnet info.ripe.net). I looked for the word "Matyas" and I got three results, one of them was the object below:
person: Matyas Matyas address: HotSoft Tirgu Mures - ROMANIA address: O.P. 1, C.P. 172 address: 4300 Tirgu Mures - Romania phone: +40-65-166516 fax-no: +40-65-166290 e-mail: matyi@hotsoft.vsat.ro nic-hdl: MM184-RIPE changed: alina@u1.ici.ro 960326 source: RIPE
and two irrelevant person objects, but the person with the NIC-handle MM200-RIPE was not there! I got a similar result with a different keyword ("matyi" from the e-mail address) and again got MM184-RIPE, but not MM200-RIPE.
Is this normal (did I miss something) or is this a bug? (I see two different problems which might have the same cause: - why does the whois not give me both MM184-RIPE and MM200-RIPE as an answer to the 'whois -h whois.ripe.net "Matyas Matyas"'? - why does the WAIS not give me the person object MM200-RIPE? ).
I could explain however the behaviour of the WAIS query by the fact that it does not search the "real" database, but a copy of it, which is updated in bigger chunks. Is this the explanation for the second problem?
Correct, WAIS gets updated only once a day. We can should be able to see the object tomorrow.
I find no explanation for the first problem though...
I think that we are dealing with a 'feature' and possibly a bug (I need to investigate this in more detail to be sure).
The database uses the following algoritm to find an object:
- break up the search key on space boundaries:
Matyas Matyas ----> (Matyas, Matyas)
Thank you for your detailed answer.
I think I have now better delimited the problem, which seems to be a _bug_ also after the explanation you gave.
Based on your description of the algorithm I would definitely assume that the result of the query
whois -h whois.ripe.net "Matyas Matyas"
should be the same as the result of the query
whois -h whois.ripe.net Matyas
Am I correct? The problem is that they are NOT the same!
Yes, you are correct. This is the real bug. The other data that you showed was in line with the (expected) answers except for the above shown one.
The correct result is provided only by the second query. :( The first one _excludes_ only the correct answers, instead of _returning_ only those values? This looks like a condition written in a negated form...
Here you are not correct. The first query gives only one of the answers: $ whois -h whois.ripe.net "Matyas Matyas" person: Dedi Matyas Matyas is indeed a key of the 'Dedi Matyas' object since the database finds the keys by splitting a line into non-white space components. However, the software should have also found the 'Matyas Matyas' objects since they match the same keys. The problem is probably located somewhere in the routine that computes the intersection of the found objects for every key (But that is now my problem to find out...) Kind regards, David K. ----
- Then it looks for objects that match the keys
Dedi Matyas (Dedi, Matyas)
Example:
Matyas -> 3,5,10 Dedi -> 5
- It returns the objects that are pointed by all the keys (not one of them) but ignores keys that don't reference anything:
Thus a query for:
Matyas Matyas
will give you back any objects that have a Matyas key (objects 3,5,10)
and
Dedi Matyas
will give you object 5 (not 3 & 10)
It looks like the database gives consistent output except for the following case:
$ whois -r Matyas Matyas
person: Dedi Matyas
because the above described algoritm should give you all objects that have a key Matyas and should give the same result as the following query:
$ whois -r Matyas
person: Dedi Matyas ... person: Matyas Matyas ... person: Matyas Matyas ...
I made some completely new code for this part of the RIPE database in my own time but it is far from production quality but the problem is on the list (This code also solves the 'too many hits' problem for people with very common first and last names).
Note that it is recommended to do your first search with a not too refined key: You cannot always be sure that people that registered a person had the same idea of the first name of a person (only initials, full name).
Thanks for noticing and informing me of this problem. It will certainly be looked into,
Kind regards,
David Kessens RIPE Database maintainer ----
participants (2)
-
David.Kessens@ripe.net
-
zsako@banknet.net