changes based on ISE feedback

2 files changed, 152 insertions, 152 deletions

diff --git a/standards/Makefile b/standards/Makefile
new file mode 100644
index 0000000..3de8381
--- /dev/null
+++ b/standards/Makefile
@@ -0,0 +1,8 @@
+all: txt html
+
+html:
+	xml2rfc --html draft-dold-payto.xml
+
+txt:
+	xml2rfc draft-dold-payto.xml
+
diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 5b5b2e5..2f322a8 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -3,6 +3,10 @@
 <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
 <!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
 <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
+<!ENTITY RFC7595 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7595.xml">
+<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
+<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
 ]>
 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 
@@ -14,7 +18,7 @@
 <?rfc subcompact="no" ?>
 
 <rfc category="info"
-     docName="draft-dold-payto-09"
+     docName="draft-dold-payto-10"
      ipr="trust200902">
 
   <front>
@@ -58,8 +62,16 @@
 
     <abstract>
 
-      <t>This document defines the 'payto' Uniform Resource Identifier (URI) scheme
-      for designating targets for payments.</t>
+      <t>
+        This document defines the 'payto' Uniform Resource Identifier (URI) scheme
+        for designating targets for payments.
+      </t>
+
+      <t>
+        A unified URI scheme for all payment target types
+        allows applications to offer user interactions with URIs that represent payment targets,
+        simplifying the introduction of new payment systems and applications.
+      </t>
 
     </abstract>
 
@@ -70,7 +82,12 @@
 <section anchor="introduction" title="Introduction">
 <t>
   This document defines the 'payto' Uniform Resource Identifier (URI) <xref target="RFC3986" /> scheme
-  for designating transfer form data for payments.  In particular, it always identifies the target of a payment.
+  for designating transfer form data for payments.
+</t>
+
+<section title="Objective">
+<t>
+  A 'payto' URI always identifies the target of a payment.
   A 'payto' URI consists of a payment target type, a target identifier and optional parameters
   such as an amount or a payment reference.
 </t>
@@ -83,15 +100,17 @@
   allows applications to offer user interactions with URIs that represent payment targets,
   simplifying the introduction of new payment systems and applications.
 </t>
+</section>
+<section title="Requirements Language">
 <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"/>.
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP 14
+   <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
+   they appear in all capitals, as shown here.
 </t>
-<t>
+</section>
 
-</t>
 </section>
 
 <section anchor="syntax"
@@ -108,11 +127,13 @@
                 "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.>
 ]]>
   </artwork>
-</figure>
+  </figure>
+  <t>
+    'path-abempty' is defined in <xref target="RFC3986" /> in Section 3.3.
+    'pchar' is defined in <xref target="RFC3986" />, Appendix A.
+  </t>
 </section>
 
 <section anchor="semantics" title="Semantics">
@@ -158,7 +179,7 @@
 <section anchor="generic-options" title="Generic Options">
 <t>
   Applications MUST accept URIs with options in any order.  The
-  "amount" option MUST only occur at most once.  Other options MAY be
+  "amount" option MUST NOT occur more than once.  Other options MAY be
   allowed multiple times, with further restrictions depending on the
   payment target type.
 
@@ -177,10 +198,10 @@
  ]]>
   </artwork>
 </figure>
-If a 3-letter currency is used, it must be an
+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 '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.
 </t>
 
@@ -221,68 +242,12 @@ The use of commas is optional for readability and they MUST be ignored.
 </t>
 </section>
 
