Subject: [dispatch] draft-dold-payto-04

From: Florian Dold <[email-masked]>
Date: Tue, 5 Mar 2019 14:22:56 +0100

Dear all,

We've updated the payto:// URI draft, based on the previous feedback on
this mailing list:

  https://datatracker.ietf.org/doc/draft-dold-payto/

After consulting with a domain expert for SEPA, we've also changed the
"sepa" payment target type into a more general "iban" target type (as
both SEPA and SWIFT use IBANs).  Now an IBAN  (International Bank
Account Number) can optionally be scoped within a BIC (Bank Identifier
Scope).

We'd be happy to hear more feedback on this decision.

We've tried to explain the question of "why does there need to be a
unified payto scheme, instead of many schemes for different payment
systems" in the introduction.  Various applications detect certain URIs
and make them interactive (mail clients, chat applications, ...).  When
there is one URI to address payment targets, adding a new payment system
does not require all these applications to be updated.  For smaller or
very regional payment systems, it might be impossible to get enough
recognition to be detected as clickable links in common applications
otherwise.

Additionally the "container format" addresses common issues like the
amount format, as well the distinction between a "message" for humans
and a machine-readable "instruction" that can't be subject to lossy
conversions.  Similarly, security and encoding considerations apply to
all payment target types.

Both authors will be present at IETF 104.  Would it be possible to
present/discuss this draft as part of the dispatch session there?

Best regards,
Florian

---

From: Ben Campbell <[email-masked]>
Date: Wed, 6 Mar 2019 14:15:29 -0600

Hi Florian,

(Apologies if I’m repeating something another AD may have already told you.)

The ART ADs have discussed this, and we wonder why this needs to be an IETF stream RFC.

The URI schemes registry is only “first come first serve” *FCFS) for provisional schemes. FCFS registration does not require an RFC.  I see that the draft requests a permanent scheme, however “permanent” status is not appropriate for a new scheme. The normal procedure is to register it as provisional, and later promote it to permanent if it sees widespread use.

Based on that, we don’t see the need to spend DISPATCH agenda time on it. Is there some reason that we are missing?

Thanks!

Ben.

> On Mar 5, 2019, at 7:22 AM, Florian Dold <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Mar 2019 23:08:17 -0500

>   https://datatracker.ietf.org/doc/draft-dold-payto/

Looking at draft-dold-payto-04, I see the BNF:

     opts = opt *( "&amp;" opt )

I suspect that "&amp;" is a remainder from some conversion process, and
you intend "&".

Also, in:

     opt = (generic-opt / authority-specific-opt) "=" *( pchar )

note that "&" is admissible in pchar because "&" is in sub-delims, which
makes parsing an opts difficult.  (Annoyingly, the current IETF BNF
doesn't seem to have a simple way of saying "a pchar that is not &".)

Dale