gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-marketing] 02/04: grammar, i18n, dead link (addressing Benjamin K


From: gnunet
Subject: [taler-marketing] 02/04: grammar, i18n, dead link (addressing Benjamin Kaduk's comments)
Date: Tue, 28 Apr 2020 15:07:07 +0200

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

dold pushed a commit to branch master
in repository marketing.

commit fdf5e8532d104ea87007ac1dd88041c68bff22bf
Author: Florian Dold <address@hidden>
AuthorDate: Tue Apr 28 17:08:51 2020 +0530

    grammar, i18n, dead link (addressing Benjamin Kaduk's comments)
---
 standards/draft-dold-payto.xml | 42 +++++++++++++++++++++++++++++++-----------
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 79982ae..7d35dd6 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -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" />.
@@ -575,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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]