John, In the PMTA draft I offered the same locator approach as SMIMEA, however also mention that that is one of many possible means for locating the record. It is not hard to image use cases in which a recipient would want to expose multiple payment associations that don't necessarily correspond to a mailbox.
URI length: I initially wrote URI length as a one byte value however I was thinking about some of the REST entry points that I have seen that are pretty long. I am not married to a two byte length, just trying to anticipate the use cases - I am open to input from folks. IBAN sounds like a good idea. One of the things we wrestled with is do we write a completely generic draft that has no specific payment networks and then handle each payment network as a separate draft or do we take the approach that we ended up with and specify two examples to provide a concrete grounding for the record (simialr to the approach taken with TLSA). We decided that showing a crypto currency and non-crypto currency use case would get things rolling then subsequent payment networks could be added outside the draft. Do you feel IBAN should be an exemplar? I agree that we should add a few more fields - fully expect this to morph from 00 to 00+ that way :) Glen ________________________________________ From: John Levine [[email protected]] Sent: Thursday, March 12, 2015 5:07 PM To: [email protected] Cc: Wiley, Glen Subject: Re: [dane] Payment association records 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
