Sorry, this message makes no sense. The IETF has been working on
non-ASCII domain names and e-mail for over a decade, and we are certainly
not going to do random things that ignore that effort and the many RFCs
that describe the use of IDNs in the DNS.
R's,
John
On Tue, 19 Apr 2011, Douglas Otis wrote:
On 4/15/11 7:25 PM, John R. Levine wrote:
Instead, conversion to A-label form, or any other special encoding
required by a particular name-lookup protocol, should be done only by
an entity that knows which protocol will be used (e.g., the DNS
resolver, or getaddrinfo() upon deciding to pass the name to DNS),
rather than by general applications that call protocol-independent
name resolution APIs.
Wow. This change would both be incompatible with 4871, and would put
non-ASCII 8-bit characters into DKIM-Signature: headers, thereby making
them invalid under RFC 5322 and getting them smashed by any 7bit MTA.
A and AAAA records serve as a discovery mechanism for SMTP rather than using
MX records to ensure independence from DNS. For both OS X and Windows local
name resolution services use UTF-8. Should email be expected to work between
two hosts having non-ASCII host names resolved using UTF-8?
When SMTP allows the display of non-ASCII local-parts, the domain portion
should also use UTF-8 as well. The DKIM verification process should therefore
confirm the proper conversions. No one expects people to visually validate
signatures, so why expect them to also validate puny-codes?
What does http://tools.ietf.org/html/rfc5321#section-2.3.5 say about FQDN.
Would http://バスケ指導.meblog.biz/ qualify as a FQDN?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html