update draft based on review

1 files changed, 38 insertions, 12 deletions

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 4b30a6f..01aa155 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -13,7 +13,7 @@
 <?rfc subcompact="no" ?>
 
 <rfc category="info"
-     docName="draft-dold-payto-08"
+     docName="draft-dold-payto-09"
      ipr="trust200902">
 
   <front>
@@ -48,7 +48,7 @@
       </address>
     </author>
 
-    <date day="27" month="September" year="2019" />
+    <date day="04" month="November" year="2019" />
 
     <!-- Meta-data Declarations -->
     <area>General</area>
@@ -83,6 +83,12 @@
   simplifying the introduction of new payment systems and applications.
 </t>
 <t>
+  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+  "OPTIONAL" in this document are to be interpreted as described in
+  <xref target="RFC2119"/>.
+</t>
+<t>
 
 </t>
 </section>
@@ -94,11 +100,12 @@
   </t>
   <figure>
   <artwork type="abnf"><![CDATA[
-  payto-URI = "payto" "://" authority path-abempty [ "?" opts ]
+  payto-URI = "payto://" authority path-abempty [ "?" opts ]
   opts = opt *( "&" opt )
-  opt = (generic-opt / authority-specific-opt) "=" *( pchar )
+  opt = (generic-opt / authority-specific-opt) "=" *pchar
   generic-opt = "amount" / "receiver-name" / "sender-name" /
                 "message" / "instruction"
+  authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." )
   authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
   path-abempty = <path-abempty, see [RFC3986], Section 3.3>
   pchar = <pchar, see [RFC3986], Appendix A.>
@@ -117,10 +124,10 @@
   by the respective payment target type.
 
   The query component of the URI can provide additional parameters for a payment.
-  Every payment method SHOULD accept the options defined in generic-opt.
+  Every payment target type SHOULD accept the options defined in generic-opt.
 
   The default operation of applications that invoke a URI with the payto scheme
-  SHOULD be to launch an application (if available) associated with the payment
+  MUST be to launch an application (if available) associated with the payment
   target type that can initiate a payment.  If multiple handlers are registered for the same
   payment target type, the user SHOULD be able to choose which application to launch.
   This allows users with multiple bank accounts (each accessed the respective bank's
@@ -152,13 +159,14 @@
   Applications MUST accept URIs with options in any order.  The
   "amount" option MUST only occur at most once.  Other options MAY be
   allowed multiple times, with further restrictions depending on the
-  payment method.
+  payment target type.
 
-  The following options SHOULD be understood by every payment method.
+  The following options SHOULD be understood by every payment target type.
 </t>
 <t>
 
-  amount:  The amount to transfer, including currency information if applicable. The format MUST be:
+  amount:  The amount to transfer, including currency information if applicable.
+  The format MUST be:
 <figure>
   <artwork><![CDATA[
   amount = [ currency ":" ] unit [ "." fraction ]
@@ -168,6 +176,8 @@
  ]]>
   </artwork>
 </figure>
+If a 3-letter currency is used, it must be an
+<xref target="ISO4217" /> alphabetic code.
 The unit value MUST be smaller than 2^53.
 If present, the fraction MUST consist of no more than 8 decimal digits.
 The use of commas is optional for readability and they MUST be ignored.
@@ -190,7 +200,7 @@ The use of commas is optional for readability and they MUST be ignored.
 <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 method.
+  for such instructions depend on the payment target type.
 </t>
 </section>
 
@@ -267,7 +277,7 @@ dots and dashes)</t>
 <t>Description: A description of the payment target type, including the semantics of the path in the URI if applicable.</t>
 <t>Example: At least one example URI to illustrate the payment target type.</t>
 <t>Contact: The contact information of a person to contact for further information</t>
-<t>References: Optionally, references describing the payment method (such as an RFC) and method-specific options,
+<t>References: Optionally, references describing the payment target type (such as an RFC) and target-specific options,
   or references describing the payment system underlying the payment target type.</t>
 </list>
   The registration policy for this sub-registry is "First Come First Served", as described in <xref target="RFC5226" />.
@@ -405,8 +415,23 @@ options are mandatory for this payment target.</t>
 
   <references title="Normative References">
 
+    &RFC2119;
+
     &RFC3986;
 
+    <reference anchor="ISO4217">
+      <front>
+        <title>ISO 4217 Currency Codes</title>
+        <author>
+          <organization>International Organization for Standardization</organization>
+          <address>
+            <uri>http://www.iso.ch</uri>
+          </address>
+        </author>
+        <date month="August" year="2018"/>
+      </front>
+    </reference>
+
     <reference anchor="ISO20022">
       <front>
         <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
@@ -582,7 +607,8 @@ options are mandatory for this payment target.</t>
 
   </references>
 
-  <!-- Change Log
+<!-- Change Log
+v09 2019-11-04  CG   Reference ISO 4217 for currency codes, clean up ENBF syntax and language (based on feedback from Matthias Heckmann)
 v08 2019-09-27  CG   Clarify use of sub-registry as per draft-ise-iana-policy
 v05 2019-05-20  CG   Addressing coments, preparing for independent stream submission, adding BIC
 v01 2017-02-15  CG   References and formatting