Dear Joachim,
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. 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. - 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. - the software should have found 'U. Schaefer' if the object existed (and nothing more, see algoritm above) - 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). 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. David K. ---