Additional examples consistent with RFC-5321 Mailbox grammar.

[gene-hightower]

No description provided.

[gene-hightower]

I think these tests are consistent with the 2020-12 draft that specifically references RFC-5321 Mailbox syntax as the basis for validation.

The review was incorrect.

[Julian]

Sounds like @awwright is happy with these -- can you add them to draft-next too? And sorry about the delay.

[gene-hightower]

Sounds like @awwright is happy with these -- can you add them to draft-next too? And sorry about the delay.

Is this something I should do? Not sure how, don't see any draft-next stuff... Happy to do whatever if somebody shows me how.

[Julian]

Yes! Essentially just add the same test cases to https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/tests/draft-next/optional/format/email.json -- let me know if you still need more guidance, apologies for the terseness!

[awwright]

There's a few more tests that I could suggest here, for example [email protected]. should be invalid (trailing dot, a valid domain name but illegal in an email address). But we can merge those in after this, if we have to.

[gene-hightower]

let me know if you still need more guidance, apologies for the terseness!

I hope this is right, let me know if you need anything else. I'm happy about this!

[awwright]

Is it possible to rebase or squash this PR? I'm not sure why it's pulling in 105 commits, that's a little confusing.

[gene-hightower]

Is it possible to rebase or squash this PR? I'm not sure why it's pulling in 105 commits, that's a little confusing.

Yeah, sorry about that. How about all in one commit?

[gene-hightower]

Is there anything more I can do to help get this merged?

[Julian]

Thanks, looks great! Sorry it took so long :(

[karenetheridge]

The format vocabulary didn't change in draft2020-12 -- so shouldn't these tests also appear for earlier drafts as well?

[Julian]

I took

that specifically references RFC-5321 Mailbox syntax

to mean that what changed was whether an explicit reference was there or not -- but if that's present in earlier drafts as well then yes!

[gene-hightower]

In the September 2019 draft, Email Addresses (section 7.3.2) looked like "email: As defined by [RFC 5322, section 3.4.1]".
But the RFC-5322 spec is for the message format, not the SMTP protocol. And that document is a bit ambiguous about allowing all kinds of white space and/or comments (in parens) which can be recursively nested.
It merely says "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec." But it allows leading and trailing comments or (folding) white space. (Also "SHOULD NOT" is not "MUST NOT")

For example, the grammar in RFC-5322 would accept < (comment) [email protected] (another (nested) comment) >

And if you ignore SHOULD NOT, you can mix in more comments and white space. RFC-5322 also requires support of the "Obsolete Syntax" to be compatible all the way back to RFC-822. It was kind of a nightmare.

[gene-hightower]

An example email address pulled from RFC-822 (section 3.1.4 on page 7) looks like:
<Muhammed.(I am the greatest) Ali @(the)Vegas.WBA>
I'm pretty sure nobody wants to allow this kind of address in their web forms.

[gene-hightower]

The domain part of the address as defined by RFC-5322 allows all kinds of craziness that is not acceptable by DNS as a domain, see section 3.2.3. for the definition of dot-atom. Using only the grammar from RFC-5322 a valid email address can be:

<foo@$$$$.$$$$> or <bar@----->

[karenetheridge]

Ah okay, I recall the change of RFCs in the specification revision, but at the time I thought that it was a typo correction of id numbers, not an actual intended behavioural change.

[awwright]

An example email address pulled from RFC-822 (section 3.1.4 on page 7) looks like: <Muhammed.(I am the greatest) Ali @(the)Vegas.WBA> I'm pretty sure nobody wants to allow this kind of address in their web forms.

This section is describing how you can encode a mail message, the parenthesized expressions are comments, they're not actually a part of the email address.

The domain part of the address as defined by RFC-5322 allows all kinds of craziness that is not acceptable by DNS as a domain

This is done for forward compatibility. This isn't really a problem because it's just handled the same as a domain name that isn't registered.

[gene-hightower]

@awwright The question is what should be considered a valid email address as far as JSON schema validation is concerned? A string with the spaces and (possibly nested) comments that would have to be stripped out before using in the SMTP protocol? I argued (successfully) that to be considered a valid address, the string should conform to the grammar in RFC-5321; the specification of the SMTP protocol. This way the string could be used directly, without further processing, to send email in today's Internet. So [email protected] -- not the string <Muhammed.(I am the greatest) Ali @(the)Vegas.WBA> which will be rejected by every MTA software program I know of.

That's why the spec was changed, and why the examples I have added should work with current versions of the JSON schema validation document.

[awwright]

@gene-hightower I would not expect comments, obsolete forms, or SHOULD NOT forms to be acceptable. If you can improve the wording in the spec, go ahead and file an issue over there with your suggestion.

[Julian]

(As a general rule, things which are SHOULD NOT are accepted / marked valid in the test suite, with an optional test suite file marking them invalid, until/unless they become MUST NOT)

[gene-hightower]

Right, so none of this is an issue as JSON Schema Validation now uses the Mailbox grammar of RFC-5321 as the basis for validation and not RFC-5322. The Mailbox grammar of RFC-5321 does not allow comments, or folding white-space, or domains inconsistent with DNS domains.
The spec is good now, no need to fix it. I was just providing some history and context about why these tests apply only to newer versions of the spec.