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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch