Re: another lookup problem

 Dear David,

 you wrote:
> From: David.Kessens@localhost
> Message-Id: <9607171550.AA01322@localhost>
> Subject: Re: another lookup problem
> To: noc@localhost
> Date: Wed, 17 Jul 1996 17:50:50 +0200 (MET DST)
> 
> > 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@localhost)
                     >>>>>> mailto:  noc@localhost   <<<<<<
   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
_____________________________________________________________________________