a...@gulbrandsen.priv.no wrote: > I will reply properly when I am back at my keyboard this weekend. Just one > thing now: the two extensions are subtly but crucially incompatible. > > Nothing in 653x requires a receiver to support idna (or a-label encoding of > local parts), or to treat them the same way as u-labels. The sender has to > chose encoding without knowledge of what the receiver supports, and quite > often the sender cannot even open a TCP connection to church since there is > a spam filter provider in the way. > > BTW, idna does not specify how a-labels work for local parts, and there are > two different implementations around, xn-- and xl--.
Hi Arnt, I fear there is some confusion or miscommunication going on here. I was and am referring to the IDNA implementation for *domains* (rfc589x, where the A-labels are defined using the "xn--" ACE prefix and are only applied to each label within the domain part). This is how mutt is currently using it, and as I quoted from rfc6531, seems to be compatible with the 653x series. Perhaps you thought I was making an argument to use IDNA for the local/mailbox part, which I am not. I haven't read about the xl-- prefix but can't find any mention of it in the rfc589x series. My point is merely that rfc589x (applied to the *domain* part of the address) seems to be completely compatible with rfc653x applied to the local/mailbox part of the address. Therefore I don't see why we have to remove it from Mutt or require it be disabled when 653x is in use. Hopefully that makes my point clearer. If not, or you still disagree, please let me know exactly how they are incompatible. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt
signature.asc
Description: PGP signature
