[taler-marketing] branch master updated (dfbff4f -> 5fcf27b)

[gnunet]

This is an automated email from the git hooks/post-receive script.

dold pushed a change to branch master
in repository marketing.

    from dfbff4f  fix xref
     new 0bc7dea  add clarification (based on Roman Danyliw's feedback)
     new fdf5e85  grammar, i18n, dead link (addressing Benjamin Kaduk's 
comments)
     new eea52d5  clarification
     new 5fcf27b  adjust metadata

The 4 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 standards/draft-dold-payto.xml | 53 +++++++++++++++++++++++++++++++-----------
 1 file changed, 39 insertions(+), 14 deletions(-)

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 9b50fb4..a8467f3 100644
--- 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-12"
+     docName="draft-dold-payto-13"
      ipr="trust200902">
 
   <front>
@@ -52,7 +52,7 @@
       </address>
     </author>
 
-    <date day="06" month="April" 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.
@@ -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>
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden.