Re: E-mail state

On Tue, Sep 8, 2009 at 8:31 AM, Julian Reschke<> wrote:
> "A valid e-mail address is a string that matches the ABNF production 1*(
> atext / "." ) "@" ldh-str 1*( "." ldh-str )  where atext is defined in RFC
> 5322 section 3.2.3, and ldh-str is defined in RFC 1034 section 3.5. [ABNF]
> [RFC5322] [RFC1034]"
> Any particular reason why this doesn't use the "domain" ABNF term from RFC
> 5322?

You mean, allowing whitespaces around the domain, allowing
domain-literal, and allowing some printable characters other than
letter/digit/hyphen (e.g. $, #, !, %, &, +, _, etc.) ?

> "This requirement is a willful violation of RFC 5322, which defines a syntax
> for e-mail addresses that is simultaneously too strict (before the "@"
> character), too vague (after the "@" character), and too lax (allowing
> comments, white space characters, and quoted strings in manners unfamiliar
> to most users) to be of practical use here."
> Using a grammar that only allows a subset of those strings allowed in EMail
> is not a "willful violation", but a profile.

It allows that RFC 5322 forbids (unless written as
".tom.", so it's not really a profile.

My take at it is that we shouldn't even reference RFC 5322 (apart for
the definition of "atext"). RFC 5322 doesn't AFAICT define a generic
syntax for e-mail addresses, but one for use in the specific case of
the "Internet Message Format"; it isn't even reused in SMTP (RFC 5321)
which defines its own local-part@domain rules.

...and AFAICT, the definition in HTML5 is equivalent to the one in RFC
5321 with one exception: HTML5 allows a "sub-domain" starting with an
hyphen (e.g.
Shouldn't HTML5 then instead borrow the local-name@domain definition
from RFC 5321? (with an eventual "willful violation" to allow
sub-domain starting with an hyphen)

(nota: RFC 5321 has the same definition of atext as RFC 5322 and the
same definition of ldh-str as RFC 1034)

Thomas Broyer

Received on Tuesday, 8 September 2009 09:43:44 UTC