hacking on payto draft, adding clarifications

1 files changed, 34 insertions, 21 deletions

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 9e427ce..abe912f 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -26,7 +26,7 @@ Questions:
 
   <front>
     <title abbrev="The 'payto' URI scheme">
-      The 'payto' URI scheme for payment addresses
+      The 'payto' URI scheme for payments
     </title>
 
     <author fullname="Florian Dold" initials="F.D." surname="Dold">
@@ -63,7 +63,7 @@ Questions:
       </address>
     </author>
 
-    <date day="17" month="January" year="2016" />
+    <date day="13" month="February" year="2017" />
 
     <!-- Meta-data Declarations -->
     <area>General</area>
@@ -74,7 +74,7 @@ Questions:
     <abstract>
 
       <t>This document defines the 'payto' Uniform Resource Identifier (URI) scheme
-      for addressing payment methods.</t>
+      for specifying payments.</t>
 
     </abstract>
 
@@ -85,25 +85,24 @@ Questions:
 <section anchor="introduction" title="Introduction">
 <t>
   This document defines the 'payto' Uniform Resource Identifier (URI) scheme
-  for addressing payment methods.  In its simplest form, a 'payto' URL
-  identifies an account within a payment method.  Additional parameters
-  for a payment, such as a payment reference, can be provided.
+  for specifying payments.  In its simplest form, a 'payto' URL
+  identifies a payment method.  Additional parameters
+  for a payment, such as an account, an amount or a payment reference, can be provided.
 </t>
 </section>
 
 <section anchor="syntax"
   title="Syntax of a 'payto' URL">
-<figure>
+  <figure>
   <artwork><![CDATA[
   payto-URI = "payto" "://" authority path-abempty [ "?" opts ]
   opts = opt *( "&amp;" opt)
   opt = (generic-opt / authority-specific-opt) "=" *( pchar )
-  generic-opt = "amount" / "recipient" / "sender" / "message" / "message
+  generic-opt = "amount" / "recipient-name" / "sender-name" / "message" / "instruction"
   authority = <authority, see [RFC3986], Section 3.2>
   path-abempty = <path-abempty, see [RFC3986], Section 3.3>
   pchar = <pchar, see [RFC3986], Appendix A.>
 ]]>
-
   </artwork>
 </figure>
 </section>
@@ -126,7 +125,7 @@ Questions:
   <artwork><![CDATA[
     payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello%20world
 
-    INVALID (authority missing):  payto:card/12345
+    INVALID (authority missing):  payto:sepa/12345
 ]]>
 
 </section>
@@ -134,13 +133,13 @@ Questions:
 <section anchor="payment-methods" title="Payment Methods">
 
 <t>
-  sepa:
+  sepa: Single European Payment Area. The path is an IBAN, as defined by [REF].
 
-  upi:
+  upi: Unified Payment Interface. The path is an account alias, as defined by [REF].
 
-  bitcoin:
+  bitcoin: Bitcoin protocol. The path is a bitcoinaddress, as defined by [REF].
 
-  card:
+  ach: FIXME.
 </t>
 
 </section>
@@ -149,13 +148,26 @@ Questions:
 <t>
   The following options SHOULD be understood by every payment method.
 
-  amount:  The amount to transfer, including currency information if applicable.
+  amount:  The amount to transfer, including currency information if applicable. The format MUST be:
+<figure>
+  <artwork><![CDATA[
+  amount = ?(currency ":") unit ?("." fraction)
+  currency = *[A-Z]
+  unit = +[0-9,]
+  fraction = +[0-9,]
+ ]]>
+  </artwork>
+</figure>
+  The fraction MUST be smaller than 10^8.  The unit value MUST be smaller than 2^53.  The use of commas
+  is optional for readability and they MUST be ignored.
+
+  recepient-name:  Name of the recipient of the payment.
 
-  recepient:  Name of the recipient of the payment.
+  sender-name:  Name of the sender of the payment.
 
-  sender:  Name of the sender of the payment
+  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
+  instruction:  A short message giving instructions to the recipient, which MUST NOT be subject to lossy conversions.  Character set limitations allowed for instructions depend on the payment method.
 </t>
 </section>
 
@@ -170,12 +182,12 @@ Questions:
 </t>
 
 
-<section anchor="checksums" title="Checksums">
+<!-- section anchor="checksums" title="Checksums">
 <t>
   (how should fields be sorted?  does order ever matter?  how do we deal with duplicate fields?)
 </t>
 
-</section>
+</section -->
 
 </middle>
 
@@ -189,7 +201,8 @@ Questions:
 
   <!-- Change Log
 
-v00 2017-01-17  HOW   Initial version
+v01 2017-02-13  CG   Minimal clarifications
+v00 2017-01-17  FD   Initial version
   -->
 </back>
 </rfc>