Should we us a URL PMI rather than a short-string

[mattsaxon]

Discussions at WG call suggested that use of short string was a 'bridging' technology and Google confirmed it would need a (small) change in the browser if we used a short-string.

We should therefore consider moving to URL.

However what would the URL be, more specifically, what domain would it be under?

[ianbjacobs]

-1 to a URL here for the reasons that AdrianHB cited on the call today - there is no need for one given that there is no authority that needs to publish a payment method manifest spec.

[mattsaxon]

So long as we can resolve the method for easily adding short string I don't disagree.

[CYV]

I understand the reason of AdrianHB... but maybe we could see from another angle. Is the basic-credit-transfer a specification to be used, that is "as is" or to be derived. for example, we could imagine, Sepa-credit-transfer, Swift-credit-transfer, fasterpayment-credit-transfer and so on. Thos different specs will be "almost" the same but dedicated and managed by the right authority. It could be easier for the consummer to understand and easier for the ecosystem to manage.

In my view, each authority should give the proper URL and not a short string.

[ianbjacobs]

Hi @CYV,

(We had similar discussions in the context of talking about gateway tokenization.)

One idea is for specific payment methods to refer to the basic credit transfer specification's data model (e.g., by extending or specializing it). That would foster some interoperability.

Ian

[mattsaxon]

There is nothing stopping people taking this spec as is and using the data structures. This would make this spec the equivalent of an abstract base class. I have no issue with that. Does everyone concur?