I assumed that the question being asked was is the style with ASCII quotes legal.
If the question involves the use of the non-ASCII quoting style, the answer is more muddled. RFC 6531 generally repeats the RFC 5321 mantra of "don't interpret the local-part", prohibiting only ASCII C0 control codes explicitly [1]. RFC 6530 suggests that C1 control codes should also be prohibited, and suggests that non-NFC is highly likely to cause problems. It further suggests that NFKC-normalized and excluding punctuation and whitespace is risky.
In general, a lot of email address handling advice requires ignoring what the dictums of the RFCs state. You should treat email addresses as case-preserving (i.e., compare ignoring case but don't change the case), and it's inadvisable to have a case-sensitive email server. Similarly, quoted local parts and domain literals should be rejected by almost all software that's not in the guts of the email system. Extending similar rules to EAI is difficult because it's unclear how the system will work in practice, but my libraries start by force-converting the localpart to NFC.
[1] The actual text is "ASCII graphics or control characters." This could be interpreted to mean "(ASCII graphics) or (control characters)" or "ASCII (graphics or control characters)." Given the text of RFC 6530, assuming that C1 is forbidden should generally be a safe assumption.
If the question involves the use of the non-ASCII quoting style, the answer is more muddled. RFC 6531 generally repeats the RFC 5321 mantra of "don't interpret the local-part", prohibiting only ASCII C0 control codes explicitly [1]. RFC 6530 suggests that C1 control codes should also be prohibited, and suggests that non-NFC is highly likely to cause problems. It further suggests that NFKC-normalized and excluding punctuation and whitespace is risky.
In general, a lot of email address handling advice requires ignoring what the dictums of the RFCs state. You should treat email addresses as case-preserving (i.e., compare ignoring case but don't change the case), and it's inadvisable to have a case-sensitive email server. Similarly, quoted local parts and domain literals should be rejected by almost all software that's not in the guts of the email system. Extending similar rules to EAI is difficult because it's unclear how the system will work in practice, but my libraries start by force-converting the localpart to NFC.
[1] The actual text is "ASCII graphics or control characters." This could be interpreted to mean "(ASCII graphics) or (control characters)" or "ASCII (graphics or control characters)." Given the text of RFC 6530, assuming that C1 is forbidden should generally be a safe assumption.