[GNUnet-SVN] [taler-marketing] branch master updated: add IANA Considerations (registry and scheme registration), change Christian's address from Rennes to Biel

[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 9bd179c  add IANA Considerations (registry and scheme registration), 
change Christian's address from Rennes to Biel
9bd179c is described below

commit 9bd179cf84f59d234edfee18d8be6efceed05089
Author: Florian Dold <address@hidden>
AuthorDate: Sat Apr 7 02:39:10 2018 +0200

    add IANA Considerations (registry and scheme registration), change 
Christian's address from Rennes to Biel
---
 standards/draft-dold-payto.xml | 62 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 54 insertions(+), 8 deletions(-)

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index a3257eb..80553f3 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -49,14 +49,11 @@ Questions:
       <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>
+          <street>H&ouml;heweg 80</street>
+          <street></street>
+          <city>Biel/Bienne</city>
+         <code>CH-2501</code>
+          <country>CH</country>
         </postal>
         <email>address@hidden</email>
       </address>
@@ -196,6 +193,42 @@ Questions:
 </t>
 </section>
 
+<section anchor="iana" title="IANA Considerations">
+
+<section anchor="payto-uri" title="URI Scheme Registration">
+<t>
+The "payto" URI scheme is to be registered in the "Permanent URI Schemes" 
registry.
+<list style="empty">
+<t>Scheme name: payto</t>
+<t>Status: permanent</t>
+<t>URI scheme syntax: See <xref target="syntax" />.</t>
+<t>URI scheme semantics: See <xref target="semantics" />.</t>
+<t>Applications/protocols that use this scheme name: payto URIs are mainly 
used by financial software</t>
+<t>Contact: address@hidden</t>
+<t>Change controller: address@hidden</t>
+<!-- There does not seem to be a way to link to the references section! -->
+<t>References: See References section of this document>.</t>
+</list>
+</t>
+</section>
+
+<section anchor="payto-registry" title="Payto Payment Method Registry">
+<t>
+This document defines a registry for payment methods.  The name of the registry
+is "Payto Payment Method Registry".
+</t>
+<t>The registry shall record for each entry:
+<list style="symbols">
+<t>Name:  The name of the payment method (case insensitive ASCII string)</t>
+<t>Description: A description of the payment method</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>
+</list>
+The registration policy for this registry is "First Come First Served", as 
described in <xref target="RFC5226" />.
+</t>
+</section>
+
+</section>
 
 <!-- section anchor="checksums" title="Checksums">
 <t>
@@ -260,6 +293,19 @@ Questions:
   </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>
+
+
   </references>
 
   <references title="Informational References">

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