Advice against using URL %-encoding on non ASCII email addresses to create ASCII version of them

[aamelnikov]

John Klensin wrote:

Also, given [mis]behavior seen in the wild, does that paragraph (or an A/S) need
an explicit caution about SMTP servers or clients assuming they can
apply the popular web convention of using %NN sequences as a way
to encode non-ASCII characters (<pct-encoded> in RFC 3986) and
assuming some later system will interpret it as they expect?

[toddherr]

Levine to provide note re: punycode to expand text in 4.2 in A/S

Ask on list if section 4.2 in the A/S addresses this

[toddherr]

From Levine...

Current text:

4.2. Use of non-ASCII Characters

Proper generation and transmission of email addresses containing non-ASCII characters is discussed in [RFC6530]. SMTP clients and servers that attempt to use the popular web convention of Percent-Encoding non-ASCII characters (see Section 2.1 of [RFC3986]) SHALL NOT assume that a downstream system will interpret the email address accordingly without prior knowledge.

Proposed text to replace the above:

Proper generation and transmission of email addresses containing non-ASCII characters is discussed in [RFC6530]. Section 9 of [RFC6530] says: "a downgrade mechanism that transforms the local part of an email address cannot be utilized in transit." Hence SMTP clients and servers MUST NOT try to encode non-ASCII email addresses as ASCII addresses. In particular, they MUST NOT use web URI percent encoding (see Section 2.1 of [RFC3986]) nor Internationalized Domain Names for Applications punycode (see section 4.4 of [RFC5891]) since neither will produce a valid address.

In some cases, servers or clients may be able to use local knowledge to substitute ASCII addresses for specific non-ASCII addresses, but that is beyond the scope of this memo. See Section 8 of [RFC6530] for further discussion.

[toddherr]

Final text, per thread started here - https://mailarchive.ietf.org/arch/msg/emailcore/1qJu66_6bCMuO5HtQPWj8Iw4dAk/

Proper generation and transmission of email addresses containing non-ASCII
characters is discussed in [RFC6530]. Section 9 of [RFC6530] says: "a
downgrade mechanism that transforms the local part of an email address
cannot be utilized in transit." Hence SMTP clients and servers MUST NOT
try to encode non-ASCII email addresses as ASCII addresses. In particular, 
they MUST NOT use web URI percent encoding (see Section 2.1 of [RFC3986]) 
nor Internationalized Domain Names for Applications (IDNA)  (see section 4.4 
of [RFC5891]) Punycode [RFC3492] in the local-part of an address, nor the 
former in the domain-part, since neither will produce a valid address.

In some cases, servers or clients may be able to use local knowledge to
substitute ASCII addresses for specific non-ASCII addresses, but that is
beyond the scope of this memo. See Section 8 of [RFC6530] for further
discussion.

[ksmurchison]

Applied the above text to draft -10.