Re: [Uri-review] Review request for payto URI scheme, draft 01

Florian Dold <> Sat, 14 April 2018 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 245E8124319 for <>; Sat, 14 Apr 2018 04:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLcwK28P2e2u for <>; Sat, 14 Apr 2018 04:49:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FF221200C5 for <>; Sat, 14 Apr 2018 04:49:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,449,1517871600"; d="scan'208";a="262046638"
Received: from unknown (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES128-SHA; 14 Apr 2018 13:49:26 +0200
To: Larry Masinter <>
References: <> <> <> <> <> <> <> <> <> <> <001301d3d3b3$f020bb40$d06231c0$>
From: Florian Dold <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Sat, 14 Apr 2018 13:49:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <001301d3d3b3$f020bb40$d06231c0$>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Uri-review] Review request for payto URI scheme, draft 01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Apr 2018 11:49:31 -0000

On 4/14/2018 7:46 AM, Larry Masinter wrote:
> On // and /.
> The definition of "payto" is a good example of WHY RFC 7595 gives the advice about avoiding them.
> You say you want to use "standard libraries" without writing a  custom parser. But there is no standard library, there are lots of little URI-parsing hacks, and there are likely many heuristic libraries that do things you might not want (like case-folding or normalizing the authority name or turning // or /./ or /xx/../ into / because they worked mostly and it mostly doesn't matter. Which is OK in most cases.
> Saying a data structure is "hierarchical" does not apply to one that is always a hierarchy of exactly two levels, without any applications that would use the hierarchical nature.

Neither the hierarchical processing nor case folding within the
authority component causes any issues for payto.  That can of course be
emphasized in the spec.

Quoting  RFC 7595:

"New schemes SHOULD reuse the common URI components of [RFC3986] for
the definition of hierarchical naming schemes.  If there is a strong
reason for a scheme not to use the hierarchical syntax, then the new
scheme definition SHOULD follow the syntax of similar previously
registered schemes."

You seem to be advocating for the invention of additional syntax,
instead of trying to map to the generic syntax of URIs if possible.  Are
you suggesting that the generic syntax of URIs (RFC 3986, Section 3) is
not well defined?

And indeed I do not follow the argument that a hierarchy that is usually
of depth two should not be mapped to hierarchical URIs.  I'd agree with
you if we were trying to encode something like unordered key-value pairs
in the path, but we're not.

Having the "//" in payto URIs means that the matching of payment
handlers can be done by simply looking at the authority part of a URI,
instead of picking apart the path.  This would make deployment on
systems that already allow matching on the authority (but not picking
apart the path) easier. Android's intent registration mechanism is an
example where this applies.

> Your registry of payment names may need a dispute process -- what if two different payment processors both claim to "own" (and release incompatible additions to) a widely used payment type.

This is precisely why the spec defines an IANA registry.

> I think you might relook at Graham's advice to consider an application/payto+json MIME type and schema instead; you'll get parsers and validators and other goodies, easy integration and extensibility. MIME type are easy and a schema is easier. If you need to stuff it in a URI use data:.

How does this address the need to send somebody a link (e.g. through
email, within a document, on a website, in a text message) that
initiates a payment through an existing, traditional banking system?

This is not addressed by the Web Payment APIs.  These APIs are there to
make the checkout flow on a merchant's website easier.

If I want to make a bank transfer to somebody's account, the only way to
initiate this right now would be to open a banking app/site manually and
enter all this information manually (or copy&paste it).  That's
precisely what payto wants to solve, and it can only do so by being a URI.

(Graham's suggestion of using app invocation links doesn't work either;
what's the "app" for SEPA or ACH account payments?)

> A lot of work went into RFC 7595/BCP 35, and I wish you would take it more seriously, rather than try to lawyer through.

Then could you please give some constructive advice on what changes
you'd want to see in the spec to be conformant with RFC 7595/BCP 35?  So
far it seems to me you're mainly arguing from the position of "this
shouldn't even exist as a URI", but maybe I'm misinterpreting what you said.