Re: [dane] Payment association records

["John Levine" <[e-mail]>]

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