Reference RFC 6531 in email format validation

[Sintendo]

The "email" format explicitly references RFC 5322. We should consider referencing RFC 6531, so email addresses with non-ASCII characters can be recognized.

[awwright]

This looks correct at first glance, but RFC 6531 doesn't obsolete RFC 5322 so this is probably a little more involved than just replacing the references.

[epoberezkin]

I think there can be another format for such emails - there may be applications that do not allow non-latin characters in emails, so they would need the current definition...

For the reference, there was the conversation here: ajv-validator/ajv#434

[handrews]

@awwright would you prefer a separate format value for RFC 6531? @epoberezkin raised that in the Ajv issue that he linked to.

If I am reading RFC 6531, the part where it says that it does not modify RFC 5322 means that any email that is valid against RFC 5322 is also valid against RFC 6531. This feels analogous to URI vs IRI, though, and I would probably rather add "iri" and "iri-reference" instead of changing the meaning of "uri" and "uri-reference" so I guess I'm in favor of a separate keyword? (I'm going to file "iri[-reference]" if don't have that filed already...)

[handrews]

@Sintendo or anyone else: any preferences on a name for the additional format? "i18n-email"? "smtp-utf8"? Those are the first that come to mind after skimming a bit of RFC 6531

If someone can name this thing, I'm happy to include it in this draft. it fits our general desire to be all modern and stuff :-)

[Sintendo]

Both options look good to me. I think I prefer a name that still contains the text 'email' (that way it's more obvious that this new format is somehow related to the existing "email" format), so "i18n-email" gets my vote.

[Julian]

Can we just axe the email format instead :)

[handrews]

@Julian in all seriousness I think it would make sense to give implementations more flexibility about how formats are implemented. Saying "if you implement format at all, you have to implement all formats" sets a really high bar for formats. I feel like we don't have a good story for why format behaves the way it does.

It's partially an annotation (informing applications about usage without constraining what they do with that information) and partially this weird optional validation thing that doesn't really offer useful guarantees. I don't know that we need to change that (except perhaps the flexibility thing) but I think it needs better framing and more clarity around why anyone would or would not implement them.

See also #54 for another approach that I'd love more feedback on.

[handrews]

Apparently "IDN email" is the appropriate term. Or at least an appropriate term. So I'll go with "idn-email" as the format name, barring evidence to the contrary.

[handrews]

Merged #408.