another lookup problem

Hi Wilfried,

> Wilfried Woeber, UniVie/ACOnet writes :
>
> >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...

I feel that it is best to introduce these checks immediately. The earlier
you do it, the better. The database grows fast (as the Internet does). It
can only save (much) work in the future.

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

I can always issue a warning instead of an error. However, I think that
an error message is more appropriate in case of an error - missing
references are errors in my view.

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

Deletion of referenced objects will now also be checked.

This will also generate an error. I can easily change this to a warning if
people want to, although my personal opinion is that this should be an
error.

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

Agreed.

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

I do some minimal checkings. You are most likely caught when you are
living in North-West Europe ;-). You may always send me a list of very
common titles in your country, and I will add them, but be aware of the
fact that I want to keep this checking minimal, to avoid people (in other
countries) that might have a name that could be the same as a title.

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

See my comments in my mail to David Conrad.

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

It might not be that difficult to implement. Hoever, it might very well
violate one of the success factors of the database, that is: quick answers.

David K.