Re: another lookup problem

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