another lookup problem
- Previous message (by thread): another lookup problem
- Next message (by thread): another lookup problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joachim Schmitz
Schmitz at rus.uni-stuttgart.de
Wed Jul 17 18:28:36 CEST 1996
Dear David, you wrote: > From: David.Kessens at ripe.net > Message-Id: <9607171550.AA01322 at belegen.ripe.net> > Subject: Re: another lookup problem > To: noc at noc.dfn.de > Date: Wed, 17 Jul 1996 17:50:50 +0200 (MET DST) > Cc: db-wg at ripe.net > > > 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 at noc.dfn.de) >>>>>> mailto: noc at noc.dfn.de <<<<<< 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 _____________________________________________________________________________
- Previous message (by thread): another lookup problem
- Next message (by thread): another lookup problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]