On Tue, Mar 31, 2015 at 6:17 PM, John Levine <[email protected]> wrote: >>An alternative is to go back to the original base32 encoding, which >>is lossless,
> As far as I can tell, the base32 approach handles everything that > hashing does The draf, has a "characters/octets" conflation problem, as do the sequence of successors to RFC-822. This likely dates back to the before-UTF and before-IDNA era, and how the docs were updated. What is not clear to me, reviewing the updates over time, are the following: - when and why was the 64-length local-part introduced? (It appeared magically in RFC 2821 4.5.3.1) - when it changed from "64 characters" to "64 octets" in RFC 5321, this implicitly affected UTF-2/3/4 languages - was this impact considered? (In UTF, #characters is not automatically #octets.) - is the 64 octet limit sufficiently universally enforced to be considered an actual de-facto standard? - is it really the case that UTF-2 mailboxes are <= 32 characters, UTF-3 mailboxes <= 21 characters, and UTF-4 mailboxes <= 16 characters? Hashing, by definition, does not care about the length of local-part, and thus is less restrictive. In effect, it ignores that 64 character limit. (I'm not entirely sure if that is a pro, con, or irrelevant.) However, the _other_ issue is that the length of local-part _encoding_ implicitly limits the parent domain name length. Using 2 x 52-octet long labels, reduces the maximum domain name length to 255-106=149 octets, minus whatever the "_mailbox" label's length is, and is applicable to IDNA and non-IDNA domain names alike. Each A-label encoding of a multi-level name, eats 5 octets (xn-- plus the dot). At 3 labels , this becomes 125 octets of punycode. Dividing that by 2, 3, or 4 (for various UTF flavors) and then splitting that into 3 parts (one per label), runs the risk of running the host name out of characters. So, simply from an IDNA perspective, hashing is less restrictive (105 vs e.g. 56). Brian _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
