[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-marketing] branch master updated: my pass
|
From: |
gnunet |
|
Subject: |
[taler-marketing] branch master updated: my pass |
|
Date: |
Fri, 11 Sep 2020 21:16:29 +0200 |
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 a840892 my pass
a840892 is described below
commit a840892b84bfaf9ac121868b022b0ff9e96ae8a5
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Fri Sep 11 21:16:26 2020 +0200
my pass
---
standards/rfc8905-in-prep.xml | 159 ++++++++++++++++++++++--------------------
1 file changed, 83 insertions(+), 76 deletions(-)
diff --git a/standards/rfc8905-in-prep.xml b/standards/rfc8905-in-prep.xml
index fa1a3b8..b25bd2e 100644
--- a/standards/rfc8905-in-prep.xml
+++ b/standards/rfc8905-in-prep.xml
@@ -4,7 +4,7 @@
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"; docName="draft-dold-payto-14"
number="8905" ipr="trust200902" obsoletes="" updates=""
submissionType="independent" category="info" xml:lang="en"
- tocInclude="true" symRefs="true" sortRefs="true" version="3">
+ tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.44.0 -->
<front>
@@ -25,10 +25,10 @@
</address>
</author>
<author fullname="Christian Grothoff" initials="C." surname="Grothoff">
- <organization>BFH</organization>
+ <organization>Bern University of Applied Sciences</organization>
<address>
<postal>
- <street>Höheweg 80</street>
+ <street>Quellgasse 21</street>
<street/>
<city>Biel/Bienne</city>
<code>2501</code>
@@ -44,11 +44,11 @@
<keyword>payments</keyword>
<abstract>
<t>This document defines the 'payto' Uniform Resource Identifier (URI)
- scheme for designating targets for payments.</t>
+ scheme for designating targets for payments.</t>
<t>A unified URI scheme for all payment target types allows applications
to offer user interactions with URIs that represent payment targets,
simplifying the introduction of new payment systems and
- applications.</t>
+ applications.</t>
</abstract>
</front>
<middle>
@@ -56,30 +56,30 @@
<name>Introduction</name>
<t>This document defines the 'payto' Uniform Resource Identifier (URI)
<xref target="RFC3986" format="default"/> scheme for designating
- transfer form data for payments.</t>
+ transfer form data for payments.</t>
<section numbered="true" toc="default">
<name>Objective</name>
<t>A 'payto' URI always identifies the target of a payment. A 'payto'
URI
consists of a payment target type, a target identifier, and optional
- parameters such as an amount or a payment reference.</t>
+ parameters such as an amount or a payment reference.</t>
<t>The interpretation of the target identifier is defined by the
payment target type and typically represents either a bank account or
- an (unsettled) transaction.</t>
+ an (unsettled) transaction.</t>
<t>A unified URI scheme for all payment target types allows
applications to offer user interactions with URIs that represent
payment targets, simplifying the introduction of new payment systems
- and applications.</t>
+ and applications.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
- "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
+ "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
- "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
+ "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
- to be interpreted as
- described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
+ to be interpreted as
+ described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
@@ -87,7 +87,7 @@
<section anchor="syntax" numbered="true" toc="default">
<name>Syntax of a 'payto' URI</name>
<t>This document uses the Augmented Backus-Naur Form (ABNF) of <xref
- target="RFC5234" format="default"/>.</t>
+ target="RFC5234" format="default"/>.</t>
<sourcecode type="abnf" ><![CDATA[
payto-URI = "payto://" authority path-abempty [ "?" opts ]
opts = opt *( "&" opt )
@@ -107,8 +107,8 @@
<section anchor="semantics" numbered="true" toc="default">
<name>Semantics</name>
<t>The authority component of a payment URI identifies the payment
- target type. The payment target types are defined in the "Payment
- Target Types" subregistry (see <xref target="payto-registry"
+ target type. The payment target types are defined in the "Payto Payment
+ Target Types" registry (see <xref target="payto-registry"
format="default"/>). The path component of the URI identifies the target
for a payment as interpreted by the respective payment target type. The
query component of the URI can provide additional parameters for a
@@ -118,38 +118,23 @@
an application (if available) associated with the payment target type
that can initiate a payment.
-<!-- [rfced] Please clarify "each accessed the respective bank's banking
-application" in the parenthetical here. Is the intent "each accessed via
-the respective bank's banking application" (i.e., adding "via") or something
-similar?
-
-Original:
- This allows
- users with multiple bank accounts (each accessed the respective
- bank's banking application) to choose which account to pay with.
-
-Perhaps:
- This allows
- users with multiple bank accounts (each accessed via the respective
- bank's banking application) to choose which account to pay with.
--->
-
- If multiple handlers are registered for the
+ If multiple handlers are registered for the
same payment target type, the user <bcp14>SHOULD</bcp14> be able to
choose which application to launch. This allows users with multiple bank
- accounts (each accessed the respective bank's banking application) to
+ accounts (each accessed via the respective bank's banking application) to
choose which account to pay with. An application <bcp14>SHOULD</bcp14>
allow dereferencing a 'payto' URI even if the payment target type of that
- URI is not registered in the "Payment Target Types" subregistry. Details
+ URI is not registered in the "Payto Payment Target Types" registry.
Details
of the payment <bcp14>MUST</bcp14> be taken from the path and options
given in the URI. The user <bcp14>SHOULD</bcp14> be allowed to modify
- these details before confirming a payment.</t>
+ these details before confirming a payment.</t>
</section>
<section anchor="examples" numbered="true" toc="default">
<name>Examples</name>
<!-- [rfced] Please review the artwork element in the xml file. Specifically,
should this artwork element be tagged as <sourcecode>, <t>, or another
element?
+Answer-CG: <t> seems fine to me. Not really source.
-->
<artwork name="" type="" align="left" alt=""><![CDATA[
payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello
@@ -164,7 +149,7 @@ INVALID (authority missing): payto:iban/12345
once. Other options <bcp14>MAY</bcp14> be allowed multiple times, with
further restrictions depending on the payment target type. The following
options <bcp14>SHOULD</bcp14> be understood by every payment target
- type.</t>
+ type.</t>
<dl newline="false" spacing="normal">
<dt>amount:</dt>
@@ -188,22 +173,22 @@ INVALID (authority missing): payto:iban/12345
<dd>Name of the entity that receives the payment (creditor). The value of
this option <bcp14>MAY</bcp14> be subject to lossy conversion, modification,
and truncation (for example, due to line wrapping or character set
- conversion).</dd>
+ conversion).</dd>
<dt>sender-name:</dt>
<dd>Name of the entity that makes the payment (debtor). The value of this
option <bcp14>MAY</bcp14> be subject to lossy conversion, modification, and
truncation (for example, due to line wrapping or character set
- conversion).</dd>
+ conversion).</dd>
<dt>message:</dt>
<dd>A short message to identify the purpose of the payment. The value of
this option <bcp14>MAY</bcp14> be subject to lossy conversion, modification,
and truncation (for example, due to line wrapping or character set
- conversion).</dd>
+ conversion).</dd>
<dt>instruction:</dt>
<dd>A short message giving payment reconciliation instructions to the
recipient. An instruction that follows the character set and length
limitation defined by the respective payment target type <bcp14>SHOULD
- NOT</bcp14> be subject to lossy conversion.</dd>
+ NOT</bcp14> be subject to lossy conversion.</dd>
</dl>
</section>
<section anchor="encoding" numbered="true" toc="default">
@@ -223,7 +208,7 @@ INVALID (authority missing): payto:iban/12345
the userinfo component <xref target="RFC3986" format="default"/> is
disallowed in 'payto' URIs. Instead, the payment target identifier is
given as an option, where encoding rules are uniform for all
- options.</t>
+ options.</t>
<t>
Defining a generic way of tagging the language of option fields containing
natural
language text (such as "receiver-name", "sender-name", and "message)
@@ -235,41 +220,41 @@ INVALID (authority missing): payto:iban/12345
</section>
<section anchor="tracking" numbered="true" toc="default">
<name>Tracking Payment Target Types</name>
- <t> A registry of payment target types is described in <xref
+ <t> A registry of "Payto Payment Target Types" is described in <xref
target="payto-registry" format="default"/>. The registration policy for
this registry is "First Come First Served", as described in <xref
target="RFC8126" format="default"/>. When requesting new entries,
- careful consideration of the following criteria is strongly advised:</t>
+ careful consideration of the following criteria is strongly advised:</t>
<ol spacing="normal" type="1">
<li>The description clearly defines the syntax and semantics of the
- payment target and optional parameters if applicable.</li>
+ payment target and optional parameters if applicable.</li>
<li>Relevant references are provided if they are available.</li>
<li>The chosen name is appropriate for the payment target type, does
not conflict with well-known payment systems, and avoids potential to
- confuse users.</li>
+ confuse users.</li>
<li>The payment system underlying the payment target type is not
fundamentally incompatible with the general options (such as positive
- decimal amounts) in this specification.</li>
+ decimal amounts) in this specification.</li>
<li>The payment target type is not a vendor-specific version of a
payment target type that could be described more generally by a
- vendor-neutral payment target type.</li>
+ vendor-neutral payment target type.</li>
<li>The specification of the new payment target type remains within
the scope of payment transfer form data. In particular, specifying
complete invoices is not in scope. Neither are processing
instructions to the payment processor or bank beyond a simple
- payment.</li>
+ payment.</li>
<li>The payment target and the options do not contain the payment
- sender's account details.</li>
+ sender's account details.</li>
</ol>
<t>Documents that support requests for new registry entries should
- provide the following information for each entry:</t>
+ provide the following information for each entry:</t>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>The name of the payment target type (case-insensitive ASCII
string, restricted to alphanumeric characters, dots, and dashes).</dd>
<dt>Description:</dt>
<dd>A description of the payment target type, including the semantics
- of the path in the URI if applicable.</dd>
+ of the path in the URI if applicable.</dd>
<dt>Example:</dt>
<dd>At least one example URI to illustrate the payment target
type.</dd>
@@ -278,21 +263,21 @@ INVALID (authority missing): payto:iban/12345
<dt>References:</dt>
<dd>Optionally, references describing the payment target type (such as
an RFC) and target-specific options or references describing the
- payment system underlying the payment target type.</dd>
+ payment system underlying the payment target type.</dd>
</dl>
<t>This document populates the registry with seven entries as follows
(see
also <xref target="payto-registry" format="default"/>).</t>
<section anchor="registry-entry-ach" numbered="true" toc="default">
<name>ACH Bank Account</name>
<dl newline="false" spacing="normal">
- <dt>Name:</dt>
+ <dt>Name:</dt>
<dd>ach</dd>
<dt>Description:</dt>
<dd>Automated Clearing House (ACH). The path consists of two
components:
the routing number and the account number. Limitations on the length
and character set of option values are defined by the implementation
of the handler. Language tagging and internationalization of options
- are not supported.</dd>
+ are not supported.</dd>
<dt>Example:</dt>
<dd>payto://ach/122000661/1234</dd>
<dt>Contact:</dt>
@@ -311,7 +296,10 @@ INVALID (authority missing): payto:iban/12345
<!-- [rfced] Would it be helpful to include a citation in this sentence?
Original:
- The registry for BICs is provided by SWIFT.
+ The registry for BICs is provided by SWIFT.
+Answer-CG:
+ The best reference is [BIC], which is already under References. I see no
+ need to duplicate the reference in that sentence.
-->
<dd>Business Identifier Code (BIC). The path consists of just
@@ -321,7 +309,7 @@ Original:
bank account number. Limitations on the length and character set of
option values are defined by the implementation of the
handler. Language tagging and internationalization of options are not
- supported.</dd>
+ supported.</dd>
<dt>Example:</dt>
<dd>payto://bic/SOGEDEFFXXX
</dd>
@@ -338,28 +326,32 @@ Original:
<dd>iban</dd>
<dt>Description:</dt>
-<!-- [rfced] How may we clarify "allows to unambiguously derive" here?
+<!-- [rfced] How may we clarify "allows to unambiguously derive" here?
Original:
Generally the IBAN allows to unambiguously derive the the associated
- Business Identifier Code (BIC).
+ Business Identifier Code (BIC).
+Answer:
+ Extended sentence explaining how it is done. But largely this
+ is out of scope of the document.
-->
<dd>International Bank Account Number (IBAN). Generally, the IBAN
allows to unambiguously derive the associated Business
- Identifier Code (BIC). However, some legacy applications process
+ Identifier Code (BIC) using a lookup in the respective
+ proprietary translation table. However, some legacy applications process
payments to the same IBAN differently based on the specified BIC.
Thus, the path can consist of either a single component (the IBAN) or
two components (BIC followed by IBAN). The "message" option of the
'payto' URI corresponds to the "unstructured remittance information"
of Single Euro Payments Area (SEPA) credit transfers and is thus
- limited to 140 characters with
+ limited to 140 characters with
character set limitations that differ according to the countries of
the banks and payment processors involved in the payment. The
"instruction" option of the 'payto' URI corresponds to the "end-to-end
identifier" of SEPA credit transfers and is thus limited to, at most,
35 characters, which can be alphanumeric or from the allowed set of
special characters, i.e., "+?/-:().,'". Language tagging and
- internationalization of options are not supported.</dd>
+ internationalization of options are not supported.</dd>
<dt>Examples:</dt>
<dd><t>payto://iban/DE75512108001245126199</t><t>payto://iban/SOGEDEFFXXX/DE75512108001245126199</t>
</dd>
@@ -379,7 +371,7 @@ Original:
amount and receiver-name options are mandatory for this payment
target. Limitations on the length and character set of option values
are defined by the implementation of the handler. Language tags and
- internationalization of options are not supported.</dd>
+ internationalization of options are not supported.</dd>
<dt>Example:</dt>
<dd>payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200
</dd>
@@ -399,7 +391,7 @@ Original:
target="BIP0021" format="default"/>. Limitations on the length and
character set of option values are defined by the implementation of
the handler. Language tags and internationalization of options are
- not supported.</dd>
+ not supported.</dd>
<dt>Example:</dt>
<dd>payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu
</dd>
@@ -419,7 +411,7 @@ Original:
target="ILP-ADDR" format="default"/>. Limitations on the length and
character set of option values are defined by the implementation of
the handler. Language tagging and internationalization of options
- are not supported.</dd>
+ are not supported.</dd>
<dt>Example:</dt>
<dd>payto://ilp/g.acme.bob
</dd>
@@ -440,7 +432,7 @@ Original:
transactions). The path is optional and interpreted as a
comment. Limitations on the length and character set of option
values are defined by the implementation of the handler. Language
- tags and internationalization of options are not supported.</dd>
+ tags and internationalization of options are not supported.</dd>
<dt>Example:</dt>
<dd>payto://void/?amount=EUR:10.5
</dd>
@@ -457,21 +449,21 @@ Original:
<t>Interactive applications handling the 'payto' URI scheme <bcp14>MUST
NOT</bcp14> initiate any financial transactions without prior review and
confirmation from the user and <bcp14>MUST</bcp14> take measures to
- prevent clickjacking <xref target="HMW12" format="default"/>.</t>
+ prevent clickjacking <xref target="HMW12" format="default"/>.</t>
<t>Unless a 'payto' URI is received over a trusted, authenticated
channel,
a user might not be able to identify the target of a payment. In
particular, due to homographs <xref target="unicode-tr36"
format="default"/>, a payment target type <bcp14>SHOULD NOT</bcp14> use
human-readable names in combination with unicode in the target account
specification, as it could give the user the illusion of being able to
- identify the target account from the URI.</t>
+ identify the target account from the URI.</t>
<t>The authentication/authorization mechanisms and transport security
services used to process a payment encoded in a 'payto' URI are handled
by
- the application and are not in scope of this document.</t>
+ the application and are not in scope of this document.</t>
<t>To avoid unnecessary data collection, payment target types
<bcp14>SHOULD NOT</bcp14> include personally identifying information
about the sender of a payment that is not essential for an application
- to conduct a payment.</t>
+ to conduct a payment.</t>
</section>
<section anchor="iana" numbered="true" toc="default">
@@ -499,6 +491,9 @@ Template on https://www.iana.org/assignments/uri-schemes/:
Change controller: grothoff&gnu.org
References: See References section of RFC-dold-payto-14.
+
+Reply-CG:
+ I don't see a reason to duplicate it here.
-->
<name>IANA Considerations</name>
@@ -510,7 +505,7 @@ Template on https://www.iana.org/assignments/uri-schemes/:
</section>
<section anchor="payto-registry" numbered="true" toc="default">
- <name>Payment Target Types</name>
+ <name>Payto Payment Target Types</name>
<t>
This document specifies a list of payment target types. It is
possible that future work will need to specify additional payment
@@ -524,11 +519,11 @@ Template on https://www.iana.org/assignments/uri-schemes/:
string, restricted to alphanumeric characters, dots, and dashes)</dd>
<dt>Contact:</dt>
<dd>The contact information of a person to contact for further
- information</dd>
+ information</dd>
<dt>References:</dt>
<dd>Optionally, references describing the payment target type (such as
an RFC) and target-specific options or references describing the
- payment system underlying the payment target type</dd>
+ payment system underlying the payment target type</dd>
</dl>
<t>
The entries in the "payto-payment-target-types" registry
@@ -726,7 +721,7 @@ Perhaps:
<reference anchor="unicode-tr36">
<front>
<title abbrev="Unicode Security Considerations">Unicode Technical
- Report #36: Unicode Security Considerations</title>
+ Report #36: Unicode Security Considerations</title>
<author initials="M." surname="Davis" fullname="Mark Davis"
role="editor">
<address>
<email>markdavis@google.com</email>
@@ -815,14 +810,18 @@ Series. Please let us know which title, commit hash, and
date to use. In
addition, we suggest updating the URL in this reference entry to point to a
more direct URL. Would either of the following work?
-https://git.gnunet.org/gana.git/tree/payto-payment-target-types
+https://git.gnunet.org/gana.git/tree/payto-payment-target-types
or
-https://git.gnunet.org/gana.git/tree/payto-payment-target-types/registry.rec
+https://git.gnunet.org/gana.git/tree/payto-payment-target-types/registry.rec
Original:
[GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)",
April 2020, <https://gana.gnunet.org/>.
+Reply-CG:
+ The "git.gnunet.org" URL is only going to work as long as GANA uses the
+ GNUnet Git repository. Using the top-level alias is likely a more stable
+ URL. Finding the payto registry within GANA should be reasonably simple.
b) We see the following forms used for the title of the registry at
[GANA]. Should these be consistent? If so, please let us know which form to
@@ -830,6 +829,11 @@ use.
"Payment Target Types" sub-registry
"payto-payment-target-types” registry
+
+Reply-CG:
+ I have changed the text to always use "Payto Payment Target Types" registry
+ when referencing the registry at GANA.
+
-->
@@ -851,6 +855,9 @@ the right (i.e., the form with single quotes). Please let
us know any
objections.
payto vs. 'payto'
+
+Reply:
+ This is fine.
-->
</back>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-marketing] branch master updated: my pass,
gnunet <=