commit f18a05423e5445a55921264fafb26374346eae25
parent c329b2dc6a183477c38e4e7cf293462441c2059c
Author: Florian Dold <florian.dold@gmail.com>
Date: Fri, 11 Sep 2020 17:38:41 +0530
add RFC in prep
Diffstat:
1 file changed, 857 insertions(+), 0 deletions(-)
diff --git a/standards/rfc8905-in-prep.xml b/standards/rfc8905-in-prep.xml
@@ -0,0 +1,857 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
+
+<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">
+
+ <!-- xml2rfc v2v3 conversion 2.44.0 -->
+ <front>
+ <title abbrev="The 'payto' URI Scheme">
+ The 'payto' URI Scheme for Payments
+ </title>
+ <seriesInfo name="RFC" value="8905"/>
+ <author fullname="Florian Dold" initials="F." surname="Dold">
+ <organization>Taler Systems SA</organization>
+ <address>
+ <postal>
+ <street>7, rue de Mondorf</street>
+ <city>Erpeldange</city>
+ <code>5421</code>
+ <country>Luxembourg</country>
+ </postal>
+ <email>dold@taler.net</email>
+ </address>
+ </author>
+ <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
+ <organization>BFH</organization>
+ <address>
+ <postal>
+ <street>Höheweg 80</street>
+ <street/>
+ <city>Biel/Bienne</city>
+ <code>2501</code>
+ <country>Switzerland</country>
+ </postal>
+ <email>christian.grothoff@bfh.ch</email>
+ </address>
+ </author>
+ <date month="September" year="2020"/>
+
+ <area>General</area>
+ <workgroup>Independent Stream</workgroup>
+ <keyword>payments</keyword>
+ <abstract>
+ <t>This document defines the 'payto' Uniform Resource Identifier (URI)
+ 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>
+ </abstract>
+ </front>
+ <middle>
+ <section anchor="introduction" numbered="true" toc="default">
+ <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>
+ <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>
+ <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>
+ <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>
+ </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
+ NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</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"/>
+ when, and only when, they appear in all capitals, as shown here.
+ </t>
+ </section>
+ </section>
+ <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>
+<sourcecode type="abnf" ><![CDATA[
+ payto-URI = "payto://" authority path-abempty [ "?" opts ]
+ opts = opt *( "&" opt )
+ opt-name = generic-opt / authority-specific-opt
+ opt-value = *pchar
+ opt = opt-name "=" opt-value
+ generic-opt = "amount" / "receiver-name" / "sender-name" /
+ "message" / "instruction"
+ authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." )
+ authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
+]]></sourcecode>
+ <t>
+ 'path-abempty' is defined in <xref target="RFC3986" sectionFormat="of" section="3.3"/>.
+ 'pchar' is defined in <xref target="RFC3986" sectionFormat="of" section="A"/>.
+ </t>
+ </section>
+ <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"
+ 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
+ payment. Every payment target type <bcp14>SHOULD</bcp14> accept the
+ options defined in generic-opt. The default operation of applications
+ that invoke a URI with the 'payto' scheme <bcp14>MUST</bcp14> be to launch
+ 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
+ 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
+ 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
+ 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>
+ </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?
+-->
+<artwork name="" type="" align="left" alt=""><![CDATA[
+payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello
+
+INVALID (authority missing): payto:iban/12345
+]]></artwork>
+ </section>
+ <section anchor="generic-options" numbered="true" toc="default">
+ <name>Generic Options</name>
+ <t>Applications <bcp14>MUST</bcp14> accept URIs with options in any
+ order. The "amount" option <bcp14>MUST NOT</bcp14> occur more than
+ 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>
+
+<dl newline="false" spacing="normal">
+ <dt>amount:</dt>
+ <dd><t>The amount to transfer. The format <bcp14>MUST</bcp14> be:</t>
+
+<sourcecode type="abnf"><![CDATA[
+ amount = currency ":" unit [ "." fraction ]
+ currency = 1*ALPHA
+ unit = 1*(DIGIT / ",")
+ fraction = 1*(DIGIT / ",")
+]]></sourcecode>
+ <t>If a 3-letter 'currency' is used, it <bcp14>MUST</bcp14> be an <xref
+ target="ISO4217" format="default"/> alphabetic code. A payment target
+ type <bcp14>MAY</bcp14> define semantics beyond ISO 4217 for currency
+ codes that are not 3 characters. The 'unit' value <bcp14>MUST</bcp14> be
+ smaller than 2^53. If present, the 'fraction' <bcp14>MUST</bcp14>
+ consist of no more than 8 decimal digits. The use of commas is optional
+ for readability, and they <bcp14>MUST</bcp14> be ignored.</t> </dd>
+
+ <dt>receiver-name:</dt>
+ <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>
+ <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>
+ <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>
+ <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>
+ </dl>
+ </section>
+ <section anchor="encoding" numbered="true" toc="default">
+ <name>Internationalization and Character Encoding</name>
+ <t>
+ Various payment systems use restricted character sets.
+ An application that processes 'payto' URIs <bcp14>MUST</bcp14> convert
+ characters that are not allowed by the respective payment systems
+ into allowable characters using either an encoding or a replacement table.
+ This conversion process <bcp14>MAY</bcp14> be lossy, except for the instruction field.
+ If the value of the instruction field would be subject to lossy conversion,
+ modification, or truncation,
+ the application <bcp14>SHOULD</bcp14> refuse further processing of the payment until a
+ different value for the instruction is provided.
+</t>
+ <t>To avoid special encoding rules for the payment target identifier,
+ 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>
+ <t>
+ Defining a generic way of tagging the language of option fields containing natural
+ language text (such as "receiver-name", "sender-name", and "message)
+ is out of the scope of this document, as internationalization must accommodate the restrictions
+ and requirements of the underlying banking system of the payment target type.
+
+ The internationalization concerns <bcp14>SHOULD</bcp14> be individually defined by each payment target type.
+</t>
+ </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
+ 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>
+ <ol spacing="normal" type="1">
+ <li>The description clearly defines the syntax and semantics of the
+ 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>
+ <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>
+ <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>
+ <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>
+ <li>The payment target and the options do not contain the payment
+ sender's account details.</li>
+ </ol>
+ <t>Documents that support requests for new registry entries should
+ 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>
+ <dt>Example:</dt>
+ <dd>At least one example URI to illustrate the payment target
+ type.</dd>
+ <dt>Contact:</dt>
+ <dd>The contact information of a person to contact for further 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>
+ </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>
+ <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>
+ <dt>Example:</dt>
+ <dd>payto://ach/122000661/1234</dd>
+ <dt>Contact:</dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd><xref target="NACHA" format="default"/>, RFC 8905</dd>
+ </dl>
+ </section>
+ <section anchor="registry-entry-bic" numbered="true" toc="default">
+ <name>Business Identifier Code</name>
+ <dl newline="false" spacing="normal">
+ <dt>Name:</dt>
+ <dd>bic</dd>
+ <dt>Description:</dt>
+
+<!-- [rfced] Would it be helpful to include a citation in this sentence?
+
+Original:
+ The registry for BICs is provided by SWIFT.
+-->
+
+ <dd>Business Identifier Code (BIC). The path consists of just
+ a BIC. This is used for wire transfers between banks. The registry
+ for BICs is provided by the Society for Worldwide Interbank
+ Financial Telecommunication (SWIFT). The path does not allow specifying a
+ 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>
+ <dt>Example:</dt>
+ <dd>payto://bic/SOGEDEFFXXX
+ </dd>
+ <dt>Contact:</dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd><xref target="BIC" format="default"/>, RFC 8905</dd>
+ </dl>
+ </section>
+ <section anchor="registry-entry-iban" numbered="true" toc="default">
+ <name>International Bank Account Number</name>
+ <dl newline="false" spacing="normal">
+ <dt>Name:</dt>
+ <dd>iban</dd>
+ <dt>Description:</dt>
+
+<!-- [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).
+-->
+ <dd>International Bank Account Number (IBAN). Generally, the IBAN
+ allows to unambiguously derive the associated Business
+ Identifier Code (BIC). 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
+ 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>
+ <dt>Examples:</dt>
+<dd><t>payto://iban/DE75512108001245126199</t><t>payto://iban/SOGEDEFFXXX/DE75512108001245126199</t>
+</dd>
+ <dt>Contact:</dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd><xref target="ISO20022" format="default"/>, RFC 8905</dd>
+ </dl>
+ </section>
+ <section anchor="registry-entry-upi" numbered="true" toc="default">
+ <name>Unified Payments Interface</name>
+ <dl newline="false" spacing="normal">
+ <dt>Name:</dt>
+ <dd>upi</dd>
+ <dt>Description:</dt>
+ <dd>Unified Payment Interface (UPI). The path is an account alias. The
+ 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>
+ <dt>Example:</dt>
+ <dd>payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200
+ </dd>
+ <dt>Contact:</dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd><xref target="UPILinking" format="default"/>, RFC 8905</dd>
+ </dl>
+ </section>
+ <section anchor="registry-entry-bitcoin" numbered="true" toc="default">
+ <name>Bitcoin Address</name>
+ <dl newline="false" spacing="normal">
+ <dt>Name:</dt>
+ <dd>bitcoin</dd>
+ <dt>Description:</dt>
+ <dd>Bitcoin protocol. The path is a "bitcoinaddress", as per <xref
+ 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>
+ <dt>Example:</dt>
+ <dd>payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu
+ </dd>
+ <dt>Contact:</dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd><xref target="BIP0021" format="default"/>, RFC 8905</dd>
+ </dl>
+ </section>
+ <section anchor="registry-entry-ilp" numbered="true" toc="default">
+ <name>Interledger Protocol Address</name>
+ <dl newline="false" spacing="normal">
+ <dt>Name:</dt>
+ <dd>ilp</dd>
+ <dt>Description:</dt>
+ <dd>Interledger protocol (ILP). The path is an ILP address, as per <xref
+ 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>
+ <dt>Example:</dt>
+ <dd>payto://ilp/g.acme.bob
+ </dd>
+ <dt>Contact: </dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd><xref target="ILP-ADDR" format="default"/>, RFC 8905</dd>
+ </dl>
+ </section>
+ <section anchor="registry-entry-void" numbered="true" toc="default">
+ <name>Void Payment Target</name>
+ <dl newline="false" spacing="normal">
+ <dt>Name:</dt>
+ <dd>void</dd>
+ <dt>Description:</dt>
+ <dd>The "void" payment target type allows specifying the parameters
+ of an out-of-band payment (such as cash or other types of in-person
+ 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>
+ <dt>Example:</dt>
+ <dd>payto://void/?amount=EUR:10.5
+ </dd>
+ <dt>Contact:</dt>
+ <dd>N/A</dd>
+ <dt>References:</dt>
+ <dd>RFC 8905</dd>
+ </dl>
+ </section>
+ </section>
+
+<section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <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>
+ <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>
+ <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>
+ <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>
+ </section>
+ <section anchor="iana" numbered="true" toc="default">
+
+<!-- [rfced] We note that the IANA registry at
+https://www.iana.org/assignments/uri-schemes/ includes a template that
+refers to this document. Should this template appear in the document?
+
+Template on https://www.iana.org/assignments/uri-schemes/:
+
+ (registered 2019-01-28, last updated 2020-05-02)
+
+ Scheme name: payto
+
+ Status: provisional
+
+ URI scheme syntax: See Section 2 of RFC-dold-payto-14.
+
+ URI scheme semantics: See Section 3 of RFC-dold-payto-14.
+
+ Applications/protocols that use this scheme name: payto URIs are
+ mainly used by financial software
+
+ Contact: grothoff&gnu.org
+
+ Change controller: grothoff&gnu.org
+
+ References: See References section of RFC-dold-payto-14.
+-->
+
+ <name>IANA Considerations</name>
+ <t>
+ IANA maintains the "Uniform Resource Identifier (URI) Schemes" registry,
+ which contains an entry for the 'payto' URI scheme. IANA has updated that
+ entry to reference this document.
+</t>
+ </section>
+
+ <section anchor="payto-registry" numbered="true" toc="default">
+ <name>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
+ target types. The GNUnet Assigned Numbers Authority (GANA) <xref target="GANA" format="default"/>
+ operates the "payto-payment-target-types" registry to track
+ the following information for each payment target type:
+</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>Contact:</dt>
+ <dd>The contact information of a person to contact for further
+ 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>
+ </dl>
+ <t>
+ The entries in the "payto-payment-target-types" registry
+ defined in this document are as follows:
+</t>
+<table>
+ <thead>
+ <tr>
+ <th>Name</th>
+ <th>Contact</th>
+ <th>Reference</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>ach</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ <tr>
+ <td>bic</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ <tr>
+ <td>iban</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ <tr>
+ <td>upi</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ <tr>
+ <td>bitcoin</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ <tr>
+ <td>ilp</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ <tr>
+ <td>void</td>
+ <td>N/A</td>
+ <td>RFC 8905</td>
+ </tr>
+ </tbody>
+</table>
+ </section>
+
+
+</middle>
+ <back>
+ <references>
+ <name>References</name>
+ <references>
+ <name>Normative References</name>
+ <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
+ <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
+ <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
+ <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
+ <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
+
+<!--[rfced] References
+
+a) Please review the date and title for this reference. The latest version
+that we see is dated August 2015 (rather than August 2018). Also, should the
+title be "Currency Codes" or "Codes for the representation of currencies"? We
+see both titles in these URLs:
+https://www.iso.org/iso-4217-currency-codes.html and
+https://www.iso.org/standard/64758.html.
+
+Original:
+ [ISO4217] International Organization for Standardization, "ISO 4217
+ Currency Codes", August 2018.
+
+
+c) We have updated the date of this reference from "March 2019" to "December
+2014" to correspond to the date in the URL provided. Please let us know any
+objections.
+
+Original:
+ [BIC] International Organization for Standardization, "ISO
+ 9362:2014 Business Identifier Code (BIC)", March 2019,
+ <https://www.iso.org/standard/60390.html>.
+
+Updated:
+ [BIC] International Organization for Standardization, "Banking -
+ Baking telecommunication messages - Business identifier
+ code (BIC)", ISO 9362, December 2014,
+ <https://www.iso.org/standard/60390.html>.
+
+
+c) We note that one ISO reference entry includes a URL while two others do
+not. For consistency, would you like to include URLs for all three ISO
+references? (Note that ISO 20022 has a number of parts; we included the URL
+for Part 1 below, but please let us know if another would be better.)
+
+Original:
+ [ISO20022]
+ International Organization for Standardization, "ISO 20022
+ Financial Services - Universal financial industry message
+ scheme", May 2013.
+
+ [ISO4217] International Organization for Standardization, "ISO 4217
+ Currency Codes", August 2018.
+
+ [BIC] International Organization for Standardization, "ISO
+ 9362:2014 Business Identifier Code (BIC)", March 2019,
+ <https://www.iso.org/standard/60390.html>.
+
+Perhaps:
+ [ISO20022] International Organization for Standardization, "Financial
+ Services - Universal financial industry message scheme",
+ ISO 20022, May 2013, <https://www.iso.org/standard/55005.html>.
+
+ [ISO4217] International Organization for Standardization, "Currency
+ Codes", ISO 4217, August 2015,
+ <https://www.iso.org/standard/64758.html>.
+
+ [BIC] International Organization for Standardization, "Banking -
+ Baking telecommunication messages - Business identifier
+ code (BIC)", ISO 9362, December 2014,
+ <https://www.iso.org/standard/60390.html>.
+
+
+d) We note that this reference has an updated version (see
+https://www.nacha.org/products/2020-nacha-operating-rules-guidelines). Would
+you like to cite the more recent version?
+
+Original:
+ [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017.
+
+Perhaps:
+ [NACHA] Nacha, "2020 NACHA Operating Rules & Guidelines", 2019.
+
+
+e) We see that the wiki cited in this reference was last updated in September
+2019. We updated this reference entry accordingly.
+
+Original:
+ [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement
+ Proposal 21", January 2012,
+ <https://en.bitcoin.it/wiki/BIP_0021>.
+
+Perhaps:
+ [BIP0021] Schneider, N. and M. Corallo, "BIP 0021", September 2019,
+ <https://en.bitcoin.it/w/index.php?title=BIP_0021&oldid=66778>.
+
+-->
+ <reference anchor="ISO4217">
+ <front>
+ <title>Currency Codes</title>
+ <author>
+ <organization>International Organization for Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="August" year="2018"/>
+ </front>
+ <seriesInfo name="ISO" value="4217"/>
+ </reference>
+
+ <reference anchor="ISO20022">
+ <front>
+ <title>Financial Services - Universal financial industry message scheme</title>
+ <author>
+ <organization>International Organization for Standardization</organization>
+ <address>
+ <uri>http://www.iso.ch</uri>
+ </address>
+ </author>
+ <date month="May" year="2013"/>
+ </front>
+ <seriesInfo name="ISO" value="20022"/>
+ </reference>
+
+ <reference anchor="NACHA">
+ <front>
+ <title>Nacha Operating Rules & Guidelines</title>
+ <author>
+ <organization>Nacha</organization>
+ <address>
+ <uri>https://www.nacha.org/</uri>
+ </address>
+ </author>
+ <date month="January" year="2017"/>
+ </front>
+ </reference>
+
+ <reference anchor="unicode-tr36">
+ <front>
+ <title abbrev="Unicode Security Considerations">Unicode Technical
+ Report #36: Unicode Security Considerations</title>
+ <author initials="M." surname="Davis" fullname="Mark Davis" role="editor">
+ <address>
+ <email>markdavis@google.com</email>
+ </address>
+ </author>
+ <author initials="M." surname="Suignard" fullname="Michael Suignard">
+ <address>
+ <email>michel@suignard.com</email>
+ </address>
+ </author>
+ <date month="September" year="2014"/>
+ </front>
+ </reference>
+ </references>
+
+ <references>
+ <name>Informative References</name>
+
+ <reference anchor="BIP0021" target="https://en.bitcoin.it/w/index.php?title=BIP_0021&oldid=66778">
+ <front>
+ <title>Bitcoin Improvement Proposal 21</title>
+ <author initials="N." surname="Schneider" fullname="Nils Schneider">
+ </author>
+ <author initials="M." surname="Corallo" fullname="Matt Corallo">
+ </author>
+ <date month="September" year="2019"/>
+ </front>
+ </reference>
+
+ <reference anchor="HMW12" target="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf">
+ <front>
+ <title>Clickjacking: Attacks and Defenses</title>
+ <author initials="L." surname="Huang" fullname="Lin-Shung Huang">
+ </author>
+ <author initials="A." surname="Moshchuk" fullname="Alexander Moshchuk">
+ </author>
+ <author initials="H." surname="Wang" fullname="Helen J. Wang">
+ </author>
+ <author initials="S." surname="Schecter" fullname="Stuart Schecter">
+ </author>
+ <author initials="C." surname="Jackson" fullname="Collin Jackson">
+ </author>
+ <date year="2012"/>
+ </front>
+ </reference>
+
+ <reference anchor="UPILinking" target="https://www.npci.org.in/sites/default/files/UPI%20Linking%20Specs_ver%201.6.pdf">
+ <front>
+ <title>Unified Payment Interface - Common URL Specifications For Deep
+ Linking And Proximity Integration</title>
+ <author>
+ <organization>National Payments Corporation of India</organization>
+ </author>
+ <date month="November" year="2017"/>
+ </front>
+ </reference>
+
+ <reference anchor="ILP-ADDR" target="https://interledger.org/rfcs/0015-ilp-addresses/">
+ <front>
+ <title>ILP Addresses - v2.0.0</title>
+ <author>
+ <organization>Interledger</organization>
+ </author>
+ </front>
+ </reference>
+
+ <reference anchor="BIC" target="https://www.iso.org/standard/60390.html">
+ <front>
+ <title>Banking - Baking telecommunication messages
+ - Business identifier code (BIC)</title>
+ <author>
+ <organization>International Organization for Standardization</organization>
+ </author>
+ <date month="December" year="2014"/>
+ </front>
+ <seriesInfo name="ISO" value="9362"/>
+ </reference>
+
+
+<!-- [rfced] Questions about the [GANA] reference
+
+a) The [GANA] reference seems to be to a git repository. See
+https://www.rfc-editor.org/styleguide/part2/ (search for "Repositories") for
+information about how repositories like this are typically cited in the RFC
+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
+or
+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/>.
+
+
+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
+use.
+
+"Payment Target Types" sub-registry
+"payto-payment-target-types” registry
+-->
+
+
+ <reference anchor="GANA" target="https://gana.gnunet.org/">
+ <front>
+ <title>GNUnet Assigned Numbers Authority (GANA)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date month="April" year="2020"/>
+ </front>
+ </reference>
+ </references>
+ </references>
+
+
+<!-- [rfced] We see the following forms in the document. We chose the form on
+the right (i.e., the form with single quotes). Please let us know any
+objections.
+
+payto vs. 'payto'
+-->
+
+</back>
+</rfc>
