another lookup problem

  Hi David & DB folks !

>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)

  As much as I remember, this is in line with a recommendation from the
  DB-WG.

>...
>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.

  Good stuff.
  But I think we should try to weed out offending things before (or in
  parallel) with the introduction of this more stringent checks. I think
  we add just another level of complexity and user confusion if we don't...

>- 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.
  
  Hmmm....
  What about allowing an update but issuing a warning?
  And the other way 'round - 
  issue a warning if an object which is still referenced gets removed.

  I'm not sure whether it makes sense to *sometimes* enforce link sanity
  and to allow for breaking them later (e.g. with a delete for the
  referenced object).

  Maybe that's just some aspects for a (hypothetical) package of sanity
  checks that might be activated regularly or upon request.

>- the software should have found 'U. Schaefer' if the object existed (and
>  nothing more, see algoritm above)
>
>- 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 don;t think that we should make software chages to accomodate syntax
  errors. In a lot of different documents, the syntax for a person
  object is cleraly defined: name [initials] name - the initials to be
  registered without a trailing dot.
  
  At the same time titles and gender specific local language "syntactic
  sugar" is not allowed. Not sure whether there's a chance to guard
  against the proliferation of "Herr", "Frau", "Professor" etc...
  
 ~~~~~~

  WRT "fuzzy" / wildcard matches - it would make the RIPE-DB software
  more user friendly (and maybe more attractive for deployment by other
  registries) to provide for (implicit/explicit) regexp or partial key
  matches.
  
  But I think that would be a major (conceptual) change and should be
  discussed, both technically and the human resources involved. Even if
  it might be easy to implement :-)
  
  Wilfried.
  
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber at CC.UniVie.ac.at
  Computer Center - ACOnet       :  
  Vienna University              :  Tel: +43 1 4065822 355
  Universitaetsstrasse 7         :  Fax: +43 1 4065822 170
  A-1010 Vienna, Austria, Europe :  NIC: WW144
 --------------------------------------------------------------------------