summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2019-09-27 12:34:57 +0200
committerChristian Grothoff <christian@grothoff.org>2019-09-27 12:34:57 +0200
commitd65d11702d7c96228f2d07149809c4d414bc5698 (patch)
tree3e4ba468b630902ae39503cbdc3921911465f4a4
parent5a7d3d0631bc9a34496cc5950f4b6c66be044234 (diff)
downloadmarketing-d65d11702d7c96228f2d07149809c4d414bc5698.tar.gz
marketing-d65d11702d7c96228f2d07149809c4d414bc5698.tar.bz2
marketing-d65d11702d7c96228f2d07149809c4d414bc5698.zip
address comments by Adrian Farrel (ISE)
-rw-r--r--sa/sa.tex28
-rw-r--r--standards/draft-dold-payto.xml44
2 files changed, 58 insertions, 14 deletions
diff --git a/sa/sa.tex b/sa/sa.tex
index 307d2eb..d7da13d 100644
--- a/sa/sa.tex
+++ b/sa/sa.tex
@@ -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&amp;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