another lookup problem

Daniel,

> Daniel Karrenberg writes :
> 
>   > Schmitz at rus.uni-stuttgart.de (Joachim Schmitz) writes:
>   > ...
>   >  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 reall
>   > y
>   >  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.
> 
> Joachm, David,
> 
> I think that the query should not be 'generalised' automagically if an
> object matching all the keys in the query cannot be found.  As Joachim
> states correctly there is an important functionality in having a "not
> found" result.  It should be up to the user to generalise the query by
> dropping keys if they wish.  Automatic 'query modification' is not
> needed with a database that has such a short response time. 

I have tried to explain in my previous mail why this 'problem' happened.
I showed that it is a special case. I showed that it was a special case
with specific (incorrect) objects that should not even be in the database
but are there because of louzy syntax checking (that is fixed in the next
release). I also showed that the problem in fact only happens in the case
that objects reference such objects but *don't* exist. The software will
find the correct objects when the incorrect object exists (and only the
referenced object).

The behavior is not that different from the previous version of the
database. The trailing dot removing is new. The skipping of too small
keys is not new (try 'whois -p 4400 -h whois.ripe.net U Schaefer', this
is the old server). I think that it is reasonable to skip keys that are
only one character long. I think it is reasonable to remove trailing dots
(this is much easier for users for 99.99% of the cases).

Yes, this choice is a trade off. The choice you propose is that we accept
any key, no matter how short. This also has some severe disadvantages.

Do you want to let the whois server behave different for queries as:

'U. Schaefer' OR 'U Schaefer'
'ripe.net' OR 'ripe.net.'
'John F. Kennedy' OR 'John Kennedy' (are you always sure if somebody
                                     used his/her initials and which they 
                                     are?)

notes for all examples: 1) the database *will* return only exact matching
                           objects when they exist.
                           
                        2) only one character keys (as with the
                           previous version of the software) possible
                           followed by dots are dropped.
                           
                        3) the other 'fuzzy logic' matching (skip keys
                           that don't exist) has been removed as
                           announced in a previous mail and asked for by
                           the database working group.

This was the question (and may be answered with yes),

David K.