A/S should cover the use of email addresses in web forms

[ietf-svn-bot]

owner:alexey.melnikov@isode.com type_enhancement | by ned.freed@mrochek.com

---

Forms that accept email addresses are ubiquitous, but AFAIK we provide no guidance as to which of the various grammar elements defined in these specifications is appropriate for use as acceptance criteria for an email address. It would be helpful to clarify this, especially in regards to obsolete syntax.

---

Issue migrated from trac:51 at 2022-01-31 12:38:05 +0000

[aamelnikov]

I will suggest some text about allowed characters that must be supported

[ksmurchison]

@aamelnikov Can the A/S just refer to this spec or do we want actual text?

https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address

[ksmurchison]

Or I can use something like this:

   addr-spec-webform  =  local-part-webform "@" domain-webform

   localpart-webform  =  dot-atom-text

   domain-webform     =  subdomain-webform *( "." subdomain-webform )

   subdomain-webform  =  alphanum [ *61( alphanum / "-" ) alphanum ]

   alphanum           =  ALPHA / DIGIT

[aamelnikov]

Referencing WHATWG specification might be Ok, but we need to bring this to the mailing list for consensus call.

My personal opinion is that your version is worse than the WHATWG's, as it doesn't allow "+" or "=" in the local part.

[ksmurchison]

Yes it does:

atext = ALPHA / DIGIT / ; VCHAR characters not including "!" / "#" / ; specials. Used for atoms. "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "" / "{" / "|" / "}" / "~"

dot-atom-text = 1atext ("." 1*atext) `

[aamelnikov]

@ksmurchison Sorry, my mistake. You are correct.

[aamelnikov]

There were some discussions on the mailing list about various problematic cases (with John Levine). Do you think you can add something along those lines that we can further refine in London?

[ksmurchison]

@aamelnikov Reading through that thread now. Are those case ONLY in relation to web forms, or generally problematic?

[toddherr]

HTML spec says mail standards are wrong, and they won't change.

"What's there now (section 4.3) is as good as we're gonna get" - Levine during November 2023 interim

Discuss on list whether or not to close ticket.

[toddherr]

Thread started on November 30, 2023 yielded no opposition to closing - https://mailarchive.ietf.org/arch/msg/emailcore/hB8LxLz0mLD32E61rnVyd7-LZmM/

[toddherr]

In response to the on-list announcement on 3 January 2024 that this ticket would be closed, John Klensin responded thusly:

No objection to closing it, but two cautionary comments lest we
be surprised during IETF LC:

(1) The HTML spec also prohibits email addresses with non-ASCII
characters in the local-part.  5321bis and, to some extent,
5322bis try to dance rather carefully around that issue,
avoiding requiring or even authorizing SMTPUTF8 but pointing out
that such extensions may exist.  There is an ongoing discussion
between the i18n WG in W3C and the HTML ones in W3C and WHATWG
about fixing that and at least a few of us hope that serious
attention will be paid to the 5322bis (and earlier) definition
if <atext> will be included in the expected update.  That effort
is proceeding slowly, perhaps even more slowly than the work of
this WG but there is a real chance that the discussion of HTML
that is now in the A/S and connected to this ticket will be
changed out from under us before the A/S goes into IETF LC.

(2) There is an otherwise-unrelated spec that has been stuck in
the IESG for around nine months because it specified something
that the WHATWG folks indicated that they had no intention of
supporting.  I hope that will not be an issue for EMAILCORE work
Because email is less tied to web browsers, URIs, and their
behavior than that other spec, but, for those who either look at
user counts or who believe that nothing other than the web is
relevant at the applications layer, there could be some issues.

Again, none of the above suggests either text changes right now
or keeping the ticket open, but we should probably keep the
issues on our radar somehow.

[toddherr]

It was further later clarified on-list that the sentence

(1) The HTML spec also prohibits email addresses with non-ASCII
characters in the local-part.

applies to

the <input> element with an attribute
type="email", not about HTML in general, where the later would include
email addresses in free text, email addresses in a mailto: URI in
type="url", free-text input fields (type="text"), and so on.