It's only 'valid' because of the particular decisions made by someone writing a random RFC. There's next to no reason to allow quoted strings, and even less reason to allow a different character set inside of them.

Email addresses do not need escape sequences.

Where do you draw the line? I occasionally have valid GMail addresses with "+" in them rejected because someone wrote a crappy validator.

Allow all the characters that are supposed to be valid outside of quotation marks. Letters, numbers, .!#$%&'*+-/=?^_`{|}~

That way if you don't mind letting through double periods or domain segments having more than 63 characters, you can validate an email with two character classes separated by an @. The basic regex looks like [xx]+@[yy]+

Doesn't this sort of RFC typically summarize and codify real-world usage, rather than coming up with new stuff? If a feature is in there, I'd have thought it's because somebody uses it.

At some point you just have to reach the level of "Yeah... don't do that." I would suspect have "@" as part of your email probably approaches that line.

It would be interesting to know the context. If this feature was already in a popular piece of software, then saying "don't do that" in your standard risks fragmenting things rather than codifying them, and that's no good either.

> It's only 'valid' because of the particular decisions made by someone writing a random RFC.

You know that's exactly what "valid" means, when talking about something standardized, right?

In HTML there's no reason to use " outside of an attribute value. Should browsers reject it?

I don't think gmail will let you register that email address.

Okay then, c."@"[email protected]