[{"author": "Rolf Sonneveld", "text": "

+1 for option 3

", "time": "2022-07-26T17:49:23Z"}, {"author": "Pete Resnick", "text": "

Consider me convinced that I should not care about whether the text is fixed or removed.

", "time": "2022-07-26T17:55:19Z"}, {"author": "Pete Resnick", "text": "

If the mailing list is (within error bars) silent, what would the decision be?

", "time": "2022-07-26T17:56:45Z"}, {"author": "Murray Kucherawy", "text": "

John is doing his impression of Joaquin Phoenix in Gladiator.

", "time": "2022-07-26T18:02:43Z"}, {"author": "John Klensin", "text": "

@Murray: ROFL

", "time": "2022-07-26T18:12:10Z"}, {"author": "John Klensin", "text": "

But the first step in getting our patterns in synch is to make our patterns absolutely clear.

", "time": "2022-07-26T18:13:23Z"}, {"author": "John Klensin", "text": "

An advanced regular expression is even worse than the ABNF

", "time": "2022-07-26T18:15:53Z"}, {"author": "John Levine", "text": "

https://html.spec.whatwg.org/multipage/input.html#email-state-(type=email)

", "time": "2022-07-26T18:16:26Z"}, {"author": "John Levine", "text": "

A valid email address is a string that matches the email production of the following ABNF, the character set for which is Unicode. This ABNF implements the extensions described in RFC 1123. [ABNF] [RFC5322] [RFC1034] [RFC1123]

\n

email = 1*( atext / \".\" ) \"@\" label *( \".\" label )
\nlabel = let-dig [ [ ldh-str ] let-dig ] ; limited to a length of 63 characters by RFC 1034 section 3.5
\natext = < as defined in RFC 5322 section 3.2.3 >
\nlet-dig = < as defined in RFC 1034 section 3.5 >
\nldh-str = < as defined in RFC 1034 section 3.5 >

", "time": "2022-07-26T18:16:45Z"}, {"author": "John Levine", "text": "

This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the \"@\" character), too vague (after the \"@\" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

", "time": "2022-07-26T18:17:42Z"}, {"author": "John Levine", "text": "

The following JavaScript- and Perl-compatible regular expression is an implementation of the above definition.

\n

/^[a-zA-Z0-9.!#$%&'*+\\/=?^_`{|}~-]+@a-zA-Z0-9?(?:\\.a-zA-Z0-9?)*$/

", "time": "2022-07-26T18:18:03Z"}, {"author": "John Klensin", "text": "

Any advice beyond what Barry just described is also significantly out of scope of this WG as now defined

", "time": "2022-07-26T18:19:28Z"}, {"author": "Murray Kucherawy", "text": "

That regex for JS and Perl is better than what I expected. It allows \"+\" at least.

", "time": "2022-07-26T18:24:50Z"}, {"author": "John Klensin", "text": "

Emphatic +1 to Barry's \"ya\"

", "time": "2022-07-26T18:27:49Z"}, {"author": "Pete Resnick", "text": "

I am always happy with not dealing with it.

", "time": "2022-07-26T18:28:42Z"}, {"author": "Murray Kucherawy", "text": "

That's Pete's standard NomCom feedback about me as well.

", "time": "2022-07-26T18:29:06Z"}, {"author": "Murray Kucherawy", "text": "

The IESG is happy not dealing with it. ;)

", "time": "2022-07-26T18:31:19Z"}]