commit 6c3201ab787edb1a64c31361e1cd8f673844fce9
parent a2c919f5668175d9340a671e9d8f8c2dec7fb68c
Author: Christian Grothoff <christian@grothoff.org>
Date: Wed, 29 Apr 2020 12:04:14 +0200
Merge branch 'master' of git+ssh://git.taler.net/marketing
Diffstat:
1 file changed, 41 insertions(+), 16 deletions(-)
diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
@@ -17,7 +17,7 @@
<?rfc subcompact="no" ?>
<rfc category="info"
- docName="draft-dold-payto-11"
+ docName="draft-dold-payto-13"
ipr="trust200902">
<front>
@@ -52,7 +52,7 @@
</address>
</author>
- <date day="23" month="March" year="2020" />
+ <date day="28" month="April" year="2020" />
<!-- Meta-data Declarations -->
<area>General</area>
@@ -121,7 +121,9 @@
<artwork type="abnf"><![CDATA[
payto-URI = "payto://" authority path-abempty [ "?" opts ]
opts = opt *( "&" opt )
- opt = (generic-opt / authority-specific-opt) "=" *pchar
+ 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 / "-" / "." )
@@ -206,26 +208,33 @@
<t>
receiver-name: Name of the entity that receives the payment (creditor).
+ The value of this option MAY
+ be subject to lossy conversion, modification and truncation (for example, due to
+ line wrapping or character set conversion).
</t>
<t>
sender-name: Name of the entity that makes the payment (debtor).
+ The value of this option MAY
+ be subject to lossy conversion, modification and truncation (for example, due to
+ line wrapping or character set conversion).
</t>
<t>
- message: A short message to identify the purpose of the payment, which MAY
- be subject to lossy conversions (for example, due to character set encoding
- limitations).
+ message: A short message to identify the purpose of the payment.
+ The value of this option MAY
+ be subject to lossy conversion, modification and truncation (for example, due to
+ line wrapping or character set conversion).
</t>
<t>
- instruction: A short message giving instructions to the recipient, which
- MUST NOT be subject to lossy conversions. Character set limitations allowed
- for such instructions depend on the payment target type.
+ instruction: 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 SHOULD NOT be subject to lossy conversion.
</t>
</section>
-
<section anchor="encoding" title="Internationalization and Character Encoding">
<t>
Various payment systems use restricted character sets.
@@ -233,14 +242,25 @@
characters that are not allowed by the respective payment systems
into allowable character using either an encoding or a replacement table.
This conversion process MAY 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 SHOULD 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" /> is disallowed in payto URIs. Instead, the payment target identifier is
given as an option, where encoding rules are uniform for all options.
</t>
-</section>
+<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 accomodate the restrictions
+ and requirements of the underlying banking system of the payment target type.
+ The internationalization concerns SHOULD be individually defined by each payment target type.
+</t>
+</section>
<section anchor="tracking" title="Tracking Payment Target Types">
<t>
A registry of Payment Target Types is described in <xref target="payto-registry" />.
@@ -313,7 +333,7 @@ also <xref target="payto-registry" />).
<t>Description: International Bank Account Number (IBAN). Generally the IBAN allows to unambiguously derive
the 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 either consist of a single component (the IBAN) or two components
- (BIC and IBAN).
+ (BIC followed by IBAN).
</t>
<t>Example:
@@ -397,6 +417,11 @@ 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 SHOULD NOT
include personally identifying information about the sender of a payment that is not
essential for an application to conduct a payment.
@@ -424,7 +449,7 @@ IANA maintains a registry called the "Uniform Resource Identifier
<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" />
+ target types. The GNUnet Assigned Numbers Authority (GANA) <xref target="GANA" />
operates the "payto-payment-target-types" registry to track
the following information for each payment target type:
<list style="symbols">
@@ -570,13 +595,13 @@ dots and dashes)</t>
</front>
</reference>
- <reference anchor="UPILinking" target="http://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf">
+ <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 Payment Corporation of India</organization>
</author>
- <date month="May" year="2016" />
+ <date month="November" year="2017" />
</front>
</reference>
@@ -598,7 +623,7 @@ dots and dashes)</t>
</front>
</reference>
- <reference anchor="GANA" target="https://git.gnunet.org/gana.git">
+ <reference anchor="GANA" target="https://gana.gnunet.org/">
<front>
<title>GNUnet Assigned Numbers Authority (GANA)</title>
<author><organization>GNUnet e.V.</organization>
