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.

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/>

Hi, On Thu, Sep 05, 2024 at 01:53:42PM -0700, Leo Vegoda wrote:

If there are good operational reasons for being more restrictive than is allowed for in RFC 5341 then we should not disregard those reasons for the sake of strict compliance with a very generous standard.

Is there? "Because someone once choose char(80) for the DB schema" does not truly sound like a "good operational reason", tbh. I do not feel strongly about this, so I won't argue either way, just pointing out that "varchar(255)" exists and in everything modern column widths are not using fixed disk space anymore :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Dear colleagues,

On 6 Sep 2024, at 10:34, Pavel Kácha via db-wg <db-wg@ripe.net> wrote:

...

On Thu, Sep 05, 2024 at 01:53:42PM -0700, Leo Vegoda wrote:

...

If there are good operational reasons for being more restrictive than is allowed for in RFC 5341 then we should not disregard those reasons for the sake of strict compliance with a very generous standard.

And are there any good operational reasons?

As long as I strongly don't appreciate Dan's style of communication, I tend to agree with the merit here. Call me biased, but I've already met too much of "your email is too long", "too short", "contains too many dots", "contains plus sign" meaning "give us email we like or go away".

RFCs are not a law, but they're here for a reason.

-- Pavel (ph)

Thanks very much all for your feedback, and Daniel for your suggestion. I don't see any replies that are in strong opposition, so we will extend the email address length to comply with the RFC. We will also review the rest of the DB schema (now over 20 years old) in case there are any other limits that should be updated: https://github.com/RIPE-NCC/whois/blob/master/whois-commons/src/main/resourc... Regards Ed Shryane RIPE NCC