Person-Objects with multiple adresses + phones

Hi HaJo,

> Nacamar AS Guardian writes :
> 
> there are a number of persons with multiple _entries_ 
> in the RIPE-Database, because they have multiple _adresses_,
> and I think, this is not handled well with our current 
> implementation.

Correct :-(.

> To make this more acceptable for such people, 
> something like the following should be possible:
> >>>
> person:      Thomas Peters
> remarks:     -- #1 - Main office:
> address:     Thomas Peters
> address:     Nacamar Data Communications GmbH
> address:     Frankfurter Strasse 141
> address:     D-63303 Dreieich
> address:     Germany
> phone:       +49 6103 9901 14
> fax-no:      +49 6103 9901 18
> e-mail:      info at nacamar.net
> remarks:     -- #2 - South office:
> address:     Thomas Peters
> address:     Herd-Weg 8
> address:     D-69198 Schriesheim OT. Ursenbach
> address:     Germany
> phone:       +49 6220 9111 25
> fax-no:      +49 6220 9111 259
> e-mail:      peters at nacamar.net
> remarks:     -- #3 ...
> nic-hdl:     TP65-RIPE
> ...
> <<<
> This applies too for people working as tech-c for
> several companies.
> 
> It should be possible for each address-block 
> to have its own phone/fax/eMail with it.

I agree, but see below ...

> As I understand the operation of the database now, 
> all phone-numbers etc. are collected together,
> so the relationship to the addresses are lost. 

Correct.

The regrouping of the attributes is for some people very nice if they are
just adding some lines to an object (example: a 'changed' line, an
'e-mail:' line). For some other people it is really bad. You can think of
'remarks:' lines that you want to point to a certain block in the object
and that gets concatenated with other comments that make remarks for
other parts of the object. 

However, the design of the internals of the database makes it very hard
to change this behavior. Of course it can be done, but it would take
quite some time to code and test such a change. On the other hand,
recoding this could be benificiary to the software since I think that it
can make the implementation cleaner and thus make the maintenance and
implementation of new features in the software easier.

I recently stumbled in the same problem since I am busy with the RPSL
implemention for the RIPE database. The (new) RPSL language specification
for routing policy specifications specifies that implementations don't
reorder attributes and store them as-is just as you propose.

Since the implementation would take quite some time *and* since this part
of the specification really contradicts with the current implementation
philosophy, I have decided to violate the RPSL specification and to first
get the other parts implemented. However, it might be interesting how
other people think about this topic since we could decide to put this on
the TODO list for the RIPE database implementation with an appropriate
priority. We might want to discuss this topic in more depth during the
next RIPE meeting.

David K.
---