minor updates to payto://

 draft

1 files changed, 17 insertions, 21 deletions

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 7621975..389f0ee 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -4,14 +4,6 @@
 ]>
 <?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"?>
@@ -46,7 +38,7 @@ Questions:
     </author>
 
     <author fullname="Christian Grothoff" initials="C.G." surname="Grothoff">
-      <organization>INRIA</organization>
+      <organization>BFH</organization>
       <address>
         <postal>
           <street>H&ouml;heweg 80</street>
@@ -55,11 +47,11 @@ Questions:
 	  <code>CH-2501</code>
           <country>CH</country>
         </postal>
-        <email>christian@grothoff.org</email>
+        <email>christian.grothoff@bfh.ch</email>
       </address>
     </author>
 
-    <date day="13" month="February" year="2017" />
+    <date day="7" month="April" year="2018" />
 
     <!-- Meta-data Declarations -->
     <area>General</area>
@@ -97,7 +89,7 @@ Questions:
   payto-URI = "payto" "://" authority path-abempty [ "?" opts ]
   opts = opt *( "&amp;" opt )
   opt = (generic-opt / authority-specific-opt) "=" *( pchar )
-  generic-opt = "amount" / "recipient-name" / "sender-name" /
+  generic-opt = "amount" / "creditor-name" / "debitor-name" /
                 "message" / "instruction"
   authority = <authority, see [RFC3986], Section 3.2>
   path-abempty = <path-abempty, see [RFC3986], Section 3.3>
@@ -141,6 +133,11 @@ Questions:
 
 <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
+  allowed multiple times, with further restrictions depending on the
+  payment method.
+
   The following options SHOULD be understood by every payment method.
 </t>
 <t>
@@ -160,11 +157,11 @@ Questions:
 </t>
 
 <t>
-  recepient-name:  Name of the recipient of the payment.
+  creditor-name:  Name of the entity that is credited (receives the payment).
 </t>
 
 <t>
-  sender-name:  Name of the sender of the payment.
+  debitor-name:  Name of the entity that is debited (makes the payment).
 </t>
 
 <t>
@@ -176,7 +173,7 @@ Questions:
 <t>
   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.
+  for such instructions depend on the payment method.
 </t>
 </section>
 
@@ -187,7 +184,7 @@ Questions:
   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.
+  This conversion process MAY be lossy, except for the instruction field.
 </t>
 </section>
 
@@ -207,8 +204,8 @@ The "payto" URI scheme is to be registered in the "Permanent URI Schemes" regist
 <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>
+<t>Contact: grothoff@gnu.org</t>
+<t>Change controller: grothoff@gnu.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>
@@ -245,10 +242,9 @@ The registration policy for this registry is "First Come First Served", as descr
 
 
 <!-- section anchor="checksums" title="Checksums">
-<t>
-  (how should fields be sorted?  does order ever matter?  how do we deal with duplicate fields?)
+     <t>-
+     (how should fields be sorted?  does order ever matter?)
 </t>
-
 </section -->
 
 </middle>