add IANA Considerations (registry and scheme registration), change Christian's address from Rennes to Biel

1 files 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>christian@grothoff.org</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: christian@grothoff.org</t>
+<t>Change controller: christian@grothoff.org</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, 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>
+
+
   </references>
 
   <references title="Informational References">