- From: klensin via GitHub <sysbot+gh@w3.org>
- Date: Fri, 30 Sep 2022 01:28:12 +0000
- To: public-i18n-archive@w3.org
Sorry.. I did not read far enough. RFC 6068 does provide for percent-encoding domain names (which the IDNA specs consider bad practice) and local-parts. The latter gets UTF-8 and then %-encoding right. But its last sentence of Section 2, item 5, says "When a <local-part> containing non-ASCII characters will be used to compose a message, the <local-part> MUST be transformed to conform to whatever encoding may be defined in a future specification for the internationalization of email addresses." That "future specification" is the SMTPUTF8 documents and they, after extensive discussion in the WG, quite explicitly prohibit trying to encode local parts. The problem goes back to the email specs of the early 1980s and, IIR, somewhat earlier, when the local-part of an email address was specified as allowing absolutely any "printable" ASCII character although some specials and spaces had to be escaped. RFC 6068 correctly describes that situation but, once one moves past ASCII in the local part, not only is user%host@example.com a valid email address, but so is user%%whatever@example.com and user%25whatever@example.com: there is no way from looking at the things to know whether they are actual addresses or represent an encoded form that must be decoded (in case it isn't clear, user%%25whatever@example.com is a valid email address (not encoded) too. -- GitHub Notification of comment by klensin Please view or discuss this issue at https://github.com/w3c/bp-i18n-specdev/pull/80#issuecomment-1262999700 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 30 September 2022 01:28:14 UTC