Dear David, you wrote:
From: David.Kessens@ripe.net Message-Id: <9607171550.AA01322@belegen.ripe.net> Subject: Re: another lookup problem To: noc@noc.dfn.de Date: Wed, 17 Jul 1996 17:50:50 +0200 (MET DST) Cc: db-wg@ripe.net
Joachim Schmitz writes :
just detected another problem with lookups: I do whois -h whois.ripe.net 192.108.55.0 and get a quite lengthy result - it finds far more persons than I expect. It is perfectly ok that it finds two "Klaus Friedrich" (obviously, there are two entries in the RIPE database). However, I am somehow confused where the program takes all these "Schaefer" from... Could you please check?
What happened:
The software first searches for 'U. Schaefer' and cannot find anything. Then it breaks up the 'U. Schaefer' in the following fields:
U (trailing dots are discarded) Schaefer
the U key is discarded because it is too small (for a good reason)
And the software only looks for 'Schaefer' as can be seen from your result. Obviously clear. It was my fault not to check whether a valid entry for "U. Schaefer" existed or not. It took me by surprise because I am used to another behaviour: If an entry is not found in a database I get a message telling me that it is not found - and not all entries which are somehow similar. I had problems with this behaviour before and simply forgot.
Short discussion:
- U. Schaefer
Names likes this will be rejected in the next release of the updating code. Names should consist of at least two parts, not counting abbreviated parts/titles. I agree with you. I do not enter objects with abbreviations into the RIPE database.
- The inetnum object is incorrect: It references a non-existing person object. This will not happen in normal circumstances. The new (not yet deployed) updating code will disallow (most) non-existing references. I completely agree
- the software should have found 'U. Schaefer' if the object existed (and nothing more, see algoritm above) I again agree
- I can change the indexing in such a way that that trailing dots are indexed. However, this might be worse then the problem: accidental dots after names cause the generation of different keys from the objects where the dots are left out and thus objects that are obvious the same are not seen as such anymore (by the software). I would not like to have trailing dots included.
People often make mistakes with this:
They don't use the initials, they only use one initial instead of more, they use initials with dots and without. Domain name (queries) may end with a dot or not. You can probably find more examples yourself.
- this problem will not happen anymore when we only allow NIC handles in the 'tech-c:/admin-c:/zone-c:' fields.
Conclusion:
This problem only affects incorrect objects. If I make fix, life becomes more difficult when looking for other incorrect objects :-(.
It's up to the RIPE community to decide if it useful to change this behavior.
Come on - no insult was meant. An incorrect object needs no additional checking to determine degrees of incorrectness or how the correct entry could possibly look like. I am just wondering now whether the database should give all information (all people named '.* Schaefer' regexp) if it has none (no 'U Schaefer' after removing the dot). The first approach is advantageuos if you are not sure about the complete name - you get all and just pick the one you really want. However, this makes it more difficult to immediately decide whether there is actually NO entry fitting the search pattern. I would like to know how the working group people think about this. Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________