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

Florian Dold <florian.dold@inria.fr> Fri, 13 April 2018 07:52 UTC

Return-Path: <florian.dold@inria.fr>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D31126B6E for <uri-review@ietfa.amsl.com>; Fri, 13 Apr 2018 00:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo7wc_-JeVep for <uri-review@ietfa.amsl.com>; Fri, 13 Apr 2018 00:52:00 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12446124234 for <uri-review@ietf.org>; Fri, 13 Apr 2018 00:51:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,444,1517871600"; d="scan'208";a="322674791"
Received: from unknown (HELO [192.168.43.30]) ([37.171.151.213]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 Apr 2018 09:51:57 +0200
To: Larry Masinter <masinter@adobe.com>
Cc: "uri-review@ietf.org" <uri-review@ietf.org>
References: <496f8300-4df8-2ca9-751b-e7b481203175@inria.fr> <5ACDBCFE.4030706@ninebynine.org> <1257488c-6d8a-a915-57e7-27f035aee991@inria.fr> <DM5PR0201MB346194A8C9D866A6CD4B49BEC3BD0@DM5PR0201MB3461.namprd02.prod.outlook.com> <fd1dcfd1-2855-446f-a46c-5c441e221b87@inria.fr> <DM5PR0201MB3461594B753258669489BC5CC3B30@DM5PR0201MB3461.namprd02.prod.outlook.com> <DM5PR0201MB3461EDB8DC681DFE3C106F4AC3B30@DM5PR0201MB3461.namprd02.prod.outlook.com>
From: Florian Dold <florian.dold@inria.fr>
Openpgp: preference=signencrypt
Autocrypt: addr=florian.dold@inria.fr; prefer-encrypt=mutual; keydata= xsBNBFLwJVABCAC10yX1gNFICGMqqrNrVxSu5RcxRJRrpkqQ5k5X8aOrbL3zjjRNQwV0FR5Y paPR8NLh4FkeAxk8OrkIuNzLPZwcZxhahZx3+IMo/WQldeCHIh7/DSz76jIGzcWSQiP8nJeT rqKBjGiv7mbGFfLfnLjYe4qtJspoZD3DC/F8K100nURckSkog49EZIkOePGhTp2g/EydPJU9 xXnBVsjhXiP2R4fhVqBDC6oi+/9vsycEAy1CyKzuXFaMoskVg1+DtV2JUX6bU+my4LRShrwQ XM7welwTDgetXxNkzOvI59nhTUIklQIhhmjoE+NZ2wIdtLrs/y66cicLFXdkm6EYCKzFABEB AAHNGkZsb3JpYW4gRG9sZCA8ZmxvQGRvbGQubWU+wsCOBBMBCAA4FiEExyDYmq52EZu3XeRZ 0uTwDynQKksFAllF5oUCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQ0uTwDynQKkuC Igf/cDySMmnM6HPqO4yrF30al6Z6lsW3XrcnGnEU+vVgCqvDllpvtM/zskxpvDwSb+gpbFid HoBYDoa15oMh6RWufeXJkQ7Iob6nbX+reD4Z8bkn16Q51nfXIMupj+DGj2cFRMlku2xzbD90 RWPp9Q8aR+vkXHCWbZxooCnmghz4V5VGdmgyYGZ21B1zNjUelynrLZChLNQFZXOxaV1eHVdC pGsWSupgLU10PCnfYoNEBaffSLorFOfVPuMxghYefrLY2hvslk6gDpOkockcJYz2b1WsprMU s/HUVbWA6HcvZoKgQ5sDv1Ot4A04CHMd8U/MLBQ9/H4Lkr+JJbBRWgLwt87ATQRS8CVQAQgA 1CFraC8IOniXUhWaOfUVVjMPpb661WWClfxUcHgMMj7n9vjVbT+6sfT/qoudIJbDswaucz0G dyeZH004PQtZphFFgupEAYKTfP5dt0AXeAPWYbLvKDKHCUzSweQ8dB9l05ab5r6LE1YSyUfg O+vf2JY35oGS/p7heeMuMCYDG9FK9+Ay32vXnBiFmZB77yVBmi2ERtwECBhx4gWp4VuX/MaL 6jABypo1SiRTSO0ZlB5NZHJeyopfE+DCx+YKuLkhvfHM9/GwYh3I18iv5Un623Fo2XmsF3gr 4kKkY5FcnFsmmtdAMlAjfDCWFu+e95PRVjFQ+6dQk77XZBKWDpaapwARAQABwsBfBBgBAgAJ BQJS8CVQAhsMAAoJENLk8A8p0CpL9lAH/1hgJ9Vay7tKDOxxWzQQ4HZ+Ej5gUAIFBlLtdrMv e7JT2KON2x+NYu1MxiPK3jfiIhVSiappJi4l2Uue2b4+Ko5W4TeRsyvJnm2HcxZxwCGvnnH6 uk/w0rYHLJBoaZEEpgOUXz++ttG4UJujaobRExSk41u/EEEWFRC0oQpH+g2wNTEujIyY2K7a RlMfm3ztjqEqrcm9PcS5pXe/cW+jRe8PmiQtVbeaxRzTqwjAOMoMQ0ws9SXdkDtXo3QxpD7s X/oYatZE2oxLd21j0o3zr4vBeO4o8VM+SJUgE0RQFbSRbEzlVsUVfRFcZJDuXfLwy5OY0l/1 GyrC8fvp7XUruTM=
Message-ID: <77192bd3-a57a-2585-6c91-d03ee7676136@inria.fr>
Date: Fri, 13 Apr 2018 09:51:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <DM5PR0201MB3461EDB8DC681DFE3C106F4AC3B30@DM5PR0201MB3461.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/8T0EuD7vkIO83JFYTd3rKnQyijA>
Subject: Re: [Uri-review] Review request for payto URI scheme, draft 01
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2018 07:52:03 -0000

On 04/13/2018 07:13 AM, Larry Masinter wrote:>
https://www.thepaypers.com/cross-border-ecommerce has an interesting
> survey of payment methods around the world. Just sampling the Preferred
> Payment Methods and Payment Service Providers gives some indication of
> the complexity. Each payment processor has a complex API for invoking a
> payment of which the payto URI seems to want to supply some of the
> parameters? You would have to map your components to each.

Thank you for pointing out that resource.

Payto is not intended as a generic API for payment systems, this is what
the Payment Request API already provides to some degree.  There is no
need to model the API of these payment systems.

Payto only represents the details for a payment to a certain target
account, with standardized names for the most common denominator of
parameters (though specific target account types can accept additional
parameters).  Some payment systems (such as credit cards) do not
directly expose this concept of transferring funds to a target account,
and payto does not apply to them.

Obviously the concept of "here is my credit card information, please
initiate a payment to my credit card" does not make sense.


> WebPayments is far along in implementation, testing and deployment.

There is the concept of "Payment Method Identifier" in WebPayments, but
as discussed in another thread, in payto it should be called "Target
Account Type" instead.

The W3C's Payment Method Identifier spec currently only defines one
fixed payment method.  As mentioned in the discussion with Adrian, a
payto URI could be used as a Payment Method Identifier in the future.

The existing "basic-card" and https-based Payment Method Identifiers
can't be replaced with a payto URI, for reasons stated earlier.

What exactly is the overlap between the Payment Request API and payto
URIs that you'd like to see addressed?

> I think the I18N issues shouldn’t be ignored, especially for things like
> names of users.

Could you point out internationalization issues you see that are not
already addressed by URL encoding?

Some payment systems use a "lossy encoding" for some strings, this issue
is already addressed here:
https://tools.ietf.org/html/draft-dold-payto-01#section-6

> Finally, I think it’s a mistake to use // or / in URIs that are not
> hierarchical, and to use //  / around something that isn’t a host name.

Do you have any reason for this other than personal preference?  The
presence of "//" is required for the first component of the URI to be
interpreted as the authority, as opposed to being part of the path.  The
"/" separates the authority from the path.  Quoting RFC3986:

"The generic syntax provides a common means for distinguishing an
authority based on a registered name or server address, along with
optional port and user information."

and

"If a URI contains an authority component, then the path component must
either be empty or begin with a slash ("/") character."

The authority does not need to be a hostname, it can also be a
registered name.

There are good reasons to stick to the common syntax of URIs, most
importantly to avoid the need for custom parsers.

Best,
Florian