email / idn-email: scope questions - 4.5.3.1 length limits and control / noncharacter codepoints

Two scope questions came up while adding idn-email tests. Both are about what the email / idn-email format should and should not check, and I would rather get a ruling than guess.

1. RFC 5321 section 4.5.3.1 length limits

The email format is the "Mailbox" ABNF (RFC 5321 section 4.1.2; RFC 6531 section 3.3 for idn-email). That grammar has no length limits. The 64-octet local part, 255-octet domain and 63-octet label limits live in section 4.5.3.1, which is about transport size limits, not the Mailbox grammar.

My reading is that format validation should follow the grammar and not enforce the 4.5.3.1 limits - a 65-octet local part would still be a valid email per section 4.1.2. Is that the intended scope, or should the suite test the 4.5.3.1 limits?

2. Control and noncharacter codepoints in the local part (idn-email)

RFC 6531 extends the local part with UTF8-non-ascii (any well-formed non-ASCII), and the "MUST NOT contain any of the ASCII graphics or control characters" clause only bars ASCII controls. By that text, a C1 control (U+0085) or a noncharacter (U+FFFF) is permitted in the local part.

RFC 6531 errata 4996 (Held) questions whether that clause was meant to exclude the 128-255 range too, so the wording is not fully settled. Should idn-email treat a C1 control / noncharacter in the local part as valid (the literal grammar reading) or invalid?

• RFC 5321 (sections 4.1.2 and 4.5.3.1): https://www.rfc-editor.org/rfc/rfc5321
• RFC 6531 section 3.3: https://www.rfc-editor.org/rfc/rfc6531#section-3.3
• RFC 6531 errata 4996: https://www.rfc-editor.org/errata/eid4996

Start by reviewing RFC 5321 sections 4.1.2 and 4.5.3.1, RFC 6531 section 3.3, and errata 4996. Resolve whether the email and idn-email tests should enforce transport length limits and reject C1 controls or noncharacters; done means the scope is decided and corresponding tests can be specified.