[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [taler-marketing] branch master updated: hacking on payto d
From: |
gnunet |
Subject: |
[GNUnet-SVN] [taler-marketing] branch master updated: hacking on payto draft, adding clarifications |
Date: |
Mon, 13 Feb 2017 14:34:24 +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 dc0ef10 hacking on payto draft, adding clarifications
dc0ef10 is described below
commit dc0ef1087eaf50c0421ccd0b325d0411f60987f0
Author: Christian Grothoff <address@hidden>
AuthorDate: Mon Feb 13 14:35:01 2017 +0100
hacking on payto draft, adding clarifications
---
standards/draft-dold-payto.xml | 55 ++++++++++++++++++++++++++----------------
1 file 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 *( "&" 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>
--
To stop receiving notification emails like this one, please contact
address@hidden
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [taler-marketing] branch master updated: hacking on payto draft, adding clarifications,
gnunet <=