Hi, change of what? Even database specification [1] doesn't reference any limit for email - so I'm expecting NCC simply follows RFC here. Also you may note mention about IDN - and as you can see, there's explicitly mentioned that there's used punnycode (RFC3492), which may increase lenght of stored email addres quickly and 80 characters might cause future problems, as popularity of IDN grows. Arguments like "reducing database size" are something, what might be valid in early nineties... but in year 2024? No, email lenght isn't any issue from database point of view. Compared to others systems (databases), NCC database is still quite small in terms of records stored, even from my experience from commercial world (like large e-commerce platforms). And of course, if I look on database schema [2], there're larger fields without any issues. Also in some places [3], there's lenght of email sometimes 256 characters. So from this point of view databaase model for storing emails is inconsistent. Why sometimes is email longer than 80 characters "problem" and sometimes isn't? In the past it was normal to call some people simply RFC ignorants and you can imagine why. This may harm people today, I know - but sometimes it's better to call a spade a spade. Even quick view on schema points, that there probably wasn't even a serious analysis and the limits are set somewhat randomly from the data in the coffee grounds and now you're looking for excuses to justify the problem in the design. And I think RFC on internet is something like law. Will we apologize for breaking the law? What about other norms, industry standards? Should we solicit for standards to be followed? Or is it normal to expect that the standards are followed? We're often tasked not to micromanage NCC. But that assumes that the standards are (simply) met. Or what's wrong with the fact that I point out the obvious ignorance of the standards? And that's obvious here. - Daniel [1] https://docs.db.ripe.net/Appendices/Appendix-A--Syntax-of-Object-Attributes/... [2] https://github.com/RIPE-NCC/whois/blob/master/whois-commons/src/main/resourc... [3] On 9/5/24 6:04 PM, Cynthia Revström wrote:
Hi Daniel,
I think it would be more productive to have a nicer tone towards the NCC staff. They are not trying to ignore standards. I would assume that they just set it to 80 because almost no addresses would exceed that and it might make the database a bit smaller.
If you think it's an issue that there is a limit of 80 characters then you can propose a change to the db-wg.
Personally I think it does make a big difference whether or not it's an actual issue or just a theoretical one in a case like this.
-Cynthia
On Thu, 5 Sept 2024, 16:42 Daniel Suchy via db-wg, <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:
Hello, I simply think it's bad approach to *ignore* internet standards (RFCs) and implement your own (nonstandard) rules.
If current database schema doesn't follow standards and as result you have some "generic" errors, you should fix DB schema.
I don't think WG should micromanage NCC in similar "obvious" thinks. There is no need to reinvent the wheel here.
Or the NCC staff wants to tell us that RFCs are a waste of paper?
What real problem solves your limit of email in the RIPE database to 80 characters? Why it isn't simply set 64+255+1 (as expected by RFC 5321 for valid email address)?
It doesn't matter if it causes any real problems. But it can cause them, unexpectly. Statistics are not important here. It's not your role to judge email validity in term of it's length. You have to check its syntax validity. Developers like to introduce their own special rules, but they have no support in the RFC - and that is simply a bug.
- Daniel
On 9/5/24 4:24 PM, Edward Shryane wrote: > We now limit the email address to 80 characters to fit into the database index table, which fixed a bug. Previously, if a user submitted a too-long email address, it would fail with a generic "internal error" because the SQL INSERT statement failed. Now, the update will fail with a syntax error on the email address. > >> I don't think implementing limitations adnd ignoring relevant RFCs here isn't a good approach at all, it can generate unnecessary problems. > Does the 80 character limit cause any problems? We fixed a bug for an issue that occurred once, for an address which seemed to be auto-generated. The average length of all email addresses currently in the RIPE database is 21 characters. > > If the current limit is too restrictive for the DB-WG then we will increase it to the limit defined in the RFC. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db- wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3- migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>