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