bug in the whois/wais query?

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 at radcom.co.il
> >   > nic-hdl:     DM55-RIPE
> >   > notify:      lir at NetVision.net.il
> >   > mnt-by:      NNCC
> >   > changed:     steiff at 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 at hotsoft.vsat.ro
> >   > nic-hdl:     MM200-RIPE
> >   > notify:      ncc at banknet.net
> >   > changed:     zsako at 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 at hotsoft.vsat.ro
> >   > nic-hdl:     MM184-RIPE
> >   > changed:     alina at 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
> >   ----
> >   
> 
>