rfc8905-in-prep.xml (36508B)
1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> 3 4 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-dold-payto-14" 5 number="8905" ipr="trust200902" obsoletes="" updates="" 6 submissionType="independent" category="info" xml:lang="en" 7 tocInclude="true" symRefs="true" sortRefs="true" version="3"> 8 9 <!-- xml2rfc v2v3 conversion 2.44.0 --> 10 <front> 11 <title abbrev="The 'payto' URI Scheme"> 12 The 'payto' URI Scheme for Payments 13 </title> 14 <seriesInfo name="RFC" value="8905"/> 15 <author fullname="Florian Dold" initials="F." surname="Dold"> 16 <organization>Taler Systems SA</organization> 17 <address> 18 <postal> 19 <street>7, rue de Mondorf</street> 20 <city>Erpeldange</city> 21 <code>5421</code> 22 <country>Luxembourg</country> 23 </postal> 24 <email>dold@taler.net</email> 25 </address> 26 </author> 27 <author fullname="Christian Grothoff" initials="C." surname="Grothoff"> 28 <organization>Bern University of Applied Sciences</organization> 29 <address> 30 <postal> 31 <street>Quellgasse 21</street> 32 <street/> 33 <city>Biel/Bienne</city> 34 <code>2501</code> 35 <country>Switzerland</country> 36 </postal> 37 <email>christian.grothoff@bfh.ch</email> 38 </address> 39 </author> 40 <date month="September" year="2020"/> 41 42 <area>General</area> 43 <workgroup>Independent Stream</workgroup> 44 <keyword>payments</keyword> 45 <abstract> 46 <t>This document defines the 'payto' Uniform Resource Identifier (URI) 47 scheme for designating targets for payments.</t> 48 <t>A unified URI scheme for all payment target types allows applications 49 to offer user interactions with URIs that represent payment targets, 50 simplifying the introduction of new payment systems and 51 applications.</t> 52 </abstract> 53 </front> 54 <middle> 55 <section anchor="introduction" numbered="true" toc="default"> 56 <name>Introduction</name> 57 <t>This document defines the 'payto' Uniform Resource Identifier (URI) 58 <xref target="RFC3986" format="default"/> scheme for designating 59 transfer form data for payments.</t> 60 <section numbered="true" toc="default"> 61 <name>Objective</name> 62 <t>A 'payto' URI always identifies the target of a payment. A 'payto' URI 63 consists of a payment target type, a target identifier, and optional 64 parameters such as an amount or a payment reference.</t> 65 <t>The interpretation of the target identifier is defined by the 66 payment target type and typically represents either a bank account or 67 an (unsettled) transaction.</t> 68 <t>A unified URI scheme for all payment target types allows 69 applications to offer user interactions with URIs that represent 70 payment targets, simplifying the introduction of new payment systems 71 and applications.</t> 72 </section> 73 <section numbered="true" toc="default"> 74 <name>Requirements Language</name> 75 <t> 76 The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", 77 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL 78 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", 79 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", 80 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are 81 to be interpreted as 82 described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> 83 when, and only when, they appear in all capitals, as shown here. 84 </t> 85 </section> 86 </section> 87 <section anchor="syntax" numbered="true" toc="default"> 88 <name>Syntax of a 'payto' URI</name> 89 <t>This document uses the Augmented Backus-Naur Form (ABNF) of <xref 90 target="RFC5234" format="default"/>.</t> 91 <sourcecode type="abnf" ><![CDATA[ 92 payto-URI = "payto://" authority path-abempty [ "?" opts ] 93 opts = opt *( "&" opt ) 94 opt-name = generic-opt / authority-specific-opt 95 opt-value = *pchar 96 opt = opt-name "=" opt-value 97 generic-opt = "amount" / "receiver-name" / "sender-name" / 98 "message" / "instruction" 99 authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." ) 100 authority = ALPHA *( ALPHA / DIGIT / "-" / "." ) 101 ]]></sourcecode> 102 <t> 103 'path-abempty' is defined in <xref target="RFC3986" sectionFormat="of" section="3.3"/>. 104 'pchar' is defined in <xref target="RFC3986" sectionFormat="of" section="A"/>. 105 </t> 106 </section> 107 <section anchor="semantics" numbered="true" toc="default"> 108 <name>Semantics</name> 109 <t>The authority component of a payment URI identifies the payment 110 target type. The payment target types are defined in the "Payto Payment 111 Target Types" registry (see <xref target="payto-registry" 112 format="default"/>). The path component of the URI identifies the target 113 for a payment as interpreted by the respective payment target type. The 114 query component of the URI can provide additional parameters for a 115 payment. Every payment target type <bcp14>SHOULD</bcp14> accept the 116 options defined in generic-opt. The default operation of applications 117 that invoke a URI with the 'payto' scheme <bcp14>MUST</bcp14> be to launch 118 an application (if available) associated with the payment target type 119 that can initiate a payment. 120 121 If multiple handlers are registered for the 122 same payment target type, the user <bcp14>SHOULD</bcp14> be able to 123 choose which application to launch. This allows users with multiple bank 124 accounts (each accessed via the respective bank's banking application) to 125 choose which account to pay with. An application <bcp14>SHOULD</bcp14> 126 allow dereferencing a 'payto' URI even if the payment target type of that 127 URI is not registered in the "Payto Payment Target Types" registry. Details 128 of the payment <bcp14>MUST</bcp14> be taken from the path and options 129 given in the URI. The user <bcp14>SHOULD</bcp14> be allowed to modify 130 these details before confirming a payment.</t> 131 </section> 132 <section anchor="examples" numbered="true" toc="default"> 133 <name>Examples</name> 134 <!-- [rfced] Please review the artwork element in the xml file. Specifically, 135 should this artwork element be tagged as <sourcecode>, <t>, or another 136 element? 137 Answer-CG: <t> seems fine to me. Not really source. 138 Answer-FD: As <t> would cause rendering in variable width font, 139 I've used sourcecode and moved the "annotation" of the examples above. 140 --> 141 <t>Valid Example:</t> 142 <sourcecode><![CDATA[ 143 payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello 144 ]]></sourcecode> 145 <t>Invalid Example (authority missing):</t> 146 <sourcecode><![CDATA[ 147 payto:iban/12345 148 ]]></sourcecode> 149 </section> 150 <section anchor="generic-options" numbered="true" toc="default"> 151 <name>Generic Options</name> 152 <t>Applications <bcp14>MUST</bcp14> accept URIs with options in any 153 order. The "amount" option <bcp14>MUST NOT</bcp14> occur more than 154 once. Other options <bcp14>MAY</bcp14> be allowed multiple times, with 155 further restrictions depending on the payment target type. The following 156 options <bcp14>SHOULD</bcp14> be understood by every payment target 157 type.</t> 158 159 <dl newline="false" spacing="normal"> 160 <dt>amount:</dt> 161 <dd><t>The amount to transfer. The format <bcp14>MUST</bcp14> be:</t> 162 163 <sourcecode type="abnf"><![CDATA[ 164 amount = currency ":" unit [ "." fraction ] 165 currency = 1*ALPHA 166 unit = 1*(DIGIT / ",") 167 fraction = 1*(DIGIT / ",") 168 ]]></sourcecode> 169 <t>If a 3-letter 'currency' is used, it <bcp14>MUST</bcp14> be an <xref 170 target="ISO4217" format="default"/> alphabetic code. A payment target 171 type <bcp14>MAY</bcp14> define semantics beyond ISO 4217 for currency 172 codes that are not 3 characters. The 'unit' value <bcp14>MUST</bcp14> be 173 smaller than 2^53. If present, the 'fraction' <bcp14>MUST</bcp14> 174 consist of no more than 8 decimal digits. The use of commas is optional 175 for readability, and they <bcp14>MUST</bcp14> be ignored.</t> </dd> 176 177 <dt>receiver-name:</dt> 178 <dd>Name of the entity that receives the payment (creditor). The value of 179 this option <bcp14>MAY</bcp14> be subject to lossy conversion, modification, 180 and truncation (for example, due to line wrapping or character set 181 conversion).</dd> 182 <dt>sender-name:</dt> 183 <dd>Name of the entity that makes the payment (debtor). The value of this 184 option <bcp14>MAY</bcp14> be subject to lossy conversion, modification, and 185 truncation (for example, due to line wrapping or character set 186 conversion).</dd> 187 <dt>message:</dt> 188 <dd>A short message to identify the purpose of the payment. The value of 189 this option <bcp14>MAY</bcp14> be subject to lossy conversion, modification, 190 and truncation (for example, due to line wrapping or character set 191 conversion).</dd> 192 <dt>instruction:</dt> 193 <dd>A short message giving payment reconciliation instructions to the 194 recipient. An instruction that follows the character set and length 195 limitation defined by the respective payment target type <bcp14>SHOULD 196 NOT</bcp14> be subject to lossy conversion.</dd> 197 </dl> 198 </section> 199 <section anchor="encoding" numbered="true" toc="default"> 200 <name>Internationalization and Character Encoding</name> 201 <t> 202 Various payment systems use restricted character sets. 203 An application that processes 'payto' URIs <bcp14>MUST</bcp14> convert 204 characters that are not allowed by the respective payment systems 205 into allowable characters using either an encoding or a replacement table. 206 This conversion process <bcp14>MAY</bcp14> be lossy, except for the instruction field. 207 If the value of the instruction field would be subject to lossy conversion, 208 modification, or truncation, 209 the application <bcp14>SHOULD</bcp14> refuse further processing of the payment until a 210 different value for the instruction is provided. 211 </t> 212 <t>To avoid special encoding rules for the payment target identifier, 213 the userinfo component <xref target="RFC3986" format="default"/> is 214 disallowed in 'payto' URIs. Instead, the payment target identifier is 215 given as an option, where encoding rules are uniform for all 216 options.</t> 217 <t> 218 Defining a generic way of tagging the language of option fields containing natural 219 language text (such as "receiver-name", "sender-name", and "message) 220 is out of the scope of this document, as internationalization must accommodate the restrictions 221 and requirements of the underlying banking system of the payment target type. 222 223 The internationalization concerns <bcp14>SHOULD</bcp14> be individually defined by each payment target type. 224 </t> 225 </section> 226 <section anchor="tracking" numbered="true" toc="default"> 227 <name>Tracking Payment Target Types</name> 228 <t> A registry of "Payto Payment Target Types" is described in <xref 229 target="payto-registry" format="default"/>. The registration policy for 230 this registry is "First Come First Served", as described in <xref 231 target="RFC8126" format="default"/>. When requesting new entries, 232 careful consideration of the following criteria is strongly advised:</t> 233 <ol spacing="normal" type="1"> 234 <li>The description clearly defines the syntax and semantics of the 235 payment target and optional parameters if applicable.</li> 236 <li>Relevant references are provided if they are available.</li> 237 <li>The chosen name is appropriate for the payment target type, does 238 not conflict with well-known payment systems, and avoids potential to 239 confuse users.</li> 240 <li>The payment system underlying the payment target type is not 241 fundamentally incompatible with the general options (such as positive 242 decimal amounts) in this specification.</li> 243 <li>The payment target type is not a vendor-specific version of a 244 payment target type that could be described more generally by a 245 vendor-neutral payment target type.</li> 246 <li>The specification of the new payment target type remains within 247 the scope of payment transfer form data. In particular, specifying 248 complete invoices is not in scope. Neither are processing 249 instructions to the payment processor or bank beyond a simple 250 payment.</li> 251 <li>The payment target and the options do not contain the payment 252 sender's account details.</li> 253 </ol> 254 <t>Documents that support requests for new registry entries should 255 provide the following information for each entry:</t> 256 <dl newline="false" spacing="normal"> 257 <dt>Name:</dt> 258 <dd>The name of the payment target type (case-insensitive ASCII 259 string, restricted to alphanumeric characters, dots, and dashes).</dd> 260 <dt>Description:</dt> 261 <dd>A description of the payment target type, including the semantics 262 of the path in the URI if applicable.</dd> 263 <dt>Example:</dt> 264 <dd>At least one example URI to illustrate the payment target 265 type.</dd> 266 <dt>Contact:</dt> 267 <dd>The contact information of a person to contact for further information.</dd> 268 <dt>References:</dt> 269 <dd>Optionally, references describing the payment target type (such as 270 an RFC) and target-specific options or references describing the 271 payment system underlying the payment target type.</dd> 272 </dl> 273 <t>This document populates the registry with seven entries as follows (see 274 also <xref target="payto-registry" format="default"/>).</t> 275 <section anchor="registry-entry-ach" numbered="true" toc="default"> 276 <name>ACH Bank Account</name> 277 <dl newline="false" spacing="normal"> 278 <dt>Name:</dt> 279 <dd>ach</dd> 280 <dt>Description:</dt> 281 <dd>Automated Clearing House (ACH). The path consists of two components: 282 the routing number and the account number. Limitations on the length 283 and character set of option values are defined by the implementation 284 of the handler. Language tagging and internationalization of options 285 are not supported.</dd> 286 <dt>Example:</dt> 287 <dd> 288 <sourcecode><![CDATA[ 289 payto://ach/122000661/1234 290 ]]></sourcecode> 291 </dd> 292 <dt>Contact:</dt> 293 <dd>N/A</dd> 294 <dt>References:</dt> 295 <dd><xref target="NACHA" format="default"/>, RFC 8905</dd> 296 </dl> 297 </section> 298 <section anchor="registry-entry-bic" numbered="true" toc="default"> 299 <name>Business Identifier Code</name> 300 <dl newline="false" spacing="normal"> 301 <dt>Name:</dt> 302 <dd>bic</dd> 303 <dt>Description:</dt> 304 305 <!-- [rfced] Would it be helpful to include a citation in this sentence? 306 307 Original: 308 The registry for BICs is provided by SWIFT. 309 Answer-CG: 310 The best reference is [BIC], which is already under References. I see no 311 need to duplicate the reference in that sentence. 312 --> 313 314 <dd>Business Identifier Code (BIC). The path consists of just 315 a BIC. This is used for wire transfers between banks. The registry 316 for BICs is provided by the Society for Worldwide Interbank 317 Financial Telecommunication (SWIFT). The path does not allow specifying a 318 bank account number. Limitations on the length and character set of 319 option values are defined by the implementation of the 320 handler. Language tagging and internationalization of options are not 321 supported.</dd> 322 <dt>Example:</dt> 323 <dd> 324 <sourcecode><![CDATA[ 325 payto://bic/SOGEDEFFXXX 326 ]]></sourcecode> 327 </dd> 328 <dt>Contact:</dt> 329 <dd>N/A</dd> 330 <dt>References:</dt> 331 <dd><xref target="BIC" format="default"/>, RFC 8905</dd> 332 </dl> 333 </section> 334 <section anchor="registry-entry-iban" numbered="true" toc="default"> 335 <name>International Bank Account Number</name> 336 <dl newline="false" spacing="normal"> 337 <dt>Name:</dt> 338 <dd>iban</dd> 339 <dt>Description:</dt> 340 341 <!-- [rfced] How may we clarify "allows to unambiguously derive" here? 342 343 Original: 344 Generally the IBAN allows to unambiguously derive the the associated 345 Business Identifier Code (BIC). 346 Answer-CG: 347 Extended sentence explaining how it is done. But largely this 348 is out of scope of the document. 349 --> 350 <dd>International Bank Account Number (IBAN). Generally, the IBAN 351 allows to unambiguously derive the associated Business 352 Identifier Code (BIC) using a lookup in the respective 353 proprietary translation table. However, some legacy applications process 354 payments to the same IBAN differently based on the specified BIC. 355 Thus, the path can consist of either a single component (the IBAN) or 356 two components (BIC followed by IBAN). The "message" option of the 357 'payto' URI corresponds to the "unstructured remittance information" 358 of Single Euro Payments Area (SEPA) credit transfers and is thus 359 limited to 140 characters with 360 character set limitations that differ according to the countries of 361 the banks and payment processors involved in the payment. The 362 "instruction" option of the 'payto' URI corresponds to the "end-to-end 363 identifier" of SEPA credit transfers and is thus limited to, at most, 364 35 characters, which can be alphanumeric or from the allowed set of 365 special characters, i.e., "+?/-:().,'". Language tagging and 366 internationalization of options are not supported.</dd> 367 <dt>Examples:</dt> 368 <dd> 369 <sourcecode><![CDATA[ 370 payto://iban/DE75512108001245126199 371 payto://iban/SOGEDEFFXXX/DE75512108001245126199 372 ]]></sourcecode> 373 </dd> 374 <dt>Contact:</dt> 375 <dd>N/A</dd> 376 <dt>References:</dt> 377 <dd><xref target="ISO20022" format="default"/>, RFC 8905</dd> 378 </dl> 379 </section> 380 <section anchor="registry-entry-upi" numbered="true" toc="default"> 381 <name>Unified Payments Interface</name> 382 <dl newline="false" spacing="normal"> 383 <dt>Name:</dt> 384 <dd>upi</dd> 385 <dt>Description:</dt> 386 <dd>Unified Payment Interface (UPI). The path is an account alias. The 387 amount and receiver-name options are mandatory for this payment 388 target. Limitations on the length and character set of option values 389 are defined by the implementation of the handler. Language tags and 390 internationalization of options are not supported.</dd> 391 <dt>Example:</dt> 392 <dd> 393 <sourcecode><![CDATA[ 394 payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200 395 ]]></sourcecode> 396 397 </dd> 398 <dt>Contact:</dt> 399 <dd>N/A</dd> 400 <dt>References:</dt> 401 <dd><xref target="UPILinking" format="default"/>, RFC 8905</dd> 402 </dl> 403 </section> 404 <section anchor="registry-entry-bitcoin" numbered="true" toc="default"> 405 <name>Bitcoin Address</name> 406 <dl newline="false" spacing="normal"> 407 <dt>Name:</dt> 408 <dd>bitcoin</dd> 409 <dt>Description:</dt> 410 <dd>Bitcoin protocol. The path is a "bitcoinaddress", as per <xref 411 target="BIP0021" format="default"/>. Limitations on the length and 412 character set of option values are defined by the implementation of 413 the handler. Language tags and internationalization of options are 414 not supported.</dd> 415 <dt>Example:</dt> 416 <dd> 417 <sourcecode><![CDATA[ 418 payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu 419 ]]></sourcecode> 420 </dd> 421 <dt>Contact:</dt> 422 <dd>N/A</dd> 423 <dt>References:</dt> 424 <dd><xref target="BIP0021" format="default"/>, RFC 8905</dd> 425 </dl> 426 </section> 427 <section anchor="registry-entry-ilp" numbered="true" toc="default"> 428 <name>Interledger Protocol Address</name> 429 <dl newline="false" spacing="normal"> 430 <dt>Name:</dt> 431 <dd>ilp</dd> 432 <dt>Description:</dt> 433 <dd>Interledger protocol (ILP). The path is an ILP address, as per <xref 434 target="ILP-ADDR" format="default"/>. Limitations on the length and 435 character set of option values are defined by the implementation of 436 the handler. Language tagging and internationalization of options 437 are not supported.</dd> 438 <dt>Example:</dt> 439 <dd>payto://ilp/g.acme.bob 440 </dd> 441 <dt>Contact: </dt> 442 <dd>N/A</dd> 443 <dt>References:</dt> 444 <dd><xref target="ILP-ADDR" format="default"/>, RFC 8905</dd> 445 </dl> 446 </section> 447 <section anchor="registry-entry-void" numbered="true" toc="default"> 448 <name>Void Payment Target</name> 449 <dl newline="false" spacing="normal"> 450 <dt>Name:</dt> 451 <dd>void</dd> 452 <dt>Description:</dt> 453 <dd>The "void" payment target type allows specifying the parameters 454 of an out-of-band payment (such as cash or other types of in-person 455 transactions). The path is optional and interpreted as a 456 comment. Limitations on the length and character set of option 457 values are defined by the implementation of the handler. Language 458 tags and internationalization of options are not supported.</dd> 459 <dt>Example:</dt> 460 <dd> 461 <sourcecode><![CDATA[ 462 payto://void/?amount=EUR:10.5 463 ]]></sourcecode> 464 </dd> 465 <dt>Contact:</dt> 466 <dd>N/A</dd> 467 <dt>References:</dt> 468 <dd>RFC 8905</dd> 469 </dl> 470 </section> 471 </section> 472 473 <section anchor="security" numbered="true" toc="default"> 474 <name>Security Considerations</name> 475 <t>Interactive applications handling the 'payto' URI scheme <bcp14>MUST 476 NOT</bcp14> initiate any financial transactions without prior review and 477 confirmation from the user and <bcp14>MUST</bcp14> take measures to 478 prevent clickjacking <xref target="HMW12" format="default"/>.</t> 479 <t>Unless a 'payto' URI is received over a trusted, authenticated channel, 480 a user might not be able to identify the target of a payment. In 481 particular, due to homographs <xref target="unicode-tr36" 482 format="default"/>, a payment target type <bcp14>SHOULD NOT</bcp14> use 483 human-readable names in combination with unicode in the target account 484 specification, as it could give the user the illusion of being able to 485 identify the target account from the URI.</t> 486 <t>The authentication/authorization mechanisms and transport security 487 services used to process a payment encoded in a 'payto' URI are handled by 488 the application and are not in scope of this document.</t> 489 <t>To avoid unnecessary data collection, payment target types 490 <bcp14>SHOULD NOT</bcp14> include personally identifying information 491 about the sender of a payment that is not essential for an application 492 to conduct a payment.</t> 493 </section> 494 <section anchor="iana" numbered="true" toc="default"> 495 496 <!-- [rfced] We note that the IANA registry at 497 https://www.iana.org/assignments/uri-schemes/ includes a template that 498 refers to this document. Should this template appear in the document? 499 500 Template on https://www.iana.org/assignments/uri-schemes/: 501 502 (registered 2019-01-28, last updated 2020-05-02) 503 504 Scheme name: payto 505 506 Status: provisional 507 508 URI scheme syntax: See Section 2 of RFC-dold-payto-14. 509 510 URI scheme semantics: See Section 3 of RFC-dold-payto-14. 511 512 Applications/protocols that use this scheme name: payto URIs are 513 mainly used by financial software 514 515 Contact: grothoff&gnu.org 516 517 Change controller: grothoff&gnu.org 518 519 References: See References section of RFC-dold-payto-14. 520 521 Answer-CG: 522 I don't see a reason to duplicate it here. 523 --> 524 525 <name>IANA Considerations</name> 526 <t> 527 IANA maintains the "Uniform Resource Identifier (URI) Schemes" registry, 528 which contains an entry for the 'payto' URI scheme. IANA has updated that 529 entry to reference this document. 530 </t> 531 </section> 532 533 <section anchor="payto-registry" numbered="true" toc="default"> 534 <name>Payto Payment Target Types</name> 535 <t> 536 This document specifies a list of payment target types. It is 537 possible that future work will need to specify additional payment 538 target types. The GNUnet Assigned Numbers Authority (GANA) <xref target="GANA" format="default"/> 539 operates the "Payto Payment Target Types" registry to track 540 the following information for each payment target type: 541 </t> 542 <dl newline="false" spacing="normal"> 543 <dt>Name:</dt> 544 <dd>The name of the payment target type (case-insensitive ASCII 545 string, restricted to alphanumeric characters, dots, and dashes)</dd> 546 <dt>Contact:</dt> 547 <dd>The contact information of a person to contact for further 548 information</dd> 549 <dt>References:</dt> 550 <dd>Optionally, references describing the payment target type (such as 551 an RFC) and target-specific options or references describing the 552 payment system underlying the payment target type</dd> 553 </dl> 554 <t> 555 The entries in the "Payto Payment Target Types" registry 556 defined in this document are as follows: 557 </t> 558 <table> 559 <thead> 560 <tr> 561 <th>Name</th> 562 <th>Contact</th> 563 <th>Reference</th> 564 </tr> 565 </thead> 566 <tbody> 567 <tr> 568 <td>ach</td> 569 <td>N/A</td> 570 <td>RFC 8905</td> 571 </tr> 572 <tr> 573 <td>bic</td> 574 <td>N/A</td> 575 <td>RFC 8905</td> 576 </tr> 577 <tr> 578 <td>iban</td> 579 <td>N/A</td> 580 <td>RFC 8905</td> 581 </tr> 582 <tr> 583 <td>upi</td> 584 <td>N/A</td> 585 <td>RFC 8905</td> 586 </tr> 587 <tr> 588 <td>bitcoin</td> 589 <td>N/A</td> 590 <td>RFC 8905</td> 591 </tr> 592 <tr> 593 <td>ilp</td> 594 <td>N/A</td> 595 <td>RFC 8905</td> 596 </tr> 597 <tr> 598 <td>void</td> 599 <td>N/A</td> 600 <td>RFC 8905</td> 601 </tr> 602 </tbody> 603 </table> 604 </section> 605 606 607 </middle> 608 <back> 609 <references> 610 <name>References</name> 611 <references> 612 <name>Normative References</name> 613 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> 614 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> 615 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> 616 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> 617 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> 618 619 <!--[rfced] References 620 621 a) Please review the date and title for this reference. The latest version 622 that we see is dated August 2015 (rather than August 2018). Also, should the 623 title be "Currency Codes" or "Codes for the representation of currencies"? We 624 see both titles in these URLs: 625 https://www.iso.org/iso-4217-currency-codes.html and 626 https://www.iso.org/standard/64758.html. 627 628 Original: 629 [ISO4217] International Organization for Standardization, "ISO 4217 630 Currency Codes", August 2018. 631 632 Answer-FD: Revised the date and title. 633 634 c) We have updated the date of this reference from "March 2019" to "December 635 2014" to correspond to the date in the URL provided. Please let us know any 636 objections. 637 638 Original: 639 [BIC] International Organization for Standardization, "ISO 640 9362:2014 Business Identifier Code (BIC)", March 2019, 641 <https://www.iso.org/standard/60390.html>. 642 643 Updated: 644 [BIC] International Organization for Standardization, "Banking - 645 Baking telecommunication messages - Business identifier 646 code (BIC)", ISO 9362, December 2014, 647 <https://www.iso.org/standard/60390.html>. 648 649 Answer-FC: That's fine! 650 651 c) We note that one ISO reference entry includes a URL while two others do 652 not. For consistency, would you like to include URLs for all three ISO 653 references? (Note that ISO 20022 has a number of parts; we included the URL 654 for Part 1 below, but please let us know if another would be better.) 655 656 Original: 657 [ISO20022] 658 International Organization for Standardization, "ISO 20022 659 Financial Services - Universal financial industry message 660 scheme", May 2013. 661 662 [ISO4217] International Organization for Standardization, "ISO 4217 663 Currency Codes", August 2018. 664 665 [BIC] International Organization for Standardization, "ISO 666 9362:2014 Business Identifier Code (BIC)", March 2019, 667 <https://www.iso.org/standard/60390.html>. 668 669 Perhaps: 670 [ISO20022] International Organization for Standardization, "Financial 671 Services - Universal financial industry message scheme", 672 ISO 20022, May 2013, <https://www.iso.org/standard/55005.html>. 673 674 [ISO4217] International Organization for Standardization, "Currency 675 Codes", ISO 4217, August 2015, 676 <https://www.iso.org/standard/64758.html>. 677 678 [BIC] International Organization for Standardization, "Banking - 679 Baking telecommunication messages - Business identifier 680 code (BIC)", ISO 9362, December 2014, 681 <https://www.iso.org/standard/60390.html>. 682 683 Answer-FD: These links are not canonical links to the standard, but deep links 684 to the store page where they can be bought. Thus I would 685 prefer a more canonical link to the ISO Website. 686 687 d) We note that this reference has an updated version (see 688 https://www.nacha.org/products/2020-nacha-operating-rules-guidelines). Would 689 you like to cite the more recent version? 690 691 Original: 692 [NACHA] NACHA, "NACHA Operating Rules & Guidelines", January 2017. 693 694 Perhaps: 695 [NACHA] Nacha, "2020 NACHA Operating Rules & Guidelines", 2019. 696 697 Answer-FD: Updated. 698 699 e) We see that the wiki cited in this reference was last updated in September 700 2019. We updated this reference entry accordingly. 701 702 Original: 703 [BIP0021] Schneider, N. and M. Corallo, "Bitcoin Improvement 704 Proposal 21", January 2012, 705 <https://en.bitcoin.it/wiki/BIP_0021>. 706 707 Perhaps: 708 [BIP0021] Schneider, N. and M. Corallo, "BIP 0021", September 2019, 709 <https://en.bitcoin.it/w/index.php?title=BIP_0021&oldid=66778>. 710 711 Answer-FD: That's fine! 712 --> 713 <reference anchor="ISO4217"> 714 <front> 715 <title>Codes for the representation of currencies</title> 716 <author> 717 <organization>International Organization for Standardization</organization> 718 <address> 719 <uri>http://www.iso.org</uri> 720 </address> 721 </author> 722 <date month="August" year="2015"/> 723 </front> 724 <seriesInfo name="ISO" value="4217"/> 725 </reference> 726 727 <reference anchor="ISO20022"> 728 <front> 729 <title>Financial Services - Universal financial industry message scheme</title> 730 <author> 731 <organization>International Organization for Standardization</organization> 732 <address> 733 <uri>http://www.iso.org</uri> 734 </address> 735 </author> 736 <date month="May" year="2013"/> 737 </front> 738 <seriesInfo name="ISO" value="20022"/> 739 </reference> 740 741 <reference anchor="NACHA"> 742 <front> 743 <title>Nacha Operating Rules & Guidelines</title> 744 <author> 745 <organization>Nacha</organization> 746 <address> 747 <uri>https://www.nacha.org/</uri> 748 </address> 749 </author> 750 <date year="2019"/> 751 </front> 752 </reference> 753 754 <reference anchor="unicode-tr36"> 755 <front> 756 <title abbrev="Unicode Security Considerations">Unicode Technical 757 Report #36: Unicode Security Considerations</title> 758 <author initials="M." surname="Davis" fullname="Mark Davis" role="editor"> 759 <address> 760 <email>markdavis@google.com</email> 761 </address> 762 </author> 763 <author initials="M." surname="Suignard" fullname="Michael Suignard"> 764 <address> 765 <email>michel@suignard.com</email> 766 </address> 767 </author> 768 <date month="September" year="2014"/> 769 </front> 770 </reference> 771 </references> 772 773 <references> 774 <name>Informative References</name> 775 776 <reference anchor="BIP0021" target="https://en.bitcoin.it/w/index.php?title=BIP_0021&oldid=66778"> 777 <front> 778 <title>Bitcoin Improvement Proposal 21</title> 779 <author initials="N." surname="Schneider" fullname="Nils Schneider"> 780 </author> 781 <author initials="M." surname="Corallo" fullname="Matt Corallo"> 782 </author> 783 <date month="September" year="2019"/> 784 </front> 785 </reference> 786 787 <reference anchor="HMW12" target="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf"> 788 <front> 789 <title>Clickjacking: Attacks and Defenses</title> 790 <author initials="L." surname="Huang" fullname="Lin-Shung Huang"> 791 </author> 792 <author initials="A." surname="Moshchuk" fullname="Alexander Moshchuk"> 793 </author> 794 <author initials="H." surname="Wang" fullname="Helen J. Wang"> 795 </author> 796 <author initials="S." surname="Schecter" fullname="Stuart Schecter"> 797 </author> 798 <author initials="C." surname="Jackson" fullname="Collin Jackson"> 799 </author> 800 <date year="2012"/> 801 </front> 802 </reference> 803 804 <reference anchor="UPILinking" target="https://www.npci.org.in/sites/default/files/UPI%20Linking%20Specs_ver%201.6.pdf"> 805 <front> 806 <title>Unified Payment Interface - Common URL Specifications For Deep 807 Linking And Proximity Integration</title> 808 <author> 809 <organization>National Payments Corporation of India</organization> 810 </author> 811 <date month="November" year="2017"/> 812 </front> 813 </reference> 814 815 <reference anchor="ILP-ADDR" target="https://interledger.org/rfcs/0015-ilp-addresses/"> 816 <front> 817 <title>ILP Addresses - v2.0.0</title> 818 <author> 819 <organization>Interledger</organization> 820 </author> 821 </front> 822 </reference> 823 824 <reference anchor="BIC" target="https://www.iso.org"> 825 <front> 826 <title>Banking - Baking telecommunication messages 827 - Business identifier code (BIC)</title> 828 <author> 829 <organization>International Organization for Standardization</organization> 830 </author> 831 <date month="December" year="2014"/> 832 </front> 833 <seriesInfo name="ISO" value="9362"/> 834 </reference> 835 836 837 <!-- [rfced] Questions about the [GANA] reference 838 839 a) The [GANA] reference seems to be to a git repository. See 840 https://www.rfc-editor.org/styleguide/part2/ (search for "Repositories") for 841 information about how repositories like this are typically cited in the RFC 842 Series. Please let us know which title, commit hash, and date to use. In 843 addition, we suggest updating the URL in this reference entry to point to a 844 more direct URL. Would either of the following work? 845 846 https://git.gnunet.org/gana.git/tree/payto-payment-target-types 847 or 848 https://git.gnunet.org/gana.git/tree/payto-payment-target-types/registry.rec 849 850 Original: 851 [GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", 852 April 2020, <https://gana.gnunet.org/>. 853 854 Answer-CG: 855 The "git.gnunet.org" URL is only going to work as long as GANA uses the 856 GNUnet Git repository. Using the top-level alias is likely a more stable 857 URL. Finding the payto registry within GANA should be reasonably simple. 858 859 b) We see the following forms used for the title of the registry at 860 [GANA]. Should these be consistent? If so, please let us know which form to 861 use. 862 863 "Payment Target Types" sub-registry 864 "payto-payment-target-types” registry 865 866 Answer-CG: 867 I have changed the text to always use "Payto Payment Target Types" registry 868 when referencing the registry at GANA. 869 870 --> 871 872 873 <reference anchor="GANA" target="https://gana.gnunet.org/"> 874 <front> 875 <title>GNUnet Assigned Numbers Authority (GANA)</title> 876 <author> 877 <organization>GNUnet e.V.</organization> 878 </author> 879 <date month="April" year="2020"/> 880 </front> 881 </reference> 882 </references> 883 </references> 884 885 886 <!-- [rfced] We see the following forms in the document. We chose the form on 887 the right (i.e., the form with single quotes). Please let us know any 888 objections. 889 890 payto vs. 'payto' 891 892 Answer-CG: 893 This is fine. 894 --> 895 896 </back> 897 </rfc>