-<section anchor="security" title="Security Considerations">
-<t>
-Interactive applications handling the payto URI scheme MUST NOT initiate any
-financial transactions without prior review and confirmation from the user,
-and MUST take measures to prevent clickjacking <xref target="HMW12"/>.
-</t>
-<t>
-Unless a payto URI is received over a trusted, authenticated channel,
-a user might not be able to identify the target of a payment.  In particular
-due to homographs <xref target="unicode-tr36" />, a payment target type SHOULD NOT
-use human-readable names in combination with unicode in the target
-account specification, as it could give the user the illusion of being able
-to identify the target account from the URI.
-</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.
-</t>
-</section>
-
-<section anchor="iana" title="IANA Considerations">
-
-<t>
-IANA maintains a registry called the "Uniform Resource Identifier
-(URI) Schemes" registry.
-</t>
-
-<section anchor="payto-uri" title="URI Scheme Registration">
-<t>
-IANA maintains a sub-registry of the "Uniform Resource Identifier
-(URI) Schemes" registry also called the "Uniform Resource Identifier
-(URI) Schemes" registry.  The "payto" URI scheme is already
-registered in this sub-registry with status set to "provisional"
-<xref target="RFC7595" />.
-
-IANA is requested to update the reference for the "payto" URI scheme
-to reference the RFC number of this document when it is published as
-an RFC.
-</t>
-</section>
-
-
-<!-- see https://tools.ietf.org/html/rfc5226#section-4.1 -->
-<section anchor="payto-registry" title="Payment Target Type Sub-Registry">
-<t>
-IANA is requested to create a new sub-registry of the "Uniform
-Resource Identifier (URI) Schemes" registry called the "Payment
-Target Types" registry with this document as the reference.
-</t>
-<t>The sub-registry shall record for each entry:
-<list style="symbols">
-<t>Name:  The name of the payment target type (case insensitive ASCII string, restricted to alphanumeric characters,
-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 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" />.
+<section anchor="tracking" title="Tracking Payment Target Types">
+  <t>
+    A registry of Payment Target Types is described in <xref target="payto-registry" />.
 
+    The registration policy for this registry is "First Come First Served",
+    as described in <xref target="RFC8126" />.
 When requesting new entries, careful consideration of the following criteria is strongly advised:
 <list style="numbers">
   <t>The description clearly defines the syntax and semantics of the payment target and optional parameters if applicable.</t>
@@ -298,9 +263,24 @@ When requesting new entries, careful consideration of the following criteria is
     payment processor or bank beyond a simple payment.</t>
   <t>The payment target and the options do not contain the payment sender's account details.</t>
 </list>
-
-IANA is requested to populate the new sub-registry with the entries
-documented in the following sub-sections.
+</t>
+<t>
+Documents that support requests for new registry entries should
+ provide the following information for each entry:
+<list style="symbols">
+<t>Name: The name of the payment target type (case insensitive ASCII string, restricted to alphanumeric characters,
+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 target type (such as an RFC) and target-specific options,
+  or references describing the payment system underlying the payment target type.</t>
+</list>
+</t>
+<t>
+This document populates the registry with six entries as follows (see
+also <xref target="payto-registry" />).
 </t>
 
 <section anchor="registry-entry-ach" title="ACH Bank Account">
@@ -385,19 +365,81 @@ options are mandatory for this payment target.</t>
 </t>
 </section>
 
-<!--
+</section><!-- tracking -->
+
+<section anchor="security" title="Security Considerations">
+<t>
+Interactive applications handling the payto URI scheme MUST NOT initiate any
+financial transactions without prior review and confirmation from the user,
+and MUST take measures to prevent clickjacking <xref target="HMW12"/>.
+</t>
+<t>
+Unless a payto URI is received over a trusted, authenticated channel,
+a user might not be able to identify the target of a payment.  In particular
+due to homographs <xref target="unicode-tr36" />, a payment target type SHOULD NOT
+use human-readable names in combination with unicode in the target
+account specification, as it could give the user the illusion of being able
+to identify the target account from the URI.
+</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.
+</t>
+</section>
+
+<section anchor="iana" title="IANA Considerations">
+
+<t>
+IANA maintains a registry called the "Uniform Resource Identifier
+(URI) Schemes" registry.
+</t>
 
-<t>The registry is initially populated with the following entries:</t>
-<texttable>
-<ttcol>Name</ttcol><ttcol>Description</ttcol><ttcol>Contact></ttcol><ttcol>References</ttcol>
-<c>ach</c><c></c><c>N/A</c><c></c>
-<c>iban</c><c>Single European Payment Area. The path is an IBAN. An optional BIC may preceed the IBAN.</c><c>N/A</c><c></c>
-<c>upi</c><c>Unified Payment Interface. The path is an account alias.</c><c>N/A</c><c></c>
-<c>bitcoin</c><c></c><c>N/A</c><c></c>
-<c>ilp</c><c></c><c>N/A</c><c></c>
-  </texttable>
+<section anchor="payto-uri" title="URI Scheme Registration">
+<t>
+IANA maintains a sub-registry of the "Uniform Resource Identifier
+(URI) Schemes" registry also called the "Uniform Resource Identifier
+(URI) Schemes" registry.  The "payto" URI scheme is already
+registered in this sub-registry with status set to "provisional"
+<xref target="RFC7595" />.
 
--->
+IANA is requested to update the reference for the "payto" URI scheme
+to reference the RFC number of this document when it is published as
+an RFC.
+</t>
+</section>
+
+<section anchor="payto-registry" title="Payment Target Type Registry">
+<t>
+IANA is requested to create a new subregistry of the "Uniform
+Resource Identifier (URI) Schemes" registry called the "Payment
+Target Types" registry with this document as the reference.
+</t>
+<t>The subregistry shall record for each entry:
+<list style="symbols">
+<t>Name:  The name of the payment target type (case insensitive ASCII string, restricted to alphanumeric characters,
+dots and dashes)</t>
+<t>Contact: The contact information of a person to contact for further information</t>
+<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="RFC8126" />.
+</t>
+<t>
+   IANA is requested to populate this registry as follows:
+</t>
+<figure>
+  <artwork>
+    Name      | Contact                 | Reference
+    ----------+-------------------------+------------
+    ach       | N/A                     | [This.I-D]
+    bic       | N/A                     | [This.I-D]
+    iban      | N/A                     | [This.I-D]
+    upi       | N/A                     | [This.I-D]
+    bitcoin   | N/A                     | [This.I-D]
+    ilp       | N/A                     | [This.I-D]
+  </artwork>
+</figure>
 
 </section><!-- payto-registry -->
 
@@ -420,6 +462,15 @@ options are mandatory for this payment target.</t>
 
     &RFC3986;
 
+    &RFC5234;
+
+    &RFC7595;
+
+    &RFC8126;
+
+    &RFC8174;
+
+
     <reference anchor="ISO4217">
       <front>
         <title>ISO 4217 Currency Codes</title>
@@ -459,27 +510,6 @@ options are mandatory for this payment target.</t>
       </front>
     </reference>
 
-  <reference anchor="RFC5234">
-    <front>
-      <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
-      <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
-        <organization>Brandenburg InternetWorking</organization>
-        <address>
-          <email>dcrocker@bbiw.net</email>
-        </address>
-      </author>
-      <author initials="P." surname="Overell" fullname="Paul Overell">
-        <organization>THUS plc.</organization>
-        <address>
-          <email>paul.overell@thus.net</email>
-        </address>
-      </author>
-      <date month="January" year="2008"/>
-    </front>
-    <seriesInfo name="STD" value="68"/>
-    <seriesInfo name="RFC" value="5234"/>
-  </reference>
-
   <reference anchor="unicode-tr36">
     <front>
       <title abbrev="Unicode Security Considerations">Unicode Technical Report #36: Unicode Security Considerations</title>
@@ -498,45 +528,6 @@ options are mandatory for this payment target.</t>
   </reference>
 
 
-  <reference  anchor='RFC5226' target='https://www.rfc-editor.org/info/rfc5226'>
-  <front>
-  <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
-  <author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
-  <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
-  <date year='2008' month='May' />
-  <abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract>
-  </front>
-  <seriesInfo name='RFC' value='5226'/>
-  <seriesInfo name='DOI' value='10.17487/RFC5226'/>
-</reference>
-
-  <reference anchor="RFC7595" target="https://www.rfc-editor.org/info/rfc7595">
-    <front>
-    <title>
-    Guidelines and Registration Procedures for URI Schemes
-    </title>
-    <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor">
-    <organization/>
-    </author>
-    <author initials="T." surname="Hansen" fullname="T. Hansen">
-    <organization/>
-    </author>
-    <author initials="T." surname="Hardie" fullname="T. Hardie">
-    <organization/>
-    </author>
-    <date year="2015" month="June"/>
-    <abstract>
-    <t>
-    This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.
-    </t>
-    </abstract>
-    </front>
-    <seriesInfo name="BCP" value="35"/>
-    <seriesInfo name="RFC" value="7595"/>
-    <seriesInfo name="DOI" value="10.17487/RFC7595"/>
-  </reference>
-
-
   </references>
 
   <references title="Informational References">
@@ -609,6 +600,7 @@ options are mandatory for this payment target.</t>
   </references>
 
 <!-- Change Log
+v10 2019-11-14  CG   Address comments from Adrian Farrel
 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