[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-marketing] branch master updated: changes based on ISE feedback
|
From: |
gnunet |
|
Subject: |
[taler-marketing] branch master updated: changes based on ISE feedback |
|
Date: |
Thu, 14 Nov 2019 12:49:07 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository marketing.
The following commit(s) were added to refs/heads/master by this push:
new 36401ab changes based on ISE feedback
36401ab is described below
commit 36401abfbfde19086dc3af3d3bd42cf243e51c08
Author: Christian Grothoff <address@hidden>
AuthorDate: Thu Nov 14 12:49:03 2019 +0100
changes based on ISE feedback
---
standards/Makefile | 8 ++
standards/draft-dold-payto.xml | 296 ++++++++++++++++++++---------------------
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>address@hidden</email>
- </address>
- </author>
- <author initials="P." surname="Overell" fullname="Paul Overell">
- <organization>THUS plc.</organization>
- <address>
- <email>address@hidden</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, [...]
- </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
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-marketing] branch master updated: changes based on ISE feedback,
gnunet <=