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

Florian Dold <florian.dold@inria.fr> Sat, 14 April 2018 01:51 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 691D312D87D for <uri-review@ietfa.amsl.com>; Fri, 13 Apr 2018 18:51:38 -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 rX5fYHOJ1R1y for <uri-review@ietfa.amsl.com>; Fri, 13 Apr 2018 18:51:36 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 2258212D87B for <uri-review@ietf.org>; Fri, 13 Apr 2018 18:51:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.48,447,1517871600"; d="scan'208";a="262020548"
Received: from unknown (HELO [192.168.43.176]) ([37.170.194.20]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 14 Apr 2018 03:51:33 +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> <77192bd3-a57a-2585-6c91-d03ee7676136@inria.fr> <DM5PR0201MB3461CC2BE3911A6C4BE60E10C3B30@DM5PR0201MB3461.namprd02.prod.outlook.com>
From: Florian Dold <florian.dold@inria.fr>
Openpgp: preference=signencrypt
X-Enigmail-Draft-Status: N1110
Message-ID: <a191e1bc-63e5-f93b-b934-8333d194bb4c@inria.fr>
Date: Sat, 14 Apr 2018 03:51:34 +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: <DM5PR0201MB3461CC2BE3911A6C4BE60E10C3B30@DM5PR0201MB3461.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/QoRJZrX8dXYRFc5EfWplhUaHM9E>
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: Sat, 14 Apr 2018 01:51:38 -0000

On 4/13/2018 10:34 PM, Larry Masinter wrote:
> On // and /: 
> 
> RFC 7595 section 3.2:
> 
>    Schemes that are not intended for use with relative URIs SHOULD avoid
>    use of the forward slash "/" character in order to avoid unintended
>    processing, such as resolution of "." and ".." (dot segments).
> 
>    Schemes SHOULD avoid improper use of "//".  The use of double slashes
>    in the first part of a URI is not a stylistic indicator that what
>    follows is a URI: double slashes are intended for use ONLY when the
>    syntax of the <scheme-specific-part> contains a hierarchical
>    structure.  In URIs from such schemes, the use of double slashes
>    indicates that what follows is the top hierarchical element for a
>    naming authority (Section 3.2 of RFC 3986 has more details).  Schemes
>    that do not contain a conformant hierarchical structure in their
>    <scheme-specific-part> SHOULD NOT use double slashes following the
>    "<scheme>:" string.

I do not see any inherent conflict here, since the
<scheme-specific-part> indeed contains a hierarchy, though often of
depth exactly two.

Some (currently imaginary) payment system's account identifier could
contain, for example, country and state as part of the hierarchical
identifier:

  payto://futurebank/usa/alabama/joe-exampleguy?amount=USD:50.00

Here "futurebank" is the target account type, and
"/usa/alabama/joe-exampleguy" is the account identifier.

(and further hierarchical sub-elements could be different accounts held
by the same identity, etc.)

Maybe the spec should stress that <scheme-specific-part> indeed contains
a hierarchy, and that a verbatim "/" in the account identifier would
have to be encoded (as %2F)?

> RFC 7595 Section 3.3
> 
> 
>    While URIs might or might not be defined as locators in practice, a
>    scheme definition itself MUST be clear as to how it is expected to
>    function.  Schemes that are not intended to be used as locators
>    SHOULD describe how the resource identified can be determined or
>    accessed by software that obtains a URI of that scheme.

Yes, I agree that this should be more clearly explained in the spec.

The resource represented by a payto URI is a partially filled-out pro
forma invoice, with the (mandatory) beneficiary identified by the
authority and path and other (optional) details (such as amount, debitor
name, etc.) given in the query part.

(Of course "pro forma invoice" is a much broader concept than what payto
provides, but so far we haven't found terminology that is a better match
yet.)

And payto URIs are handled by invoking the application registered with
the target account type ("payment method" in the old terminology).
Typically this application can settle/pay an invoice to such a target
account.

(The application might be part of the browser itself, for example when
an appropriate Web Payment handler is available.)

Best,
Florian