>> 1) Section 3, in case of EAI, it should specify the character encoding of >> the local-part on which to perform the SHA224 function.
Paul H is right. Regular mail addresses are 7-bit ASCII, and EAI is UTF-8. Those are the only two choices, and since ASCII is a subset of UTF-8, it's really only one choice. See RFC 6530. Section 3.1 seems very ill-advised -- it says the client probes for various addresses which might be the person you want, but might equally well be someone else if you guess wrong. While it is unusual for foobar@domain and FOOBAR@domain and foo.bar@domain to be different people, that is and always has been entirely valid. With + and - variants, there's no consistency at all. Nerds who are used to sendmail think it's normal for foo+bar to be a variant of foo, but the other 98% of the world doesn't. And some even use foo-bar as a variant of foo. My advice would be to remove all of the current text in 3.1 and replace it with a note that systems that publish records at names that are hashed mailboxes may publish CNAMEs for variant mailbox hashes that they consider to be equivalent. That's safe, since the party publishing the variants is the one that knows what they mean. It's also fairly hopeless once you get beyond folding stuff to lower case and stripping dots since the number of possibilities explodes. R's, John PS: If we have name variant rules, which I'm not at all sure we should, they really should be the same for OPENPGPKEY and SMIMEA and anything else that uses a hashed mailbox. This suggests if we go down that road, the name management belongs in a separate document from the definition of the RR type, and it needs attention from the SMTP crowd. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
