This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
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 ]