Hi Colleagues A few comments expressed a slight preference for option 2 below, rejecting updates with multiple whitespace. So with my devil's advocate hat on let me make a comment. Putting multiple whitespaces in any text string in the database input has no meaning or benefit to anyone (except in "remarks:" for formatted information blocks). So when it occurs it is an obvious typo or misunderstanding of how the database works. The fix for it, compressing the multiple whitespaces into a single space, is clearly defined and I can't think of any situation where applying that fix would corrupt the data. If the database software applies that fix automatically in any situation (except in "remarks:") it makes the database slightly more user friendly. So I don't see the need to reject any update for this mistake, and make users do more work, when it can be so easily fixed. I don't even see the need for any informational message back to the users about applying this fix to their data. Also I would like to see this fix applied to input from Webupdates as well. It is such an obvious and easy fix, why make it an issue. We do have a precedence for this. If you include multiple spaces in an INETNUM range either side of the '-' they are fixed by the software and reduced to a single space. No info message is included in the ack message. cheersdenisco-chair DB WG From: Tim Bruijnzeels via db-wg <db-wg@ripe.net> To: Database WG <db-wg@ripe.net> Sent: Sunday, 12 November 2017, 7:35 Subject: [db-wg] Validation on "org-name:" syntax (double spaces and newlines) Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC