>One disadvantage of base32 is that it imposes new limits on the >length of the email address localpart, unless splitting into multiple >labels is introduced to handle longer inputs. Hashing imposes no >such limits.
If you'll review previous messages on this very topic, I proposed a base32 version that pads the local-part out to 64 bytes with 0xFF (a byte valid neither in ASCII nor UTF-8), splits it in half, and base32 encodes those as <highpart>.<lowpart>. This can encode any local-part, and is trivial to reverse. Since most local-parts are less than 32 bytes, a minor optimization is to omit the highpart if it's all FF. You can't use a base32 or base32hex encoding exactly like the one in RFC4648 since it uses = for padding, but you could leave out the padding since you know how long the result is supposed to be. It's ugly, but so what? Only machines are going to look at it. R's, John _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
