diff options
author | Christian Grothoff <christian@grothoff.org> | 2019-09-27 12:34:57 +0200 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2019-09-27 12:34:57 +0200 |
commit | d65d11702d7c96228f2d07149809c4d414bc5698 (patch) | |
tree | 3e4ba468b630902ae39503cbdc3921911465f4a4 | |
parent | 5a7d3d0631bc9a34496cc5950f4b6c66be044234 (diff) | |
download | marketing-d65d11702d7c96228f2d07149809c4d414bc5698.tar.gz marketing-d65d11702d7c96228f2d07149809c4d414bc5698.tar.bz2 marketing-d65d11702d7c96228f2d07149809c4d414bc5698.zip |
address comments by Adrian Farrel (ISE)
-rw-r--r-- | sa/sa.tex | 28 | ||||
-rw-r--r-- | standards/draft-dold-payto.xml | 44 |
2 files changed, 58 insertions, 14 deletions
@@ -532,6 +532,23 @@ support from INRIA, the French national institute for research in computer security (\url{https://www.inria.fr/}) and the Free Software community (\url{https://www.gnu.org/}). The company is privately owned and debt-free. +In response to the SARB's tender, Taler Systems SA has established +partnerships with Community-Exchange Systems NPC (CES) and JumpingBean INC +(JBI) from South Africa to jointly pursue this opportunity. +The Memorandum of Understanding between the companies is included in our +application materials. + +CES and JBI will provide community support, local developers and their general +expertise in the area of payment systems and software integration to the +project. The consortium plans to jointly work on integrating Taler with the +SARB's banking systems, and also offer integration support for the broader +e-commerce sector in SA. + +Taler Systems SA will focus on providig technical support for CES and JBI to +the best of its ability. In particular, Taler Systems SA will freely share +all of its documentation, code and technical expertise with its partners, +holding nothing back. Furthermore, Taler Systems SA will evolve the core +implementation to support SARB requirements to the extent this is feasible. % FIXME: Leon @@ -625,6 +642,17 @@ Our advisory board members are: \item[Dr. Edgar FLEISCH] Professor of Information Management, ETH Z\"urich \end{description} +CES is operating a global network of regional community payment systems +based on software originally developed by Tim Jenkin, who will work with +the project in his capacity as director of CES. Tim Jenkin will also bring +in his network of contacts and developers in SA to support the project. + +JBI is a Free Software consultancy based in SA focusing on providing +integration solutions for e-commerce. They are ideally suited for assisting +us onboard businesses in SA to the GNU Taler platform. Mark Clarke also has a +network of contacts in SA to bring in further support for the project if +required. + \subsection{Commentary on the CBDC principles and attributes} diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml index dc06793..8ed4f11 100644 --- a/standards/draft-dold-payto.xml +++ b/standards/draft-dold-payto.xml @@ -110,7 +110,7 @@ <section anchor="semantics" title="Semantics"> <t> The authority component of a payment URI identifies the payment target type. The - payment target types are defined in the "Payment Target Types" registry, see <xref + payment target types are defined in the "Payment Target Types" sub-registry, see <xref target="payto-registry" />. The path component of the URI identifies the target for a payment as interpreted @@ -127,7 +127,7 @@ banking application) to choose which account to pay with. An application SHOULD allow dereferencing a payto URI even - if the payment target type of that URI is not registered in the "Payment Target Types" registry. + if the payment target type of that URI is not registered in the "Payment Target Types" sub-registry. Details of the payment MUST be taken from the path and options given in the URI. The user SHOULD be allowed to @@ -233,20 +233,32 @@ essential for an application to conduct a payment. <section anchor="iana" title="IANA Considerations"> +IANA maintains a registry called the "Uniform Resource Identifier +(URI) Schemes" registry. + <section anchor="payto-uri" title="URI Scheme Registration"> <t> - The "payto" URI scheme is already registered in the "Provisional URI Schemes" registry <xref target="RFC7595" />. +IANA maintains a sub-registry of the "Uniform Resource Identifier +(URI) Schemes" registry also called the "Uniform Resource Identifier +(URI) Schemes" registry. The "payto" URI scheme is already +registered in this sub-registry with status set to "provisional" +<xref target="RFC7595" />. + +IANA is requested to update the reference for the "payto" URI scheme +to reference the RFC number of this document when it is published as +an RFC. </t> </section> <!-- see https://tools.ietf.org/html/rfc5226#section-4.1 --> -<section anchor="payto-registry" title="Payment Target Type Registry"> +<section anchor="payto-registry" title="Payment Target Type Sub-Registry"> <t> -This document defines a registry for payment methods. The name of the registry -is "Payment Target Types". +IANA is requested to create a new sub-registry of the "Uniform +Resource Identifier (URI) Schemes" registry called the "Payment +Target Types" registry with this document as the reference. </t> -<t>The registry shall record for each entry: +<t>The sub-registry shall record for each entry: <list style="symbols"> <t>Name: The name of the payment target type (case insensitive ASCII string, restricted to alphanumeric characters, dots and dashes)</t> @@ -256,7 +268,7 @@ dots and dashes)</t> <t>References: Optionally, references describing the payment method (such as an RFC) and method-specific options, or references describing the payment system underlying the payment target type.</t> </list> - The registration policy for this registry is "First Come First Served", as described in <xref target="RFC5226" />. + The registration policy for this sub-registry is "First Come First Served", as described in <xref target="RFC5226" />. When requesting new entries, careful consideration of the following criteria is strongly advised: <list style="numbers"> @@ -273,6 +285,9 @@ When requesting new entries, careful consideration of the following criteria is payment processor or bank beyond a simple payment.</t> <t>The payment target and the options do not contain the payment sender's account details.</t> </list> + +IANA is requested to populate the new sub-registry with the entries +documented in the following sub-sections. </t> <section anchor="registry-entry-ach" title="ACH Bank Account"> @@ -282,7 +297,7 @@ When requesting new entries, careful consideration of the following criteria is <t>Description: Automated Clearing House. The path consist of two components, the routing number and the account number.</t> <t>Example: payto://ach/122000661/1234</t> <t>Contact: N/A</t> -<t>References: <xref target="NACHA" /></t> +<t>References: <xref target="NACHA" />, [this.I-D]</t> </list> </t> </section> @@ -294,7 +309,7 @@ When requesting new entries, careful consideration of the following criteria is <t>Description: Business Identifier Code. The path consist of just a BIC. This is used for wire transfers between banks. The registry for BICs is provided by SWIFT. The path does not allow specifying a bank account number.</t> <t>Example: payto://bic/SOGEDEFFXXX</t> <t>Contact: N/A</t> -<t>References: <xref target="BIC" /></t> +<t>References: <xref target="BIC" />, [this.I-D]</t> </list> </t> </section> @@ -315,7 +330,7 @@ When requesting new entries, careful consideration of the following criteria is payto://iban/SOGEDEFFXXX/DE75512108001245126199 </t> <t>Contact: N/A</t> -<t>References: <xref target="ISO20022" /></t> +<t>References: <xref target="ISO20022" />, [this.I-D]</t> </list> </t> </section> @@ -328,7 +343,7 @@ When requesting new entries, careful consideration of the following criteria is options are mandatory for this payment target.</t> <t>Example: payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200</t> <t>Contact: N/A</t> -<t>References: <xref target="UPILinking" /></t> +<t>References: <xref target="UPILinking" />, [this.I-D]</t> </list> </t> </section> @@ -340,7 +355,7 @@ options are mandatory for this payment target.</t> <t>Description: Bitcoin protocol. The path is a "bitcoinaddress" as per <xref target="BIP0021" />.</t> <t>Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu</t> <t>Contact: N/A</t> -<t>References: <xref target="BIP0021" /></t> +<t>References: <xref target="BIP0021" />, [this.I-D]</t> </list> </t> </section> @@ -352,7 +367,7 @@ options are mandatory for this payment target.</t> <t>Description: Interledger protocol. The path is an ILP address as per <xref target="ILP-ADDR" />.</t> <t>Example: payto://ilp/g.acme.bob</t> <t>Contact: N/A</t> -<t>References: <xref target="ILP-ADDR" /></t> +<t>References: <xref target="ILP-ADDR" />, [this.I-D]</t> </list> </t> </section> @@ -566,6 +581,7 @@ options are mandatory for this payment target.</t> </references> <!-- Change Log +v08 2019-09-27 CG Clarify use of sub-registry as per draft-ise-iana-policy v05 2019-05-20 CG Addressing coments, preparing for independent stream submission, adding BIC v01 2017-02-15 CG References and formatting v01 2017-02-13 CG Minimal clarifications |