Person-Objects with multiple adresses + phones
Hello, 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. 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. As I understand the operation of the database now, all phone-numbers etc. are collected together, so the relationship to the addresses are lost. Best Regards, HaJo Gurt ------------------------------------------------------------------- Nacamar Network Administration NACAMAR Data Communications guardian@nacamar.net Frankfurter Str. 135-141 D-63303 Dreieich +49 6103 9901 ?? Voice Germany +49 6103 9901 18 FAX gurt@nacamar.de -------------------------------------------------------------------
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. ---
Dear Sir,
From instruction in RIPE's configuration file. There is a suggestion that we should not use NIC handle's postfix differrent from the source name.
Can someone explain me why? Are there any serious errors if I do so. Thanks, Suwat Panitkullawat..
On Wed, 15 Jan 1997 21:43:39 +0700 (GMT+7:00) Suwat Panitkullawat wrote:
From instruction in RIPE's configuration file. There is a suggestion that we should not use NIC handle's postfix differrent from the source name.
Can someone explain me why? Are there any serious errors if I do so.
Hi, Currently, handles work per registry. That is, it is likely that the Internic allocates SP123 to somebody else than the RIPE registry would do. To avoid confusion, it was agreed that we would always append -RIPE to handles we create, and that Internic would never append -RIPE, so that these would always be different. Apnic uses the country code due to the different political structure in that area. It's a hack, but it works. Geert Jan PS: in the very beginning we created handles with RIPE- as prefix. I think these are nearly eradicated now. Same reason, but keep in mind that SP123-RIPE and RIPE-SP123 are NOT the same..
participants (4)
-
davidk＠isi.edu -
Geert Jan de Groot -
Nacamar AS Guardian -
Suwat Panitkullawat