commit 6c48e8535da56009c368ba7ed720830a69b60699
parent 3fe33190d282fa37c406f135fd646aab66e484a9
Author: Florian Dold <florian.dold@gmail.com>
Date: Thu, 28 Mar 2019 15:15:08 +0100
payto: add expert review (WIP)
Diffstat:
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
@@ -69,9 +69,9 @@
<section anchor="introduction" title="Introduction">
<t>
This document defines the 'payto' Uniform Resource Identifier (URI) <xref target="RFC3986" /> scheme
- for designating targets for payments. In its simplest form, a 'payto' URL
- identifies a payment target type and optionally a target identifier. Additional parameters,
- such as an amount or a payment reference, can be provided.
+ for designating transfer form data for payments. In particular, it always identifies the target of a payment.
+ A 'payto' URL consists of a payment target type, a target identifier and optional 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
@@ -80,7 +80,7 @@
<t>
A unified URI scheme for all payment target types
allows applications to offer user interactions with URIs that represent payment targets,
- without delay and churn when new payment systems are introduced.
+ simplifying the introduction of new payment systems and applications.
</t>
<t>
@@ -254,7 +254,7 @@ The "payto" URI scheme is to be registered in the "Permanent URI Schemes" regist
<section anchor="payto-registry" title="Payment Target Type Registry">
<t>
This document defines a registry for payment methods. The name of the registry
-is "Payment Target Type Registry".
+is "Payment Target Types".
</t>
<t>The registry shall record for each entry:
<list style="symbols">
@@ -265,7 +265,18 @@ dots and dashes)</t>
<t>Contact: The contact information of a person to contact for further information</t>
<t>References: Optionally, references describing the payment method (such as an RFC) and method-specific options</t>
</list>
-The registration policy for this registry is "First Come First Served", as described in <xref target="RFC5226" />.
+The registration policy for this registry is "expert review", as described in <xref target="RFC5226" />.
+The expert should be appointed by the IETF Indenpendent Stream Editor.
+
+The expert SHOULD check that
+* references clearly describe syntax and semantics of the payment target and optional parameters if applicable
+* appropriateness of the chosen payment target type name and (if applicable) vendor neutrality, specifically
+avoiding conflicts with well-known payment systems and names that have a potential to confuse users
+* compatibility of the payment target type specification with the this specification
+* the specifications of new payment target types remain within the scope of payment transfer form data. In particular
+specifying complete invoices is not in scope. Neither are processing instructions to the bank beyond a simple payment.
+* the optional parameters do not contain information that specifies the debitor's account details
+
</t>
<section anchor="registry-entry-ach" title="ACH Bank Account">
diff --git a/standards/rfc-ise.txt b/standards/rfc-ise.txt
@@ -4,6 +4,7 @@ Dear IS Editor,
This is a message for the submission of draft-dold-payto to the
independent stream. We intend this to be an experimental RFC.
+We believe Bernie discusses this already with you at IETF 104.
Previous drafts have seen review by the IETF communities, and we
addressed the various comments we have received. As no WG was
@@ -41,6 +42,9 @@ data. We believe this standard is urgently needed, and have had
discussions with various parties in the financial industry that support
this assertion. We also implemented this in our own payment system.
+Christian Grothoff is willing to serve as the first expert reviewer for the
+IANA registry.
+
The intended audience are thus developers for applications that deal
with payments and are seeking a simple standard for specifying wire
transfer information.
