iana registration form

2 files changed, 147 insertions, 2 deletions

diff --git a/standards/draft-dold-payto.xml b/standards/draft-dold-payto.xml
index 4c3f909..a3257eb 100644
--- a/standards/draft-dold-payto.xml
+++ b/standards/draft-dold-payto.xml
@@ -173,11 +173,15 @@ Questions:
 </t>
 
 <t>
-  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, which MAY
+  be subject to lossy conversions (for example, due to character set encoding
+  limitations).
 </t>
 
 <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.
+  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>
 
diff --git a/standards/uri-request-payto.txt b/standards/uri-request-payto.txt
new file mode 100644
index 0000000..0b7ac20
--- /dev/null
+++ b/standards/uri-request-payto.txt
@@ -0,0 +1,141 @@
+Scheme name: payto
+
+Status: permanent
+
+Applications/protocols that use this scheme name:
+  Online banking and payment applications.
+
+Scheme syntax:
+  payto://<method>/<account>[?<params>]
+
+  where the tokens have the following meanings:
+  
+  payto:  The literal "payto"
+  method:  A string identifying the payment method
+  account: A string identifiying the account
+  params: A list of "key=value" pairs separated by "&". 
+    The keys "amount", "recipient-name", "sender-name", "message"
+    and "instruction" SHOULD be supported by all payment methods.
+    Additional keys may be allowed or required by the payment method.
+
+ABNF
+   Formal syntax is defined using ABNF [RFC5234].  Certain values
+   are included by reference from [RFC3986]: 
+
+   payto-URI = "payto" "://" method account [ "?" params ]
+   params = param *( "&amp;" param )
+   param = (generic-param / authority-specific-param) "=" *( pchar )
+   generic-param = "amount" / "recipient-name" / "sender-name" /
+                 "message" / "instruction"
+   method = <authority, see [RFC3986], Section 3.2>
+   account = <path-abempty, see [RFC3986], Section 3.3>
+   pchar = <pchar, see [RFC3986], Appendix A.>
+   amount = [ currency ":" ] unit [ "." fraction ]
+   currency = 1*ALPHA
+   unit = 1*(DIGIT / ",")
+   fraction = 1*(DIGIT / ",")
+
+   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.
+
+Scheme semantics:
+    The authority component of a payment URI identifies the payment
+    method. 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.
+
+  The following methods MUST have the following semantics:
+
+    sepa: Single European Payment Area.  The path is an IBAN, as defined
+    by [ISO20022].
+
+    upi: Unified Payment Interface.  The path is an account alias, as
+    defined by [UPILinking].
+
+    bitcoin: Bitcoin protocol.  The path is a bitcoin address, as defined
+    by [BIP0021].
+
+    ach: Automated Clearing House.  The path is a bank account number, as
+    defined by [NACHA]
+
+  The following parameters SHOULD be recognized by every method:
+
+    amount: The amount to transfer, including currency information if
+    applicable.  The format MUST be:
+
+    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.
+
+    sender-name: 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).
+
+    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.
+
+Encoding considerations:
+  The payto URI scheme encoding conforms to the encoding rules established
+  for URIs in [RFC3986].
+
+  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.
+
+Interoperability considerations:
+  None.
+
+Security considerations:
+  The payto URL contains instructions on how to send money.  Applications
+  that support the payto URI scheme MUST ask for confirmation from the
+  user in order to confirm a payment.  Applications MUST handle payto
+  URLs in conformance with the principle of safe interaction
+  (http://www.w3.org/TR/webarch/#safe-interaction).
+
+Examples:
+  payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello
+
+Contact:
+  Florian Dold <dold@taler.net>
+  Christian Grothoff <christian@grothoff.org>
+
+Author/Change controller:
+  See previous answer.
+
+References:
+   [ISO20022]
+              International Organization for Standardization, "ISO 20022
+              Financial Services - Universal financial industry message
+              scheme", May 2013,
+              <http://iso.ch>
+
+   [NACHA]    NACHA, "NACHA Operating Rules & Guidelines", January 2017,
+              <https://www.nacha.org>
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [BIP0021]  Schneider, N. and M. Corallo, "Bitcoin Improvement
+              Proposal 21", January 2012, <https://en.bitcoin.it/wiki/
+              BIP_0021>.
+
+   [UPILinking]
+              National Payment Corporation of India, "Unified Payment
+              Interface - Common URL Specifications For Deep Linking And
+              Proximity Integration", May 2016,
+              <http://www.npci.org.in/documents/
+              UPILinkingSpecificationsVersion10draft.pdf>.