Interesting idea. One thing that immediately jumps out at me is that the DNS name token that is _pmta in this draft and _smimecert in the SMIMEA draft should really be _mailbox, since the DNS name corresponds to a mailbox, not a particular service. I don't think that affects the tree walk problem.
With respect to Warren's concern that a sleazy mailbox provider might publish bogus PMTA records -- they can read your mail. If they're going to do that, they can steal any account for which your mailbox gets password recovery mail, so that horse is, as they say, exfaenile. Concretely, I have a few nits. All the other strings I can think of in DNS records have one-byte lengths, so I'm wondering if you actually expect URI strings to be more than 255 bytes. For ACH transfers, I think it needs to include a an account type for personal/business checking/saving, but that's not a big deal. To be a little less provincial, add a payment system selector for IBANs. The data is an 11 character BIC (sometimes 8 characters followed by 3 spaces or within much of Europe, all blank) and a variable length IBAN of up to 34 characters. Something that we'll need to address is payment systems that handle more than one currency. American ACH transfers only work in US dollars and bitcoins only in bitcoins, but IBAN transfers can handle many different currencies. So if you are paying me in dollars, I want to you do an ACH transfer to my account in the US, but if you're paying me in pounds or anything else, do an IBAN transfer to my account in the UK. An obvious approach is to add a three character currency field and a flag saying whether transfers in other currencies are OK. If this sounds awfully complicated, yeah, payment systems are like that. R's, John _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
