[GNUnet-SVN] [taler-marketing] branch master updated: address comments by Adrian Farrel (ISE)

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new d65d117  address comments by Adrian Farrel (ISE)
d65d117 is described below

commit d65d11702d7c96228f2d07149809c4d414bc5698
Author: Christian Grothoff <address@hidden>
AuthorDate: Fri Sep 27 12:34:57 2019 +0200

    address comments by Adrian Farrel (ISE)
---
 sa/sa.tex                      | 28 +++++++++++++++++++++++++++
 standards/draft-dold-payto.xml | 44 ++++++++++++++++++++++++++++--------------
 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/address@hidden?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

-- 
To stop receiving notification emails like this one, please contact
address@hidden.