interesting person entry...
Dear colleagues, dear Ambrose, by accident I discovered a person entry which in its form is definitely not wanted: *pn: Stefan Seiz *ad: Herdweg 73 *ad: \ ... > 128 empty address lines!!! *ad: / *ad: 70174 Stuttgart *ad: Germany *ph: +49 711 18748-0 *fx: +49 711 18748-32 *em: index@schwaben.com *nh: SSE2-RIPE *ny: noc@ecrc.de *ch: wer@ecrc.de 951115 *so: RIPE I am in no position to decide whether the entry was done including these empty lines or whether this is an error of the database software. I think a check should be implemented during acceptance of new database objects (or updates) which - removes empty input lines (or fields which do contain nothing but white space) - afterwards checks whether all mandatory fields for the object are filled in should be done (actually I expect such a test to be performed anyway...) Could anybody please check what is wrong here? Thank you! Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________
Dear Joachim Schmitz, Thank you for infroming us. The object does follow the rules for the person object. Currently, a warning is given as follows: "WARNING: removed empty line(s) in attribute: <attribute>". These are my experiments in the test database; Here is the original e-mail message: person: Dober Mann address: Dog Town address: address: phone: +41 phone: +41 phone: +41 fax-no: +42 e-mail: nic-hdl: AUTO-1 remarks: notify: mnt-by: AMRM1-TEST-MNT changed: ripe-dbm@ripe.net 960926 source: TEST Here is the acknowledgement: New OK: [person] DM1-RIPE (Dober Mann) person: Dober Mann address: Dog Town phone: +41 phone: +41 phone: +41 fax-no: +42 nic-hdl: DM1-RIPE mnt-by: AMRM1-TEST-MNT changed: ripe-dbm@ripe.net 960926 source: TEST WARNING: removed empty line(s) in attribute: "address" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Remember "address" is a mandatory attribute. Empty optional attributes were removed. This may not have been the case when this object was created. I have just seen your follow-up message. I will certainly investigate ! Regards, Ambrose Magee ____________________________ RIPE Database Administration. Schmitz@rus.uni-stuttgart.de (Joachim Schmitz) writes: * * Dear colleagues, dear Ambrose, * * by accident I discovered a person entry which in its form is definitely * not wanted: * * *pn: Stefan Seiz * *ad: Herdweg 73 * *ad: \ * ... > 128 empty address lines!!! * *ad: / * *ad: 70174 Stuttgart * *ad: Germany * *ph: +49 711 18748-0 * *fx: +49 711 18748-32 * *em: index@schwaben.com * *nh: SSE2-RIPE * *ny: noc@ecrc.de * *ch: wer@ecrc.de 951115 * *so: RIPE * * I am in no position to decide whether the entry was done including these * empty lines or whether this is an error of the database software. * * I think a check should be implemented during acceptance of new database * objects (or updates) which * - removes empty input lines (or fields which do contain nothing but * white space) * - afterwards checks whether all mandatory fields for the object are filled * in should be done * (actually I expect such a test to be performed anyway...) * * Could anybody please check what is wrong here? * Thank you! * * Joachim * ____________________________________________________________________________ * _ * * DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) * >>>>>> mailto: noc@noc.dfn.de <<<<<< * Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart * Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) * EMERGENCY phone +711 1319 139 with answering machine and pager * ____________________________________________________________________________ * _ *
Hi Joachim,
Joachim Schmitz writes :
by accident I discovered a person entry which in its form is definitely not wanted:
*pn: Stefan Seiz *ad: Herdweg 73 *ad: \ ... > 128 empty address lines!!! *ad: / *ad: 70174 Stuttgart *ad: Germany *ph: +49 711 18748-0 *fx: +49 711 18748-32 *em: index@schwaben.com *nh: SSE2-RIPE *ny: noc@ecrc.de *ch: wer@ecrc.de 951115 *so: RIPE
I am in no position to decide whether the entry was done including these empty lines or whether this is an error of the database software.
I am in such a position and found indeed a bug (It was the power of two that made me feel that there was a bigger problem then at first sight). I could quickly trace the problem *and* have fixed the code. The software was doubling the number of empty attributes during the reindexing process :-(. The fix will also remove the extra empty lines during the reindexing process. Note for the real-time mirror people: The fix might cause some faulty updates (the software will warn you about this). Please get the new software when Ambrose makes it available.
I think a check should be implemented during acceptance of new database objects (or updates) which - removes empty input lines (or fields which do contain nothing but white space)
The software intended to do the following: - Remove leading and trailing empty lines in every attribute. (attribute=all lines with the same attribute together) - Accept empty lines inside the attribute (This allows for punctuation in Free Text attributes) I changed this one to: Accept at most one consecutive empty line in an attribute. Note: some individual attributes might have syntax checking code that disallows any empty lines inside the attribute.
- afterwards checks whether all mandatory fields for the object are filled in should be done (actually I expect such a test to be performed anyway...)
This is done & was done. The database working group might want to decide to completely disallow empty attribute lines inside a (non empty) attribute. I personally feel that this should be done through the config file: give every attribute a property of allowed empty lines or not. For example 'remarks:' lines can be read easier when they may contain empty lines while empty rev-srv: lines are useless. David K.
Dear David, you wrote as reply to my mail:
From: davidk@isi.edu Message-Id: <9609261851.AA00711@old.isi.edu> Subject: Re: interesting person entry... To: noc@noc.dfn.de Date: Thu, 26 Sep 1996 11:51:51 -0700 (PDT) Cc: db-wg@ripe.net (Database Working Group) [...]
by accident I discovered a person entry which in its form is definitely not wanted:
*pn: Stefan Seiz *ad: Herdweg 73 *ad: \ ... > 128 empty address lines!!! *ad: / *ad: 70174 Stuttgart *ad: Germany [...] I am in no position to decide whether the entry was done including these empty lines or whether this is an error of the database software.
I am in such a position and found indeed a bug (It was the power of two that made me feel that there was a bigger problem then at first sight).
I could quickly trace the problem *and* have fixed the code.
Great! Thank you very much for this fast debugging! (and that it was done remotely from ISI ;-) [...]
The database working group might want to decide to completely disallow empty attribute lines inside a (non empty) attribute.
I personally feel that this should be done through the config file: give every attribute a property of allowed empty lines or not. For example 'remarks:' lines can be read easier when they may contain empty lines while empty rev-srv: lines are useless.
Wilfried: I suggest a collection of all attributes should be analyzed to see where empty lines are useful and where not. I currently do not have an overview of all attributes but I feel that - single ones - attributes used as reference (e.g. tech-c) - attributes necessary for administrative database purposes (e.g. changed or source) must not be empty (just as it came to my mind). I wonder how many attributes might be left over which could carry empty lines. I feel that the address attribute should not have empty lines. However, empty lines could be useful as David noted on the remark attribute. I guess this might be a point for the agenda of RIPE26... Thank you, David for this fast repsonse! Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________
participants (3)
-
davidk＠isi.edu -
RIPE Database Manager -
Schmitz＠rus.uni-stuttgart.de