On Mon, Mar 16, 2015 at 7:04 PM, John Levine <[email protected]> wrote:
> > The stuff in section 3 of the openpgpkey draft is trying to > canonicalize mailbox names, i.e., given some mailbox name, find the > "real" mailbox name that it corresponds to. > I think this can be summarized as a "publication vs discovery" problem. Keys get published in DNS at specific locations, corresponding to hashes of usernames. That is publication. The username-equivalence problem is a discovery problem. My suggestion is, standardize a PLACE (label) at which the email crowd can iteratively codify their equivalence rules. This puts the onus on them (the email folks), and gives them all the control they need. Publishing the applicable "rules" at a well-known location under a parent domain, facilitates discovery, without needing to implement anything within DNS. The specifics (what to codify and how to implement) are things the publishers (email providers and smtp providers) and the consumers (email clients) can work out, on their own and without involving the DNS folks. There is no specific need to uniqueness among the rules, even -- the same mapping could have more than one name/code-point, even if it is sub-optimal. E.g. different ISO-whatever country codes, might utilize the same mappings, and those mappings might also be shared by regional entities (like Quebec, or New Brunswick, in Canada). There may be a desire to have "vanity" names for the same mappings, e.g. GOOGLE and YAHOO. There may be related groups of rule sets, like GOOGLE_FR, GOOGLE_DE, where combinations of simple mappings are applied (lowercase, remove dots, trim +, and then apply language-specific mappings). We don't need (or want, IMHO) to develop those encodings, merely incorporate them by reference. (The email folks can fight those battles.) As an example, consider a new RRTYPE, of priority and rule, published at _mboxrule. _mboxcanon.example.com IN MBOXRULE 1 LC_ASCII _mboxcanon.example.com IN MBOXRULE 2 FR_CA_NOACCENT _mboxcanon.example.net IN MBOXRULE 1 NO_DOTS _mboxcanon.example.net IN MBOXRULE 2 NO_PLUS_SUFFIX 8 bits of priority, and 16 bits of enumerated rules (from an IANA table), is likely sufficient as a first cut, unless anyone has a better idea. (Suggestion: reserve some code points for experimental, and some for local use, however those might get implemented.) If a given domain has "fuzzy" stuff, then they still have the ABILITY to publish the same (user) keys at multiple hashed owner locations (equivalent usernames, e.g. firstname.lastname and 8-letter-username), for the enumerated variants. It does not need to be the case that the entire problem space be solved (all possible mailbox mappings). The ability to standardize and apply "sane" (well-defined, simple, context-free and content-agnostic) rules, might encourage adoption of such rules, and facilitate a sufficiently-high level of interop, as to justify deployment of these rules, and OPENPGPKEY & SMIME generally. > One new > problem (not the hardest) is that the case folding rules are language > specific -- the way you fold accented characters in Turkish is > different from the way you do it in French, and it's even different > between European French and Canadian French. You cannot tell by > looking at a mailbox name what language it is. > No, but if there is a well-known location that lists the applicable rules, you _can_ tell what those rules are, just by looking at that well-known (domain-wide) rule. The specifics of _what_ each rule is, and who is "authoritative" for a given rule, are thankfully out of scope for dnsop. Unless you are vastly smarter than everyone else who has looked at > this problem, you're not going to solve it any time soon. Every > approach suggested so far is something we're aware of and is known not > to work when applied to the complex mess that is Internet e-mail. If > you want to use hashes to represent mailbox names, you either have to > completely punt on variant names, which the users will hate, or stop > here, talk to people who understand the subtle reality of mail and see > if there's any way to come up with something that works. > I am suggesting we do both - punt on solving it, and providing just enough rope to the email community. _THE_ main thing is to recognize that there can be many case-folding rules, and that it does not need to be unified. At best, providing ways to publish the applicable set(s) of rules, and maybe a way to prioritize their use in case of conflicting elements within the rules, should be sufficient. I strongly suggest that those rules get published by the email folks, as an IANA registry or set of registries (well-known and local). > I realize this isn't what you want to hear, but you've dived into a > swamp. You may not recognize it as a swamp, but trust me, that's > where you are. > No, we are standing at the edge of the swamp, admiring the guts of those fighting the alligators. Brian
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
