Daniel,
Daniel Karrenberg writes :
Schmitz@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.