[GNUnet-SVN] [taler-marketing] branch master updated: rfc outline

[gnunet]

This is an automated email from the git hooks/post-receive script.

dold pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new a523ac3  rfc outline
a523ac3 is described below

commit a523ac38afe29d099888c2c428c15c02547a30e6
Author: Florian Dold <address@hidden>
AuthorDate: Mon Feb 13 14:01:12 2017 +0100

    rfc outline
---
 standards/draft-dold-mailto.xml | 127 --------------------------
 standards/draft-dold-payto.xml  | 195 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 195 insertions(+), 127 deletions(-)

diff --git a/standards/draft-dold-mailto.xml b/standards/draft-dold-mailto.xml
deleted file mode 100644
index b42eb09..0000000
--- a/standards/draft-dold-mailto.xml
+++ /dev/null
@@ -1,127 +0,0 @@
-<?xml version="1.0" encoding="US-ASCII"?>
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
-<!ENTITY RFC3986 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml";>
-<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM 
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml";>
-]>
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-
-<?rfc strict="yes" ?>
-<?rfc toc="yes" ?>
-<?rfc symrefs="yes"?>
-<?rfc sortrefs="yes" ?>
-<?rfc compact="yes" ?>
-<?rfc subcompact="no" ?>
-
-<rfc category="info"
-     docName="draft-dold-iesg-payto"
-     ipr="trust200902">
-
-  <front>
-    <title abbrev="Special-Use P2P Names">
-      Special-Use Domain Names of Peer-to-Peer Systems
-    </title>
-
-    <author fullname="Florian Dold" initials="F.D." surname="Dold">
-      <organization>INRIA</organization>
-      <address>
-        <postal>
-          <street>&Eacute;quipe TAMIS</street>
-          <street>INRIA Rennes Bretagne Atlantique</street>
-          <street>263 avenue du G&eacute;n&eacute;ral Leclerc</street>
-          <street>Campus Universitaire de Beaulieu</street>
-          <city>Rennes</city>
-          <region>Bretagne</region>
-         <code>F-35042</code>
-          <country>FR</country>
-        </postal>
-        <email>address@hidden</email>
-      </address>
-    </author>
-
-    <author fullname="Christian Grothoff" initials="C.G." surname="Grothoff">
-      <organization>INRIA</organization>
-      <address>
-        <postal>
-          <street>&Eacute;quipe TAMIS</street>
-          <street>INRIA Rennes Bretagne Atlantique</street>
-          <street>263 avenue du G&eacute;n&eacute;ral Leclerc</street>
-          <street>Campus Universitaire de Beaulieu</street>
-          <city>Rennes</city>
-          <region>Bretagne</region>
-         <code>F-35042</code>
-          <country>FR</country>
-        </postal>
-        <email>address@hidden</email>
-      </address>
-    </author>
-
-    <date day="17" month="January" year="2016" />
-
-    <!-- Meta-data Declarations -->
-    <area>General</area>
-    <workgroup>Internet Engineering Task Force</workgroup>
-
-    <keyword>payments</keyword>
-
-    <abstract>
-
-      <t>This document defines the 'payto' Uniform Resource Identifier (URI) 
scheme
-      for electronic payment addresses.</t>
-
-    </abstract>
-
-  </front>
-
-  <middle>
-
-    <section anchor="introduction"
-            title="Introduction">
-
-      <t>This document defines the 'payto' Uniform Resource Identifier (URI) 
scheme
-      for electronic payment addresses.  The purpose of this URI scheme is to
-      enable a user to initiate a transfer of funds to the specified 
address.</t>
-
-    </section>
-
-    <section anchor="wire-transfer-methods"
-            title="Wire Transfer Methods">
-
-    </section>
-
-  </middle>
-
-  <back>
-
-    <references title="Normative References">
-
-      &RFC3986;
-
-    </references>
-
-    <references title="Informative References">
-
-      <reference anchor="Dingledine2004"
-                 
target="https://www.onion-router.net/Publications/tor-design.pdf";>
-        <front>
-          <title>Tor: the second-generation onion router</title>
-          <author initials="R.D." fullname="Roger Dingledine" 
surname="Dingledine">
-            <organization>The Free Haven Project</organization>
-          </author>
-          <author initials="N.M." fullname="Nick Mathewson" 
surname="Mathewson">
-            <organization>The Free Haven Project</organization>
-          </author>
-          <author initials="P.S." fullname="Paul Syverson" surname="Syverson">
-            <organization>Naval Research Lab</organization>
-          </author>
-          <date year="2004" />
-        </front>
-      </reference>
-
-    </references>
-
-    <!-- Change Log
-
-v00 2017-01-17  HOW   Initial version
-    -->
-  </back>
-</rfc>
diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
new file mode 100644
index 0000000..9e427ce
--- /dev/null
+++ b/standards/draft-dold-payto.xml
@@ -0,0 +1,195 @@
+<?xml version="1.0" encoding="US-ASCII"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY RFC3986 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml";>
+<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM 
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml";>
+]>
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+
+<!--
+Questions:
+- should we distinguish between a message and an instruction?  SEPA does this, 
one
+  can be mangled, the other not
+- how should we specify amounts in general?
+- should we say anything about the number format?
+-->
+
+<?rfc strict="yes" ?>
+<?rfc toc="yes" ?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes" ?>
+<?rfc compact="yes" ?>
+<?rfc subcompact="no" ?>
+
+<rfc category="info"
+     docName="draft-dold-payto"
+     ipr="trust200902">
+
+  <front>
+    <title abbrev="The 'payto' URI scheme">
+      The 'payto' URI scheme for payment addresses
+    </title>
+
+    <author fullname="Florian Dold" initials="F.D." surname="Dold">
+      <organization>INRIA</organization>
+      <address>
+        <postal>
+          <street>&Eacute;quipe TAMIS</street>
+          <street>INRIA Rennes Bretagne Atlantique</street>
+          <street>263 avenue du G&eacute;n&eacute;ral Leclerc</street>
+          <street>Campus Universitaire de Beaulieu</street>
+          <city>Rennes</city>
+          <region>Bretagne</region>
+         <code>F-35042</code>
+          <country>FR</country>
+        </postal>
+        <email>address@hidden</email>
+      </address>
+    </author>
+
+    <author fullname="Christian Grothoff" initials="C.G." surname="Grothoff">
+      <organization>INRIA</organization>
+      <address>
+        <postal>
+          <street>&Eacute;quipe TAMIS</street>
+          <street>INRIA Rennes Bretagne Atlantique</street>
+          <street>263 avenue du G&eacute;n&eacute;ral Leclerc</street>
+          <street>Campus Universitaire de Beaulieu</street>
+          <city>Rennes</city>
+          <region>Bretagne</region>
+         <code>F-35042</code>
+          <country>FR</country>
+        </postal>
+        <email>address@hidden</email>
+      </address>
+    </author>
+
+    <date day="17" month="January" year="2016" />
+
+    <!-- Meta-data Declarations -->
+    <area>General</area>
+    <workgroup>Internet Engineering Task Force</workgroup>
+
+    <keyword>payments</keyword>
+
+    <abstract>
+
+      <t>This document defines the 'payto' Uniform Resource Identifier (URI) 
scheme
+      for addressing payment methods.</t>
+
+    </abstract>
+
+  </front>
+
+  <middle>
+
+<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.
+</t>
+</section>
+
+<section anchor="syntax"
+  title="Syntax of a 'payto' URL">
+<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
+  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>
+
+<section anchor="semantics" title="Semantics">
+<t>
+  The authority component of a payment URI identifies the payment method.  The 
registry
+  for payment methods is defined in <xref target="payment-methods" /> of this 
document.
+
+  The path component of the URI identifies the target account for a payment as 
interpreted
+  by the respective payment method.
+
+  The query component of the URI can provide additional parameters for a 
payment.
+  Every payment method SHOULD accept the options defined in generic-opt.
+</t>
+</section>
+
+<section anchor="examples" title="Examples">
+<figure>
+  <artwork><![CDATA[
+    payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello%20world
+
+    INVALID (authority missing):  payto:card/12345
+]]>
+
+</section>
+
+<section anchor="payment-methods" title="Payment Methods">
+
+<t>
+  sepa:
+
+  upi:
+
+  bitcoin:
+
+  card:
+</t>
+
+</section>
+
+<section anchor="generic-options" title="Generic Options">
+<t>
+  The following options SHOULD be understood by every payment method.
+
+  amount:  The amount to transfer, including currency information if 
applicable.
+
+  recepient:  Name of the recipient of the payment.
+
+  sender:  Name of the sender of the payment
+
+  message:  A short message to identify the purpose of the payment
+</t>
+</section>
+
+
+<section anchor="encoding" title="Encoding">
+<t>
+  Various payment systems use restricted character sets.
+  An application that processes 'payto' URIs MUST convert
+  characters that are not allowed by the respective payment systems
+  into allowable character using either an encoding or a replacement table.
+  This conversion process is typically not lossless.
+</t>
+
+
+<section anchor="checksums" title="Checksums">
+<t>
+  (how should fields be sorted?  does order ever matter?  how do we deal with 
duplicate fields?)
+</t>
+
+</section>
+
+</middle>
+
+<back>
+
+  <references title="Normative References">
+
+    &RFC3986;
+
+  </references>
+
+  <!-- Change Log
+
+v00 2017-01-17  HOW   Initial version
+  -->
+</back>
+</rfc>

-- 
To stop receiving notification emails like this one, please contact
address@hidden